[1.12.3+] RealChute Parachute Systems v1.4.9.5 | 20/10/24

[ctbram]

But here's the thing! It doesn't do that for the majority of people using this. It sure as hell didn't do it for me. So there's something unique to the people who are experiencing it but nobody seems very damned intent on providing enough information to track down the problem. Where is your output_log.txt file? Or at least a comprehensive list of mods used?

Edit: And have you tried disarming the chute?

Edit #2: show us that craft in the VAB. In the Action Group Editor. Select 'Staging'.

It's not happening "for the majority" of other people because I suspect the majority are not using both REALCHUTE and SDHI. It is an incompatibility with SDHI and the way it is interpreting REALCHUTES pre-arming of the chutes to auto deploy based on pressure or altitude. I have no control over these settings in the AG editor for the SDHI paradock. Nor would anyone else using this mod and chute and all 100% of the people using this will have this problem unless something can be worked out between SDHI and REALCHUTE authors.

You can see there is no realchute configuration gui in the ag editor for the SDHI paradock. But is was designed to work with realchute using it's own right click context menu.

The SDHI author suggested turning off the auto-deploy in the realchutes .cfg file but I think gimping realchute is not the right answer! I'd rather see paradock fixed to work properly and NOT interpret "pre-arming" as "deploying". I mean can't the two guys cooperate and work out a way to make the paradock chutes just work properly with realchute as they were intended?

Edited May 6, 2014 by ctbram

[sumghai]

SDHI requires RealChute, so those using the latter will automatically require the former.

Please don't vilify myself and stupid_chris by claiming we refuse to cooperate (we've always been on very good terms - in fact, I was involved in some behind the scenes stuff for RealChute). Contrary to what certain individuals have espoused, I'm not trolling anyone or dicking around - I genuinely cannot reproduce the reported issue, and so I'm not really able to help you.

Your best bet would be to have another installation of KSP running only SDHI and RC, to see if it really is only a SDHI/RC issue. Then, add each of the other mods one-by-one until the incompatibility is observed.

[Starwaster]

It's not happening "for the majority" of other people because I suspect the majority are not using both REALCHUTE and SDHI. It is an incompatibility with SDHI and the way it is interpreting REALCHUTES pre-arming of the chutes to auto deploy based on pressure or altitude. I have no control over these settings in the AG editor for the SDHI paradock. Nor would anyone else using this mod and chute and all 100% of the people using this will have this problem unless something can be worked out between SDHI and REALCHUTE authors.

The SDHI author suggested turning off the auto-deploy in the realchutes .cfg file but I think gimping realchute is not the right answer! I'd rather see paradock fixed to work properly and NOT interpret "pre-arming" as "deploying". I mean can't the two guys cooperate and work out a way to make the paradock chutes just work properly with realchute as they were intended?

Do I need to be drunk or stoned to read this? Because I do not drink or do drugs.

This talk about SDHI 'interpreting' ... SDHI has no code of its own, and Real Chutes doesn't decide to arm chutes on its own. If necessary conditions are met it arms. If not, it does not arm. You clearly cannot solve this on your own but you refuse to follow suggested troubleshooting steps or provide needed information.

[ctbram]

I specifically set the SDHI parachutes to only deploy upon falling, hence the "waiting for negative velocity message".

My understanding is that RealChutes_settings.cfg has an option for auto-arm, which I have disabled in my own setup. It is also suggested that folks build and configure their CM/SM stack in the exact manner described in the SDHI SMS user manual.

I just checked the RealChutes_settings.cfg and AutoArm is set to false by default so this does not appear to be the cause of SDHI paradock thinking that the chute has been given the command to "deploy". I have not seen either source but I am guessing that realchute's pre-arm for pressure or altitude base auto deployment is being interpreted by paradock as the command to deploy?!?!?

