Starwaster

They're also stored in a manner that it's not technically possible for you to obtain without dissecting asset files into McNugget sized pieces and parts which also happens to be the part disallowed under the EULA.

Using Update() to check to see if any new Kerbals have gone on EVA lately is bad folks... m'kay? So don't use Update() to check to see if any Kerbals have gone on EVA... m'kay?

No, even on Kerbin, if there is CO2 on the part then the recycler is supposed to be processing it into O2. Re: expansion & other resources, maybe. Even if not, it would be easy enough to write up a MM config to cut out unwanted parts. 99.99% of Ioncross resources are not hardcoded at all. It's all in the configs. And the 0.01% is only because of a hack that checks to see if any EVA resources are Oxygen so that Kerbals can be exempted in code from having to need bottled Oxygen when on Kerbin or Laythe. (Laythe has O2 in its atmosphere, right? I forget... anyway, it checks to see if the planet.atmosphereContainsOxygen and doesn't do a resource check/consumption for the Kerbal if that's true)

Ok I take back my earlier answer. Or rather, it's factually correct but conversion is definitely not happening.... Looking into that. I see no errors or status messages indicating a problem.

I use XSI when I model for KSP.

Ioncross 1.21.0 update Updated for KSP 1.0.5 Known issue: Menu unavailable at this time. If per savegame enabling/disabling is desired then save games must be manually edited and isLifeSupportEnabled set to true or false as desired for enabling or disabling. Downloads http://mods.curse.com/ksp-mods/kerbal/221054-ioncross-crew-support-sw alternate download https://github.com/Starwaster/Ioncross-Crew-Support/releases/tag/v1.21.0 Plans for near future: Update for KSP 1.1.x (this may or may not mean 1.1.2, depending on how quickly 1.1.3 gets here) Command pods will have electronics and other electrical equipment that generate heat. Factor in effects of interior heating on Kerbals. Kerbals can get too hot or too cold and be incapacitated or die. (radiators will be useful in keeping them cool) Create simpler life support configs. (Two resources. 'Life Support' and possibly 'Waste') Create advanced life support config (current config + water and possibly other resources)

The model needs a hatch transform added to it. There are two ways to do that. The first requires that the model in question is edited in the Unity editor and the appropriate transform added to it. It wouldn't hurt for appropriate texture or meshing be added where lacking. (is it lacking? I hadn't noticed myself) Since we don't have access to the original models/meshes before they were exported from Unity to KSP (unless Stali has them?) we move to option 2. A model is created in Unity that has a hatch transform. This is then exported and added to the part using MODEL nodes. (mesh/texture is optional; the 'model' can be just a transform and nothing more)

@bertibott Do you have Module Manager installed?

I don't remember it having attach node issues but apparently it does... here's a link to a post that should help:

Slight correction though on the 'no roll' part; obviously if you have a pair of them situated on either side you can still roll using it. Just meant to stress that it would limit itself to the one axis.

Real Fuels doesn't touch any of those values at all. Or the TECHLIMIT nodes

In the PP configs look in the TECHLIMIT nodes. Look for lengthMin, lengthMax, diameterMin, diameterMax, volumeMin and volumeMax

@stali79 There's a problem in the J-61 engine config: The gimbal configuration is outside the part configuration. It needs to be moved back inside the part brackets or gimballing won't work. Also, in KSP 1.1.x, you can lock gimballing on a per part axis basis which IMO should be done here considering that the J-61 uses a single set of vanes to control thrust vectoring so it really should be restricted to a single axis. (i.e. no yaw, no roll) This is tested and works even if the engine's orientation is changed from default. MODULE { name = ModuleGimbal gimbalTransformName = thrustTransform gimbalRange = 10.00 gimbalRangeYP = 0 gimbalRangeYN = 0 gimbalRangeZP = 0 gimbalRangeZN = 0 }

That's not what I meant. What I meant was, how are you making the determination that OPT L cargo bay contents are or are not shielded. I just put together an L type and put it on the runway. I didn't do a very comprehensive test, just a single tank attached to one of the interior nodes and secured with struts. That tank was in fact shielded when the doors were closed. I didn't try more complex contents or varying their position within the bay, but it definitely DOES shield contents. The way in which I tested for this was to quick save on the runway with cargo bay closed then I quickloaded and right clicked the test tank with physics-Aero-Display Aero Data enabled. Drag vector is 0, 0, 0 and Cd is 0. The reason for quicksaving then loading is because of a quirk in the aforementioned context menu items where they stop updating when the part goes from unshielded to shielded and only reflect the last known values rather than the current shielded values. Reloading shows the correct current value when examined.

hrmmm I was under the impression that it lacked the cargo bay module. That LOOKS correct. How are you determining shielded status?

@Ven you gave the stock hex probe the same name as the one from Asteroid Day??? Duplicate part names are BAD. And no panourgue, this is not normal behavior.

I'm talking about Github. You don't browse through it downloading individual files, you go to releases. I could just link you to that but you need to learn how Github works. Go to https://github.com/BobPalmer/SubPack Look for the word releases. 20 commits, 2 branches, 7 releases, 2 contributors. Click on releases. Alternatively you'll note that there's a big green button that says Clone or Download. You would click on that if either there are no official releases or if you want to grab all the latest changes that have been committed but not yet been pushed into an official release.

But you've taken on the task of maintaining and making changes. Isn't adding cargo bay functionality to the cargo bay something you'd be interested in?

Correct, ModuleAnimation2Value is part of Deadly Reentry

THAT I have not experienced.

... You're doing it wrong. Go to the releases section.

They're improved but there's still room for improvement. They still need work and it wouldn't surprise me in the least if there's a collider issue in there and if it's spanning two parts it might just be popping that cockpit right off.

Ooops I thought I fixed that. It was a last minute versioning change. It's safe to ignore but I'll fix it.

Have you tried relocating the landing gear elsewhere? Especially considering the problems that wheels have in 1.1.2?

I think that only includes the source code.... I'll look into making it include everything. I'm not sure why it doesn't. The deal with the recycler is that you need to kill the scrubbers first. They're scrubbing the CO2 out before the recycler can get to it.