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

[stupid_chris]

To everyone with the reports: thanks. I'll try to take a look when I get my laptop back. Developing from this remote computer is suboptimal. But a thing I'm noticing: mot of you are on 1.2.5.2, get 1.5.2.3. Other thing, try to see if a sandbox game also crashes if you remove the part folder. If so, I have a clue what might be going on on my side.

SQUAD needs to make these chutes stock. They're about a hundred times better.

Don't tell that to me. Y'all should email Squad about that.

[endl]

RealChute should not be doing that, because RealChute just adds some parachutes, and in theory, functionality to existing parachutes. Are you referring to Deadly Reentry? In that case: make sure your landing gear is tucked away behind a heatshield: I will often use a procedural heatshield from Procedural Parts which is just a bit wider than the rest of my craft. Anything which sticks out more than the tiniest bit from your heatshield is liable to fry if you're using Deadly Reentry.

your absolutly right, i should have posted this under deadly re entry

[funk]

... But a thing I'm noticing: mot of you are on 1.2.5.2, get 1.5.2.3..

That did it for me... now quickloading is fine... but the chutes of the existing vessel aren't deployable through staging... but thats a small thing and trivial... THX!!!

[Kitspace]

Hello

It is very nice to see all these fixes but it would be nice to know one more thing.

There were three more little issues some time ago. One of them was the double cone chute configured to a main and a drogue did not drop its fairing if the main was deployed without the drogue due to low speed or altitude. And the other one is that just a couple of versions ago the choice between the triple dome and the large single dome disappeared for some of the parts where it was previously. And the third one was that all the parachutes set to deploy while going down or deploy after a delay did not follow these rules if activated at a very low altitude like during a pad abort.

Are these still there now?

Thank you!

[FlexGunship]

To everyone with the reports: thanks. I'll try to take a look when I get my laptop back. Developing from this remote computer is suboptimal. But a thing I'm noticing: mot of you are on 1.2.5.2, get 1.5.2.3. Other thing, try to see if a sandbox game also crashes if you remove the part folder. If so, I have a clue what might be going on on my side.

Woohoo! Proper bug reporting saves a mod (and the mental state of a modder)!

[slumpie]

To everyone with the reports: thanks. I'll try to take a look when I get my laptop back. Developing from this remote computer is suboptimal. But a thing I'm noticing: mot of you are on 1.2.5.2, get 1.5.2.3. Other thing, try to see if a sandbox game also crashes if you remove the part folder. If so, I have a clue what might be going on on my side.

I just noticed something. The .version file still says 1.2.5.2 instead of 1.2.5.3.

Also AVC doesn't report 1.2.5.2 as being outdated.

Edited October 15, 2014 by slumpie

[hjrrockies]

The only thing "stupid" about stupid_chris is that there's only one of him . I know we'd love a clone or two, and he probably wouldn't mind the extra help.

It's the paradox of excellent software - the better it is, the more people use it, which leads to more support requests. This is RealChute.

[Mystique]

Is anyone experiencing chutes not being deployed first time when you press "space" to activate corresponding stage, even though corresponding sound effect seems to play? Not sure it's RC related, got quite a bunch of mods here, so I'm just guessing, because it only affects chutes so far =\

[Zeenobit]

Is anyone experiencing chutes not being deployed first time when you press "space" to activate corresponding stage, even though corresponding sound effect seems to play? Not sure it's RC related, got quite a bunch of mods here, so I'm just guessing, because it only affects chutes so far =\

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

[hjrrockies]

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

Does the "Automatic arm on deployment" option make a difference?

[Mystique]

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 suspected DRE somehow, generally because I build craft with kind of service/propulsion module that also carries heatshield. After hottest part of re-entry I usually decouple it and have chutes deploy there at the same time in order to get some cash back. When I do this, I get some phantom stage (i.e. empty stage that can be deleted with "-" button) and when I press "space" to activate chute stage, it plays deployment sound while that phantom stage disappears. So I thought that it somehow tries to activate part that was left on decoupled module.

Right click or action group is fine until you have to do it while there is about 7 km to nearest mountain, which is quite blocking your way, speed is above 400 m/v and things are getting FUBAR because control was lost when thick air aerodynamics kicked in

Does the "Automatic arm on deployment" option make a difference?

I have it on, didn't try to switch off ever.

[Zeenobit]

Does the "Automatic arm on deployment" option make a difference?

I tried with it both on and off. Didn't make a difference.

I suspected DRE somehow, generally because I build craft with kind of service/propulsion module that also carries heatshield. After hottest part of re-entry I usually decouple it and have chutes deploy there at the same time in order to get some cash back. When I do this, I get some phantom stage (i.e. empty stage that can be deleted with "-" button) and when I press "space" to activate chute stage, it plays deployment sound while that phantom stage disappears. So I thought that it somehow tries to activate part that was left on decoupled module.