REALCHUTE_SETTINGS
{
	//If the parachutes automatically arm or not when staged
	autoArm = False

Edited May 6, 2014 by ctbram

[phoenix_ca]

Talk to us when you've run a clean install with RC and SDHI to see if it's specific to the mods or not. It's entirely possible that something else is throwing a wrench in things.

But people are going to just stop trying to help you if you keep on being belligerent in your posts on these forums. I've seen you post in various other add-on threads, almost consistently in an angry and righteous tone. Eventually, others will catch-on and not bother.

[Starwaster]

I just checked the RealChutes_settings.cfg and AutoArm is set to false by default so this does not appear to be the cause of SDHI paradock thinking that the chute has been given the command to "deploy". I have not seen either source but I am guessing that realchute's pre-arm for pressure or altitude base auto deployment is being interpreted by paradock as the command to deploy?!?!?

thank you for providing the screenshots of the VAB

to answer your question, again, SDHI has no code of its own. It's not interpreting anything, it decides nothing. Chute functionality for the paradock comes from the RealChute plugin.

absent the output_log.txt file as phoenix says, you really need to create a new install of KSP with nothing but SDHI and RealChutes. And no other config files, no tweaks, nothing

[ctbram]

SDHI requires RealChute, so those using the latter will automatically require the former.

Please don't vilify myself and stupid_chris by claiming we refuse to cooperate (we've always been on very good terms - in fact, I was involved in some behind the scenes stuff for RealChute). Contrary to what certain individuals have espoused, I'm not trolling anyone or dicking around - I genuinely cannot reproduce the reported issue, and so I'm not really able to help you.

Your best bet would be to have another installation of KSP running only SDHI and RC, to see if it really is only a SDHI/RC issue. Then, add each of the other mods one-by-one until the incompatibility is observed.

Very sorry did not mean to imply anything bad about either of you. I really appreciate both mods and just wanted to try and clearly document the issue as I am seeing it. I just made a camtasia vid of my entire launch sequence so you could actually see what I am seeing.

I am hoping there will be an easy solution for this for as I said I really use both mods extensively. I have at least half a dozen crew transport ships that I switch between that are dependent on both mods.

I apologize if I came across as being upset with either of you guys.

Do I need to be drunk or stoned to read this? Because I do not drink or do drugs.

This talk about SDHI 'interpreting' ... SDHI has no code of its own, and Real Chutes doesn't decide to arm chutes on its own. If necessary conditions are met it arms. If not, it does not arm. You clearly cannot solve this on your own but you refuse to follow suggested troubleshooting steps or provide needed information.

paradock is a chute and something is instructing it to deploy. I don't know the inner workings or which mod is doing what. But I do know that it has nothing to do with the staging or whether the autoarm is set to true or false. I know the chute is starting deployed as I can set "no down" to true and as soon as I launch the chutes deploy. So although I do not know which mod is instructing the chute to deploy something has to be!

I am going to create a vanilla game with just realchute and sdhi and verify that the paradock chute is starting in a deployed state with no other mods as instructed. I am going to use the same craft file.

I also recorded an entire launch but I can't get to youtube right now to upload it. I am trying to provide as much information as I can guys. Making new game now.

paradock is a chute and something is instructing it to deploy. I don't know the inner workings or which mod is doing what. But I do know that it has nothing to do with the staging or whether the autoarm is set to true or false. I know the chute is starting deployed as I can set "no down" to true and as soon as I launch the chutes deploy. So although I do not know which mod is instructing the chute to deploy something has to be!

I am going to create a vanilla game with just realchute and sdhi and verify that the paradock chute is starting in a deployed state with no other mods as instructed. I am going to use the same craft file.

I also recorded an entire launch but I can't get to youtube right now to upload it. I am trying to provide as much information as I can guys. Making new game now.

Doh! Obviously I cannot use the same craft file as it has lots of non-stock parts. So I made a ship consisting of the mk2 command module, the paradock, a 2.5m decoupler, a 2.5m reaction wheel, a grey 1/4 orange tank, and a skipper engine. I did not get the chute attempting to deploy at launch. Going back to existing career game and building the same ship as a test.

Doh! Obviously I cannot use the same craft file as it has lots of non-stock parts. So I made a ship consisting of the mk2 command module, the paradock, a 2.5m decoupler, a 2.5m reaction wheel, a grey 1/4 orange tank, and a skipper engine. I did not get the chute attempting to deploy at launch. Going back to existing career game and building the same ship as a test.

Okay I build the same ship in my current career game - paradock, mk2 capsule, decoupler, tank, skipper and as soon as I press the space bar I get the warning that the chute has attempted to deploy and is awaiting negative vertical velocity.

