Zeenobit

Thank you so much! This worked!

I love the idea of this mod, and I would love to use it to manage all the zillions of parts that I have. However, manually re-arranging the parts is a very daunting task. I would be a lot nicer if you could organize parts as you unlock them. Basically, if a part is locked, it shouldn't show up in the Part Arranger's list. This way, you can organize a handful of parts whenever you research a new tech, making the entire task a lot more manageable. Would this be possible?

I would love to use this mod purely for the ground vehicles. However, I've tried installing this on 3 fresh installs so far, and everytime, as soon as I launch a ground vehicle on the runway or even the launchpad, the tires of the car clip into the ground. This means the vehicle cannot move. Any solutions to this?

Yes. That'd be the idea. Temporary solution to make it easier to manage the memory and decrease load time until we can dynamically unload textures.

A simple CSV file that goes something like: Part Name 1,filepath1.cfg Part Name 2,filepath2.cfg Then a simple third-party script could parse this and automatically rename those *.cfg files to *.cfg.disabled. This is a very clunky way to do this, but I think it's the easiest solution we'd have until the dynamic texture unloading is resolved. Sidenote: I'm not sure if the texture is loaded intro memory or not if the part is "disabled". If it is, then this solution wouldn't work.

A quick suggestion until the problem is solved for loading/unloading textures dynamically: Would it be possible to generate a list of all parts disabled? If that's done, then manually or automatically we can disable those parts.

What exactly happens? Are you using Deadly Reentry? If so, check the mission log (Press F3).

This is a great mod! I do have a request/suggestion though: When looking at the SpareParts resource, I noticed that it has a density of 18.9 kg/Unit. This is quite a lot in my opinion. Most command modules which take 50.0 units of these have an additional mass of around 945 kg. Of course, everyone could remember to always bring only the amount of spare parts they need, but I think this just becomes yet another thing to double check before launch, especially since most launches won't require spare parts due to short mission lengths. If the density of spare parts shouldn't be changed for balance reasons, I would suggest you remove the spare parts entirely from command modules, or simply set the default amount to 0 units (or something reasonable). Then give us a container of some sort that can store spare parts. This allows the user to only equip spare parts when needed, much like every other resource in the game.

A screenshot? I present you with a fancy album, sir! Have ALL THE screenshots! I performed two tests, and here are the results: *** This is a test with a very simple, standard rocket, all using stock beginner parts. http://imgur.com/a/ozt6o/ Each screenshot corresponds to the state after the space bar was pressed (minus the launchpad and landing shots, for some reason imgur didn't let me edit titles to make it more clear). Note that there is no 'phantom stage' anywhere. The chute should've opened on the 3rd image (2nd space bar). But instead it opens on the 4th (3rd space bar, even though there were only 2 stages). *** The second test is with a very slightly more complex rocket, all using stock beginner parts, simple design for an atmospheric lander. Same format as the above: http://imgur.com/a/082d0 (imgur let me edit the title/description of this second upload, so no explanation needed here). The reason I did this test is because this problem becomes particularly annoying when the chute isn't the last stage, as you can see. Thankfully, I had the throttle down to 0% at the end, but if I didn't, things would go very wrong. ALSO, make note of the 'phantom stage' 2 in the second test, after 2nd spacebar. *** So in one test, I do get the phantom stage you mention, and in the other, I don't. Not sure what conclusion can be drawn from that. But in both cases, as you can see, I need to stage twice for the parachute to go on. For both tests, no other interaction was done with the rocket besides turning on SAS, controlling the throttle, steering the rocket to west, and pressing the spacebar to stage.

I tried removing ATM, and I still get the same error, unfortunately.

A few people are experiencing this problem, myself included. You can go a few pages to see logs posted and more details provided. To save you the trouble: 1. Yes, all addons have been updated. I double and tripple checked this, especially Deadly Reentry. 2. As far as I can tell, yes, all addons are installed correctly and functional as expected. 3. In regards to stock KSP, the issue does not occur with stock KSP 0.25. The issue also does not occur if you uninstall just RealChutes. 4. This is on KSP 0.25 Win32 5. This doesn't look memory related. 6. Yes, this issue has been reported multiple times in 3 different places. This is the log I'm seeing: [LOG 01:47:41.287] [mk1pod (RealChute DE Test)]: Activated <--- I activate the parachute through staging [LOG 01:47:41.287] [fuelTankSmall]: Activated [LOG 01:47:41.288] [parachuteSingle]: Activated [LOG 01:47:44.850] [RealChute]: parachuteSingle was activated in stage 0 <--- 3 seconds later, I press the staging key again No other diagnostic information seems to show up in the log. Additional information: A. This issue happens with both RealChute chutes and stock chutes. B. The parachute opens normally when deployed through the right-click menu, or from an action group. It seems only the execution through staging is the issue. C. The issue happens both with "Automatic arm on deployment" on and off. D. Originally, I suspected this is a Deadly Reentry issue, destroying my chutes. I brought this up in the Deadly Reentry thread, and the developers have resolved the issue with parachutes overheating on deployment. Since that fix, deploying the chute through right-click menu works just fine (see point B above). Any help on this issue would be incredibly appreciated!