Right click or action group is fine until you have to do it while there is about 7 km to nearest mountain, which is quite blocking your way, speed is above 400 m/v and things are getting FUBAR because control was lost when thick air aerodynamics kicked in

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.

[Mystique]

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.

Log shows only record about stage activation, that's all. In console I have lot of spam "Skipped frame because GfxDevice is in invalid state (device lost)" (the Kerb should that mean), but there were also records like you posted above and when I have to press space 3 times to actually open chute.

P.S. Just in case, what exactly part were you using? I was using stock chute (which is currently tweakable like all RC chutes).

[Starwaster]

In console I have lot of spam "Skipped frame because GfxDevice is in invalid state (device lost)" (the Kerb should that mean),

That's because you alt-tabbed away from KSP to go look at your log file while the game was running.

That's normal behavior. Might not do it if you're running KSP in Windowed Mode instead of fullscreen. Maybe.

[NathanKell]

Correct, it only does it in fullscreen.

[Zeenobit]

P.S. Just in case, what exactly part were you using? I was using stock chute (which is currently tweakable like all RC chutes).

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

[Mystique]

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

Yep, that's right.

About phantom stage - it's actually chutes that were left on detached stage for automatic recovery purposes. When that stage was flying near me and getting hot, its chutes appeared in phantom stage with overheat warning, even though they weren't part of the vessel anymore. Maybe that the cause of problem, who knows.

[ArcFurnace]

Why has this mod been made completely incomparable with x64 Kerbal? I know many people complain about crashes an that they fail to realist most conflicts and crashes are actually caused by the instability of the game, and not the mod, but this choice keeps people like me from using your mod at all. I love Real chute, its part of my core mods but making it incomparable with x64 means that it must be abandoned. I can't sacrifice dozens of other mods for this solely because you deemed it necessary to place this limit. Is the complaints of a few worth blocking everyone who needs the x64 Kerbal to run all their mods? I get that it must be frustrating, and there's probably a lot more to this, but without intimately knowing the code and programming process, us on the outside only see the results, the arbitrary limiting that you imposed on us.

Because no amount of warnings in the thread to not bother him with bug reports from the instability-riddled Win64 KSP worked.

Personally I like ferram4's solution, which also works here (according to the license terms in the first post): if you are capable of downloading the source code, modifying it to remove the small code snippet that disables the mod if Win64 KSP is detected, and recompiling it for your own use, this proves that you know enough about computers to not end up harassing the mod author with bug reports that aren't his responsibility and may use the mod freely in Win64 KSP. No redistributing it, though.

[stupid_chris]

Why has this mod been made completely incomparable with x64 Kerbal? I know many people complain about crashes an that they fail to realist most conflicts and crashes are actually caused by the instability of the game, and not the mod, but this choice keeps people like me from using your mod at all. I love Real chute, its part of my core mods but making it incomparable with x64 means that it must be abandoned. I can't sacrifice dozens of other mods for this solely because you deemed it necessary to place this limit. Is the complaints of a few worth blocking everyone who needs the x64 Kerbal to run all their mods? I get that it must be frustrating, and there's probably a lot more to this, but without intimately knowing the code and programming process, us on the outside only see the results, the arbitrary limiting that you imposed on us.

Do whatever you please.

[Claw]

I get that it must be frustrating, and there's probably a lot more to this, but without intimately knowing the code and programming process, us on the outside only see the results, the arbitrary limiting that you imposed on us.

It is not only frustrating, but people have been downright belligerent and obscene toward add-on authors. It's really disconcerting how rapidly people can turn on the mod authors for things that aren't really anyone's fault. People wanted 64-bit KSP bad, and they got it (and it's bad). This is why the add-on authors have been doing things like disabling 64-bit capability. Don't be upset with the add-on authors, but with those who put them in this situation.

Cheers,

~Claw

[Jim Kernan]

Why has this mod been made completely incomparable with x64 Kerbal? I know many people complain about crashes an that they fail to realist most conflicts and crashes are actually caused by the instability of the game, and not the mod, but this choice keeps people like me from using your mod at all. I love Real chute, its part of my core mods but making it incomparable with x64 means that it must be abandoned. I can't sacrifice dozens of other mods for this solely because you deemed it necessary to place this limit. Is the complaints of a few worth blocking everyone who needs the x64 Kerbal to run all their mods? I get that it must be frustrating, and there's probably a lot more to this, but without intimately knowing the code and programming process, us on the outside only see the results, the arbitrary limiting that you imposed on us.