So from this I can deduce it's not craft file specific. Next I will uninstall sdhi and realchute completely and then reinstall them to see if something within either mod got corrupted. I guess the next step would be to remove all mods but sdhi and realchute in a copy of my current game and see if the problem goes away. If it does I'll do a binary addition of all the mods back to see if one is causing the issue.

Edited May 6, 2014 by stupid_chris
don't.

[Starwaster]

paradock is a chute and something is instructing it to deploy. I don't know the inner workings or which mod is doing what. But I do know that it has nothing to do with the staging or whether the autoarm is set to true or false. I know the chute is starting deployed as I can set "no down" to true and as soon as I launch the chutes deploy. So although I do not know which mod is instructing the chute to deploy something has to be!

I am going to create a vanilla game with just realchute and sdhi and verify that the paradock chute is starting in a deployed state with no other mods as instructed. I am going to use the same craft file.

I also recorded an entire launch but I can't get to youtube right now to upload it. I am trying to provide as much information as I can guys. Making new game now.

It's only a chute because its config file contains something like

MODULE
{
    name = RealChute // guessing at module name. posting from iPad
    //(buncha chute parameters)
    //chuteDiameter =
    //chuteTexture = 
}

That basically tells KSP that this is a Real Chute and that the Real Chute plugin should be notified of various events like staging, and should be notified when time advances each frame. It has a similar MODULE rhat says 'this is a docking port' and the game's docking port code gets similar notifications and thats an extremely simplistic explanation. Basically, SUmghai wrote no code. He made a model. Wrote a config file that splices that model with other models (docking port for the stockalike version maybe chute model, I forget) and included some lines that give the part chute and port functionality via computer code written by others.

Your chute is attempting to deploy because something told it that it staged. If you activated the engine via its context menu and launched without staging I doubt your chute would be deploying. I have read its code and even hacked on it a bit awhile back and it just doesnt arbitrarily decide to arm or deploy unless it got staged.

Or armed via its context menu.

[NathanKell]

Total stab in the dark, but...Smart Parts? Those can activate stuff.

Remake your ship without custom parts. Add one mod's worth of custom parts back each time, test.

Also, for the eleventy-millionth time, post your output_log.txt

[ctbram]

@Starwasher - I tried activating the engine via it's context menu pretty early on in trying to debug this and the chute still tried to deploy.

I have found the apparent culprit (99.99999999% sure in fact) and I want to apologize. I am normally extremely methodical about adding mods and keeping track of things. However, I guess I was tired and installed several updates in addition to Realchute and SDHI and it turns out that one of those mods components is definitely causing the chutes to deploy on craft load.

I installed a mod from kip engineering call universal docking ports -> http://forum.kerbalspaceprogram.com/threads/73005-0-23-5-Kip-Engineering-NEW!-Adaptive-Docking-Node-by-Toadicus-Fix-(29th-Apr-2014). The latest version comes with a mod called AdaptiveDockingNode and it is this mod that appears to be deploying chutes on craft load. You can even see the message about negative velocity flicker on the screen during the craft load to the launch pad.

What I did to track it down was...

1. uninstalled realchute and sdhi and then reinstalled in my current game and when this failed to resolve the issue

2. I installed a completely vanilla 0.23.5 and only realchutes and sdhi and this did resolve the issue -> which implied the problem could be with a mod conflict so,

3. to eliminate the possibility of a corrupt persistant.sfs issue I went back to my career game and creates a new sandbox game and removed (deleted and pasted to a new folder) all my mods except realchute, sdhi, and the stock two mods. I created a ship and launched and the chutes not not deploy -> so it's was now likely to be a mod problem, so

4. I reinstalled about 1/3 of my mods, built and launched a ship and the chutes once again tried to deploy on launch (at this point I noticed the message flicker as the ship loaded to the pad) -> this really implied a mod issue so,

5. I systematically removed mods until the deploy on ship load stopped and drilled down to a single mod as the culprit -> AdaptiveDockingNode which is a sub mod of Universal Docking Ports from Kip Engineering at http://forum.kerbalspaceprogram.com/threads/73005-0-23-5-Kip-Engineering-NEW!-Adaptive-Docking-Node-by-Toadicus-Fix-(29th-Apr-2014).

