Starwaster

Been there, done that, got the bruises on my forehead from banging my head repeatedly against the desk whilst whimpering like a small feral creature....

If it's disabled, the chute will deploy when staged, if it can deploy. If it cannot deploy it will reset its staging status so that you can still stage it when it is in a deployable situation.

pictures of the texture glitch please?

There is a way of preventing click through..... but I don't know what it is. BTW, work around for click through problems for players. Right click on the button if you're worried about what's underneath.

Send some Kerbals out there with flags. Get the coordinates from the flags.

lol, I'm sorry I if I started anything! (ok not really) (ok maybe just a tiny bit...) (also, downloading) Edit: Oh wait! Does this do anything for SDHI?

WHAT??? He's not? How come nobody told me this in advance.... what am I going to do with these whips and chains now???

If you guys do go back to the old pre 2.2.0 behavior of trying to fix save files, please PLEASE change how dynamic PartModules are handled. Don't wantonly delete them because can be and are used for persistence and if they get deleted then whatever state was being tracked is lot as well.

Did you ever try the suggestion someone made a few pages back about moving it to a different folder? Simply put, do not run the game from Program Files or Program Files (x86) because the game can run into security issues. Make a folder just for it to go in. Call it Games, or whatever you want. Then move KSP in there. Applies to both 32 bit and 64 bit.

That sounds more like a Unity issue then, instead of a Squad issue.... but instancing something shouldn't take as much as having two of the same texture. There's always going to be overhead, no way around that, but instancing is actually what you would want to happen. It's not a bad thing. (And it's still not making a lot of sense, internals and externals texture usage are the same thing instantiated the same way way for a given configuration. If the overhead for internals were as bad as you say it is then it would be just as bad for externals and therefore much more of a problem as external models are used much more than internals)

I still dont understand that. Internals can make use of the same texture declarations as externals. What part exactly doesnt work?

To recap what has been talked about repeatedly over the past few pages; SDHI's paradocks are not currently Real Chute compatible due to Real Chute's format having change with its last update. Stupid Chris has said this is something he's going to deal with but in the meantime, don't use those parts. Or, you can try the temporary hack that I posted in the post right before yours that has a Module Manager patch that will make those parts use the stock chutes. They will work reliably with stock chutes, in as much as stock chutes are reliable in 0.24.

Modules added via ModuleManager should be in the prefab because they were added to the part's configuration node before the part was compiled. It's (probably) only when we do part.AddModule("ModuleMySuperUltraCoolModule") that they're not in the prefab. That's always been the source of those 'cannot load module #x, the part only has y modules' warnings. Or was, I haven't seen any since 0.24 At any rate, I've been thinking we should be adding to the prefabs instead, if we can.

Possible, yes, but if you don't do it exactly right you could make things worse. So what do we REALLY know about Squad's PartModule reordering and what misconduct can we actually implicate it in?

No, he just made an end user mistake confusing coincidence with causality. There's no need to brow beat the guy into submission. Let's just all drop it.

It's right where you left it, GameData/KSO/ Or at least that's where it was supposed to be installed.

Firespitter has had an update for 0.24 for a few days now. it's a parts pack. It's been awhile since a part itself has been broken in a KSP update. It's the plugins you have to watch for, as in the case of the aforementioned Firespitter which is updated.

Some of them are are custom or non-standard. (standard being 20 O2 units per crew capacity)

It SHOULD be really easy given that it's just a big text file, but I had an easier time hex editing binary save files back in the day (for... just about any game)

Oops important note, it's generally best to remove existing mod folders from GameData, but it's really important here because it gets rid of the config file that was manually adding in atmospheric vents (and scrubbers. mostly scrubbers, but vents too) Even if all you do is try to manually replace the dll, it's important that that config file goes away, because the Ioncross code as written really revolves around certain Ioncross modules being added through code, and apparently it really didnt take to me trying to add in the vents that way. (even though it worked fine for the scrubbers) Edit: And, StainX, what the HECK is that green skinned woman with the opal eyes in your signature space???

New test version: IoncrossCrewSupport.1.15.0.zip This shouldn't break craft; previous issue I saw was probably unrelated. However, craft in existing save files will not be fixed by this. If you're brave, you could edit your save files and manually remove air vent generator modules. That should be safe but back up your save files anyway just to be sure. So, with this update, I reverted a lot of the old code that I had changed regarding how persistence was handled. Air vents now work again. They open and close automatically; there is no GUI button for them. Wasn't supposed to be one, that's how broken it was. There is also the possibility that the air scrubber problem might come back, but it's also possible that that was never really an Ioncross issue. Instead, it's probable that it was always a Module Manager save file fixer issue, and as of MM 2.2.0, that functionality has been removed because KSP 0.24 supposedly has rendered it unnecessary and obsolete. (meaning, apparently, that KSP now will handle PartModule order changes and format changes better than it did before) (which is to say, not at all, before) Also, because I'm such a nice guy, this post was not made in Comic Sans

Mmmmmm Hammer Films...

That's how much of a wuss I am. I still don't even know what that option does, and I missed the original Apr 1st release

Seems strange, no other mod that I use that has its own resources has that problem...

There it is. I tried to get it to behave more or less the way the main chute does with the RC version but I had to sort of guesstimate the air pressure because stock doesn't do semi deploy by altitude. Also it opens too fast at 6.... maybe that's now how that parameter works on stock. And of course; no drogue chute. Bad things happen trying to do two stock chute modules on one part. Many Kerbals died to bring me this information Honestly, I find myself not using this so much. Can't wait for an RC version. I wonder if it's just a config issue.... { !MODULE[RealChuteModule]{} MODULE { name = ModuleParachute invertCanopy = true autoCutSpeed = 0.5 capName = chute_cover_drogue canopyName = canopy_main semiDeployedAnimation = SDHI_ParaDock_1_main_semi_deploy fullyDeployedAnimation = SDHI_ParaDock_1_main_full_deploy stowedDrag = 0.22 semiDeployedDrag = 1 fullyDeployedDrag = 700 minAirPressureToOpen = 0.75 deployAltitude = 700 deploymentSpeed = 6 semiDeploymentSpeed = 1 } } @PART[SDHI_ParaDock_2_IACBM]:FINAL //:NEEDS[!RealChuteModule] { !MODULE[RealChuteModule]{} MODULE { name = ModuleParachute invertCanopy = true autoCutSpeed = 0.5 capName = chute_cover_drogue canopyName = canopy_main semiDeployedAnimation = SDHI_ParaDock_2_main_semi_deploy fullyDeployedAnimation = SDHI_ParaDock_2_main_full_deploy stowedDrag = 0.22 semiDeployedDrag = 1 fullyDeployedDrag = 700 minAirPressureToOpen = 0.75 deployAltitude = 700 deploymentSpeed = 6 semiDeploymentSpeed = 1 } } @PART[SDHI_ParaDock_1_ClampOTron]:FINAL//:NEEDS[!RealChuteModule]