This author and many others make these plugins for us because they love the game and want to contribute to it because they can. They don't get enough donations to even make it a second job. Yet people demand things from them that take real life time away from other things that they like to do. As long as there are posts like yours in this thread, I don't blame Stupid_Chris for staying away. Fuss at Squad for the buggy 64-bit KSP. Not the mod authors who have decided to exempt it from their plugins.

[Guest]

Except that 64-bit KSP is actually pretty stable under OpenGL. I find that going out of way to disable a plugin in 64-bit is a downright moronic way to go. This restriction is arbitrary and should be removed, or never should have been here in first place. If some people are dumb enough to blame 64-bit instability on mod authors, punish those people, not the entire userbase!

Really, it's startling on how many people (not only on these forums, this kind of mindset is everywhere) fail to consider that "idiot-proofing" their stuff in a way that actually hurts other users is getting it backwards. Making it possible to disable via config would be an option, but forcing people to compile from the source just to get 64-bit enabled is just. plain. wrong. It's also a fallacy that it will "fix" anything, as people dumb enough to complain to the mod author about 64-bit bugs are usually also dumb enough to complain if the mod doesn't work at all (due to being artificially disabled). So it's not even idiot-proof, as seen in FAR thread, this sort of restriction accomplishes exactly nothing.

Don't be upset with the add-on authors, but with those who put them in this situation.

It doesn't work like that, sorry. If they ignored those dolts who couldn't grasp that 64-bit has some problems, then there would be no problem. However, by introducing those arbitrary restrictions, they introduce a legitimate reason for people to be angry with them. So, instead of having dumb people turn on them for things that aren't their fault, they have people in general turning on them for things that are very much their fault. This is the way I see it, and should I ever dabble in writing plugins, I'll never introduce anything like that.

Edited October 17, 2014 by Guest

[Nori]

@Dragon01, yeah but I don't think you are looking at this from the mod author's point of view. He has tested Win x64 and it was found lacking. He also gets a extreme amount of support requests for x64 most all of which are due to x64 bugs. So why not disable it? If I was a modder I most certainly would.

As for people wondering why it isn't working because it is disabled, doesn't it pop up with a window saying x64 doesn't work with this mod?

As for the x64 being stable under OpenGL I haven't heard of this as of yet. Nvidia graphics card? And what is your overall RAM usage? PM me if you don't want to derail the thread.

[Guest]

People reported x64 working well under OGL. I haven't tested this personally (only my laptop has a 64bit system, and that one is still on 0.23.5), but those who heard of it reported it's working fine. Performance does take a hit, though, as is always the case with OGL in Unity.

And no, I am looking at it from a mod maker's perspective. If there's no technical reason not to allow something to run on 64bit, then it shouldn't be artificially prevented from doing so. IIRC, there's no window, either. I suppose that's because going out of your way to make a warning window requires more effort than just killing the plugin, or else they could just stick with a pop-up warning. RealChute would likely work fine on 64bit, but there are other, unrelated bugs that people complain about. As such, besides lazyness (i.e. not wanting to listen to complaints; not that it works, as detailed above), I don't see a reason to disable a plugin like that. As an actual mod (though not plugin) author, I would never cut out 64bit users like this. It's simply wrong to do so.

Real chute is important because things depend on it, like Component Space Shuttle. RealChute being incompatible with 64bit means CSS isn't (at least in it's current form). As such, it's not only forcing users to use 32bit with it, it might also force other mod authors to stop supporting 64bit if they used it as a dependency.

Edited October 17, 2014 by Guest

[Walsht9]

People reported x64 working well under OGL. I haven't tested this personally (only my laptop has a 64bit system, and that one is still on 0.23.5), but those who heard of it reported it's working fine. Performance does take a hit, though, as is always the case with OGL in Unity.

And no, I am looking at it from a mod maker's perspective. If there's no technical reason not to allow something to run on 64bit, then it shouldn't be artificially prevented from doing so. IIRC, there's no window, either. I suppose that's because going out of your way to make a warning window requires more effort than just killing the plugin, or else they could just stick with a pop-up warning. RealChute would likely work fine on 64bit, but there are other, unrelated bugs that people complain about. As such, besides lazyness (i.e. not wanting to listen to complaints; not that it works, as detailed above), I don't see a reason to disable a plugin like that. As an actual mod (though not plugin) author, I would never cut out 64bit users like this. It's simply wrong to do so.

Real chute is important because things depend on it, like Component Space Shuttle. RealChute being incompatible with 64bit means CSS isn't (at least in it's current form). As such, it's not only forcing users to use 32bit with it, it might also force other mod authors to stop supporting 64bit if they used it as a dependency.

Well said! Real chutes is a core componnent of many other mods I use. As a 64 bit enthusiast this decision has caused me to loose some interest in my absolute favorite game EVER.