I will put a post on their forum page letting to make them aware of the bug. I am sorry to have blamed both the SDHI and the Realchutes authors for this bug.

I hope this will be helpful to any others experiencing this chute deployment on craft load to the pad problem.

[LameLefty]

First, I wan't to say that this is a great mod! Just love it! Ok, now I seem to have come across a problem. If it's one you've found, I apologize!

It seems that there is some kind of issue with the stack chute for me. I'm building a probe using KW rocketry and procedural fairings (i have other mods, but these were the ones being used at the time). I put a stack chute near the top of the rocket. As soon as the physics load on the launch pad, everything above the chute disconnects, falls through the middle of the ship, hits the ground and explodes. The explosion then sends the rocket into the air, but very slowly (almost like in a vacuum with no gravity). I take the stack chute out and the problem stops.

Any thoughts on what might be the issue?

I'm quoting this in its entirety because I experienced almost exactly the same issue yesterday and it only went away when I removed the stack RealChute from the top of my rocket (built with a large number of KW parts and Procedural Fairings). Immediately upon physics loading, the launch clamps fail and the rocket falls to the ground (well, the engine bells fall THROUGH the ground but without much damage). Upon liftoff, things go weird - time speeds up or slows down, parts fall off at random, etc. As soon as I removed the stack chute, things work fine.

If anyone knows where the logs are stored on a Mac, I'll be happy to try to recreate the problem and post them.

[ctbram]

I went to post at the kip Engineering universal docking port forum and apparently they had already discovered the compatibility issue with SDHI. There was an updated AdaptiveDockingNode 1.2 mod which is in my link below. I have confirmed it resolves the deploy on craft load to the launch pad issue.

However, be aware that there still seems to be some kind of issue with incompatible docking port combinations between universal docking ports and stock.

Here is a link http://forum.kerbalspaceprogram.com/threads/73005-0-23-5-Kip-Engineering-NEW%21-Adaptive-Docking-Node-by-Toadicus-Fix-%2829th-Apr-2014%29?p=1140125&viewfull=1#post1140125

[stupid_chris]

Okay. First of all: no.

I just installed the update and launched my crew transfer vehicle - what is with the "awaiting negative vertical velocity". it's kind of distracting. what is it for and can I please turn it off?

That part was okay. You have a problem. You state the problem. You don't go off the rails, you don't get mad. You're just telling me about your problem, and ask for a solution, and if you had stayed there instead of taking it up all the way as you did, it would be much, much, much better for everyone now.

ummm, okay next silly question. Why are my chutes armed before I am launching? I am using the sdhi paradock and I have seen some comments about them starting pre-deployed. Is this what is happening to me because it's damn annoying seeing that message on my screen for my entire mission and not be able to turn it off!!!!

Well apparently I am seeing the same thing. Everyone of my crew transfer ships I have several US and RUSSIAN style crew transfer vehicles use the SDHI paradock and ever since I installed the update 1.1.0.1 yesterday from the instant I press laucnh I get a VERY ANNOYING message about "waiting for negative velocity" and the damn message cannot be turned off until I actually complete my ENTIRE mission and deorbiting!! It really ruins the game to have this gaudy yellow message constantly showing my vertical velocity for several hours spattered in the center of my damn screen!

And you crossed the line here. Why the caps, is this necessary? All you did here was anger everyone off; me included.

It's not happening "for the majority" of other people because I suspect the majority are not using both REALCHUTE and SDHI. It is an incompatibility with SDHI and the way it is interpreting REALCHUTES pre-arming of the chutes to auto deploy based on pressure or altitude. I have no control over these settings in the AG editor for the SDHI paradock. Nor would anyone else using this mod and chute and all 100% of the people using this will have this problem unless something can be worked out between SDHI and REALCHUTE authors.

And that's the most insanely off target thing you said in all this mess. sumghai is a good friend of mine, he contributed immensely to the creation of RealChute, and some very features of this mod are the direct conequence of his participation, ideas, propositions, and concerns. I even made a full RealChute update for SDHI.

You can see there is no realchute configuration gui in the ag editor for the SDHI paradock. But is was designed to work with realchute using it's own right click context menu.