I'm noticing an issue, that I think might be related to FAR, but I'm not entirely sure. I'm testing this only with stock parts. Very simple plane: Mk1 Cockpit, Jet Fuel tank, swept wings, Basic Jet Engine, and two of the basic air intakes. Simplest design I could make to test this. I fire the engine on the runway, and as I'm gaining speed, my engine's thrust just keeps dropping as if I'm losing air. But I'm still on the runway! I lift off, my engine's thrust is still dropping. So much that by the time I'm at 3,000 m, with an AoA of 0, the Basic Jet Engine with max thrust of 150 kN is now giving me 20 kN at full throttle, and dropping. Am I doing something wrong? Is this a recent change with FAR? Anyone else experiencing a similar behavior?

Are you using Active Texture Management as well, by any chance?

I'm getting the exact same message: [EXC 16:07:29.441] AggregateException: Failed to create NativeBridge, even legacy mode!Contained exceptions: --------------------------------------- System.PlatformNotSupportedException: This mod currently only supports Direct3D 9.0c. at LoadOnDemand.NativeBridge.SetupNativeBridge () [0x00000] in <filename unknown>:0 --------------------------------------- System.NotImplementedException: Legacy mode isn't even close to a working state! at LoadOnDemand.NativeBridge.SetupNativeBridge () [0x00000] in <filename unknown>:0 LoadOnDemand.NativeBridge.SetupNativeBridge () LoadOnDemand.NativeBridge.Setup (System.String cache_directory) LoadOnDemand.Logic.Startup.Awake () UnityEngine.GameObject:AddComponent(Type) AddonLoader:StartAddon(LoadedAssembly, Type, KSPAddon, Startup) AddonLoader:StartAddons(Startup) :MoveNext() UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) :MoveNext() UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) GameDatabase:StartLoad() :MoveNext() UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) LoadingScreen:Start() Anyone have any solutions?

This is true. And with the entry costs, the "purchase all" button is already there. So I think this mod is obsolete in 0.25 even though it is one of most useful mods for < 0.25.

I was using the stock Mk16 chute too. But I also tested this with RealCute chutes, and they had the same issues.

I tried with it both on and off. Didn't make a difference. What does your console (ALT+F2) and Mission Log (F3) say when you open the chute? If it's a DRE problem, you'd get messages for it in Mission Log.

I've been having the same issue since the latest version. Originally, I suspected it's Deadly Reentry, but it doesn't seem to be, since Deadly Reentry patched their issue already. For now, as a workaround, you can deploy your chute using the right click menu or binding it to an actiongroup. But this problem is really annoying. In case it's lost in the thread, I posted this log a few pages back that explains the problem: [LOG 01:47:41.287] [mk1pod (RealChute DE Test)]: Activated <--- I activate the parachute through staging [LOG 01:47:41.287] [fuelTankSmall]: Activated [LOG 01:47:41.288] [parachuteSingle]: Activated [LOG 01:47:44.850] [RealChute]: parachuteSingle was activated in stage 0 <--- 3 seconds later, I press the staging key again

I'm still having issues with my parachutes not deploying through staging. It only works if I deploy using action groups or the right-click menu. This is after Deadly Reentry fixed the console spam. So now I'm not sure if the issue is from Deadly Reentry or ReachChutes or something else entirely. Anyways, this is the console log when it happens: [LOG 01:47:41.287] [mk1pod (RealChute DE Test)]: Activated <--- I activate the parachute through staging [LOG 01:47:41.287] [fuelTankSmall]: Activated [LOG 01:47:41.288] [parachuteSingle]: Activated [LOG 01:47:44.850] [RealChute]: parachuteSingle was activated in stage 0 <--- 3 seconds later, I press the staging key again This is on a very simple test vessel. The stack is as follows: Mk16 Parachute Command Pod Mk16 FL-T200 Fuel Tank LV-T45 Liquid Fuel Engine The problem happens both with RealChute chutes, AND the stock chutes. Additionally, if I uninstall RealChutes, I don't have this problem. The stock chutes deploy normally through staging (at hilarious and terrifying speeds, of course). This is why I'm getting convinced that it's a RealChute issue.

Thanks for the quick update, Starwaster. You definitely fixed the console spam issue. However, I still have the issue that my chute doesn't deploy through staging. Again, everything is fine if I use the right-click menu to deploy the chute.

I am having a chute problem with the latest version of Deadly Reentry. Originally, I thought this was a RealChutes problem. But further debugging shows it's a Deadly Reentry problem. If I activate the chute using staging, it simply will not deploy, regardless of altitude or temperature. I get a spam in my mission log that my chute failed to deploy due to excessive heat, but my chute is in perfect condition visually. If I activate the chute using the right click menu, under the same conditions, everything works fine. Using the action groups to deploy the chute works perfectly fine too. There is another thread on this issue as well: http://forum.kerbalspaceprogram.com/threads/96582-MK-16-and-Deadly-ReEntry-Question?p=1472806

That would make sense, if it wasn't for the fact that immediately pressing the stage button again, or using the right-click menu to deploy the chute worked under the exact same circumstances. Either the right-click menu should tear the chute off too at that speed, or the staging button should work the first time. Either scenario sounds like a bug to me.

Indeed you're right. It seems to be a Deadly Reentry issue.

I have a similar issue even with the latest version of Deadly Reentry. Originally, I thought this was a RealChutes problem. But further debugging shows it's a Deadly Reentry problem. If I activate the chute using staging, it simply will not deploy, regardless of altitude or temperature. I get a spam in my mission log that my chute failed to deploy due to excessive heat, but my chute is in perfect condition visually. If I activate the chute using the right click menu, under the same conditions, everything works fine.

Any hopes for this being updated for 0.25.0?