As far as I know, that is intended. I have yet to message sumghai about it to see if he was interested to include it because college has me insanely busy in the past three months (there's actually quite a few things I need to message sumghai about ). Most of the free time I have is spent coding for this because I can do it offline, and when I happen to be online, I rarely have much time.

The SDHI author suggested turning off the auto-deploy in the realchutes .cfg file but I think gimping realchute is not the right answer! I'd rather see paradock fixed to work properly and NOT interpret "pre-arming" as "deploying". I mean can't the two guys cooperate and work out a way to make the paradock chutes just work properly with realchute as they were intended?

They already do. As I said, they were meant to work together.

Very sorry did not mean to imply anything bad about either of you. I really appreciate both mods and just wanted to try and clearly document the issue as I am seeing it. I just made a camtasia vid of my entire launch sequence so you could actually see what I am seeing.

I am hoping there will be an easy solution for this for as I said I really use both mods extensively. I have at least half a dozen crew transport ships that I switch between that are dependent on both mods.

I apologize if I came across as being upset with either of you guys.

You did. You come off extremely entitled and unapreciative of the work that this is, you completely negliged what most people told you to simply ram your problems back at us and tell us all loud and clear how upset you are.

paradock is a chute and something is instructing it to deploy. I don't know the inner workings or which mod is doing what. But I do know that it has nothing to do with the staging or whether the autoarm is set to true or false. I know the chute is starting deployed as I can set "no down" to true and as soon as I launch the chutes deploy. So although I do not know which mod is instructing the chute to deploy something has to be!

I am going to create a vanilla game with just realchute and sdhi and verify that the paradock chute is starting in a deployed state with no other mods as instructed. I am going to use the same craft file.

I also recorded an entire launch but I can't get to youtube right now to upload it. I am trying to provide as much information as I can guys. Making new game now.

The only thing telling a parachute to deploy is you. The instruction goes from you, to RealChute, to the part. The part is irrelevant, the process is just the same. The part is just the thing that "hosts" the parachute. It could be anything, the paradock has nothing to do with this.

Doh! Obviously I cannot use the same craft file as it has lots of non-stock parts. So I made a ship consisting of the mk2 command module, the paradock, a 2.5m decoupler, a 2.5m reaction wheel, a grey 1/4 orange tank, and a skipper engine. I did not get the chute attempting to deploy at launch. Going back to existing career game and building the same ship as a test.

Okay I build the same ship in my current career game - paradock, mk2 capsule, decoupler, tank, skipper and as soon as I press the space bar I get the warning that the chute has attempted to deploy and is awaiting negative vertical velocity.

So from this I can deduce it's not craft file specific. Next I will uninstall sdhi and realchute completely and then reinstall them to see if something within either mod got corrupted. I guess the next step would be to remove all mods but sdhi and realchute in a copy of my current game and see if the problem goes away. If it does I'll do a binary addition of all the mods back to see if one is causing the issue.

Because all this time you were testing with a hoard of mods while throwing a tantrum here?

@Starwasher - I tried activating the engine via it's context menu pretty early on in trying to debug this and the chute still tried to deploy.

I have found the apparent culprit (99.99999999% sure in fact) and I want to apologize. I am normally extremely methodical about adding mods and keeping track of things. However, I guess I was tired and installed several updates in addition to Realchute and SDHI and it turns out that one of those mods components is definitely causing the chutes to deploy on craft load.

I installed a mod from kip engineering call universal docking ports -> http://forum.kerbalspaceprogram.com/threads/73005-0-23-5-Kip-Engineering-NEW!-Adaptive-Docking-Node-by-Toadicus-Fix-(29th-Apr-2014). The latest version comes with a mod called AdaptiveDockingNode and it is this mod that appears to be deploying chutes on craft load. You can even see the message about negative velocity flicker on the screen during the craft load to the launch pad.

What I did to track it down was...

-irrelevant-.

I will put a post on their forum page letting to make them aware of the bug. I am sorry to have blamed both the SDHI and the Realchutes authors for this bug.

I hope this will be helpful to any others experiencing this chute deployment on craft load to the pad problem.

And if you hadn't had the attitude you showed all along in here, everyone would be in a much better mood.

I went to post at the kip Engineering universal docking port forum and apparently they had already discovered the compatibility issue with SDHI. There was an updated AdaptiveDockingNode 1.2 mod which is in my link below. I have confirmed it resolves the deploy on craft load to the launch pad issue.

However, be aware that there still seems to be some kind of issue with incompatible docking port combinations between universal docking ports and stock.

Here is a link http://forum.kerbalspaceprogram.com/threads/73005-0-23-5-Kip-Engineering-NEW%21-Adaptive-Docking-Node-by-Toadicus-Fix-%2829th-Apr-2014%29?p=1140125&viewfull=1#post1140125

And there you go.

---

All in all, that was pretty unnecessary. If you had kept your cool, kept yourself from throwing crazy accusations all over the place, and had provided an output_log.txt from the beginning, I wouldn't have come back from a 4h early morning (6am) shift to find three pages of this in my thread. That was pretty unpleasant. Also please try not quadruple posting next time and such.

[Mykill Metal]

I'm quoting this in its entirety because I experienced almost exactly the same issue yesterday and it only went away when I removed the stack RealChute from the top of my rocket (built with a large number of KW parts and Procedural Fairings). Immediately upon physics loading, the launch clamps fail and the rocket falls to the ground (well, the engine bells fall THROUGH the ground but without much damage). Upon liftoff, things go weird - time speeds up or slows down, parts fall off at random, etc. As soon as I removed the stack chute, things work fine.

That's like almost exactly what happened to me. I placed the 1.25 stack chute on my Laythe landers, and once I would time warp into render distance while in orbit of Laythe, the station would rip apart and start going crazy all over the screen with the g-meter going nuts and the orbit warping all over the map screen. I actually got two or three landers attached before it did it the first time. Once I stopped using the stack chute I was fine. Station is perfect now.

clip of bug

http://youtu.be/XQXXFLXLMiE

[Garek]

Well, I also had the problem described by ctbram. I thought about posting here. Then I realized that I should probably provide a minimal example craft instead of my mod-heavy Orion Launcher. So I build it. And I couldn't replicate the Issue. So I deleted the faulty paradock from the launcher and replaced it with a new one. And that, as far as I've tested, solved the Problem. Now that I read the latest posts, it was probably the same problem with the AdaptiveDockingNode as I also use Kip's mod, and replacing the paradock solved it because i-have-no-idea-what-KSP-does. I should probably update Kip's mod anyway

Just a little story I wanted to share how one can treat such a problem without blowing everything up. Okay, I'm working as a software developer, so I propably know a bit more about minimal examples and hunting down bugs than the average player.

Also wanted to say that RealChutes and SDHI have been on my mod list for a long time and I really appreciate the work all the mod-devs do for the community.

Another Detail, now that I see Mykill's post: the launcher I mentioned was basically the standard SDHI-Orion configuration on top of a KWR 2.5m tank and engine. No Launchclamps, and no wierdness during launch after the 'awaiting negative vertical velocity' problem was solved.

[ctbram]

The only thing telling a parachute to deploy is you. The instruction goes from you, to RealChute, to the part. The part is irrelevant, the process is just the same. The part is just the thing that "hosts" the parachute. It could be anything, the paradock has nothing to do with this.

This is completely untrue! I did not instruct the chute to deploy. The stage with the chute was clearly 5 stages away from the launch stage! The chute was deploying or attempting to be deployed as the ship was being loaded on the pad! You could even see a message pop up just before the ship loaded and before the physics engine loaded. I did nothing to deploy the chute myself.

Because all this time you were testing with a hoard of mods while throwing a tantrum here?

I don't consider 8 mods to be "a hoard". Especially since at the time the only changes I thought I had made was updating Realchutes and SDHI (which accounts for 25% of all my mods) so naturally they were the only two things that I thought could have been causing the issue. I said I was sorry that I did not recall installing the universal docking system.

I apologized and I drove the issue to ground and posted the results for everyone's benefit! You talk about crossing lines! I don't need to be lectured to by you. If you don't want to accept an apology then fine I don't really care.

[stupid_chris]

You come into the thread and rustle with everyone on three pages, and then expect "sorry" makes it all fine?

That was pretty irritating to go through this morning. The attitude you had is not something I like seeing in here, and I have enough to deal with already.

[sumghai]

To reiterate, when using the SDHI Service Module System, no RealChute configuration GUI will appear in the action group editor - this is intentional and by design.

The SMS is designed specifically for return-to-Kerbin scenarios only, and allowing tweakable parachutes in those two parts opens up the possibility of inexperienced users misconfiguring their chutes and sending their Kerbals to a fiery death.

[ebookah]

Does anybody know how fix this? Or what I did wrong?

[RealChute]: Encountered an error calculating atmospheric density with FAR. Using stock values.

at System.Linq.Enumerable.First[MethodInfo] (IEnumerable`1 source, System.Func`2 predicate, Fallback fallback) [0x00000] in <filename unknown>:0

at System.Linq.Enumerable.First[MethodInfo] (IEnumerable`1 source, System.Func`2 predicate) [0x00000] in <filename unknown>:0

at RealChute.Extensions.CelestialBodyExtensions.GetDensityAtAlt (.CelestialBody body, Double alt) [0x00000] in <filename unknown>:0

(Filename: C:/BuildAgent/work/d3d49558e4d408f4/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 53)

InvalidOperationException: Operation is not valid due to the current state of the object

at System.Linq.Enumerable.First[MethodInfo] (IEnumerable`1 source, System.Func`2 predicate, Fallback fallback) [0x00000] in <filename unknown>:0

at System.Linq.Enumerable.First[MethodInfo] (IEnumerable`1 source, System.Func`2 predicate) [0x00000] in <filename unknown>:0

at RealChute.Extensions.CelestialBodyExtensions.GetDensityAtAlt (.CelestialBody body, Double alt) [0x00000] in <filename unknown>:0

UnityEngine.Debug:Internal_LogException(Exception, Object)

UnityEngine.Debug:LogException(Exception)

RealChute.Extensions.CelestialBodyExtensions:GetDensityAtAlt(CelestialBody, Double)

RealChute.RealChuteModule:FixedUpdate()

[stupid_chris]

Does anybody know how fix this? Or what I did wrong?

-snip-

Update FAR.

[ebookah]

Update FAR.

ok thank you.

[Eskandare]

Yeah I fixed that one locally, it'll have to wait until next update.

I'm pretty sure this may be the same issue, but I got NREs up the wazzu.

Log in DropBox

[stupid_chris]

I'm pretty sure this may be the same issue, but I got NREs up the wazzu.

Log in DropBox

KSP.log is mostly useless, I'll need your output_log.txt

[Eskandare]

KSP.log is mostly useless, I'll need your output_log.txt

Oops! Sorry wrong one. Here it is! This occurs upon leaving the atmosphere and prevents KSP menu commands from working (ie: recover vessel, revert, etc.)

Edit: Reading through the log, it looks like it could be a conflict with MechJeb. Didn't occur when I tested each mod individually. Then I installed each mod one at a time, testing each one against the others. When I installed RealChutes the NREs started up again.

Edited May 7, 2014 by Eskandare

[Starwaster]

Getting the following error when I reload the database:

PartLoader: Compiling Part 'RealChute/Parts/cone_chute/RC_cone'

(Filename: C:/BuildAgent/work/d3d49558e4d408f4/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 53)

ArgumentException: An element with the same key already exists in the dictionary.
  at System.Collections.Generic.Dictionary`2[System.String,System.Collections.Generic.List`1[RealChute.SizeNode]].Add (System.String key, System.Collections.Generic.List`1 value) [0x00000] in <filename unknown>:0 

  at RealChute.ProceduralChute.OnLoad (.ConfigNode node) [0x00000] in <filename unknown>:0 

  at PartModule.Load (.ConfigNode node) [0x00000] in <filename unknown>:0 

  at PartLoader+.MoveNext () [0x00000] in <filename unknown>:0 

(Filename:  Line: -1)
  at Part.AddModule (.ConfigNode node) [0x00000] in <filename unknown>:0 

  at PartLoader.ParsePart (.UrlConfig urlConfig, .ConfigNode node) [0x00000] in <filename unknown>:0 

All parts that would have compiled after that point don't and all patches fail.