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

[Supernovy]

stupid_chris: Nice to see this released. On the subject of colliding parachutes, I wanted to say that when C7 was being bugged about it, he mentioned that he could possibly set up a solution in which the parachutes 'repelled' each other. Like how they move about randomly now, only specifically in the direction away from the other chute(s).

Otherwise, nice job. Also, to whoever asked, yes these deploy just fine at 4x time warp.

[Itsdavyjones]

wow, found out about this today, and can't wait to try it out.

[AndreyATGB]

I tried it with the solar system mod and far and it seems to work fine. The parachute once deployed worked fine but the model really glitched around, it did work as advertised though.

[stupid_chris]

stupid_chris: Nice to see this released. On the subject of colliding parachutes, I wanted to say that when C7 was being bugged about it, he mentioned that he could possibly set up a solution in which the parachutes 'repelled' each other. Like how they move about randomly now, only specifically in the direction away from the other chute(s).

Otherwise, nice job. Also, to whoever asked, yes these deploy just fine at 4x time warp.

.... That's actually a very good and feasible solution. I'm liking how this sounds and that seems like something totally within my reach.

[jpinard]

Will these burn up if you deploy them (with Deadly Re-entry) while in the hottest phase of re-entry?

[stupid_chris]

Will these burn up if you deploy them (with Deadly Re-entry) while in the hottest phase of re-entry?

They'll behave like normal parts do. I don't know if the parachute transform is considered as a part of the part and can affect it's temperature. It would need testing.

[jpinard]

They'll behave like normal parts do. I don't know if the parachute transform is considered as a part of the part and can affect it's temperature. It would need testing.

I hope so. I want to be penalized for being a moron.

[Camacha]

Deployment off pressure could make you smash in a mountain. In some cases that work, but the idea of having deployment and first opening by pressure completely makes it impossible to land on Duna with chutes that land on Kerbin. I understand nromal chutes would work this way, but my goal is to make for a better gameplay experience.

So unfortunately RealChute is not really the right name, nor does realistic parachutes deliver what it says on the tin. BetterChutes would probably cover your bases a bit better. Personally I would love to see a proper RealChute, but I have no use for something that changes stock behaviour into different intentionally (still) inaccurate behaviour, even if it would make life easier in some ways.

I think it would be lovely to learn about parachutes in different atmospheres if they behave properly. Nothing teaches you to be careful like smashing into a mountain because you messed up your densities It might not be convenient, but that is rocket science for you.

Edited November 13, 2013 by Camacha

[User Unrelated]

I saw chris mention this mod in another thread earlier, and decided to try it.

I plopped it into my save, and mounted a realchute main chute to the top of my slightly re-designed lunar lander. I was just going to trust the mod and go for it.

No issues getting there, nice smooth landing in the polar crater

On the way home, I prepared for fuel-saving aerobrake... and cut it a BIT too shallow.

I was burning up around 35000meters up, and opened the chute.

It acted as normal, but then I just bounced off the top of the atmosphere, and tumbled out to my apoapsis (or whichever one is further out), which was around 60,000m, JUST out of the atmosphere.

The chute stayed deployed, but sort of locked into a vertical position above the ship, it wouldn't move around like stock. Also, when the craft re-entered the atmosphere, the unopened chute and lander acted as one body, rotating about their center of mass.

I didn't know what to think of this, but just put it off as maybe how the mod worked?

Well, cut back in for landing

coming in smooth

and then... uh...

MAN am I lucky to have landed this thing.

If I hadn't went around for that second round of aerobraking, I wouldn't have had enough fuel...

then again, it might have been that same second round that glitched the chute... who knows.

Kenlas Kermin was very happy to be alive... but he was NOT happy with those pesky engineers. He thinks maybe Kenny Kermin spilled some starch into the chute bay by accident.

[stupid_chris]

So unfortunately RealChute is not really the right name, nor does realistic parachutes deliver what it says on the tin. BetterChutes would probably cover your bases a bit better. Personally I would love to see a proper RealChute, but I have no use for something that changes stock behaviour into different intentionally (still) inaccurate behaviour, even if it would make life easier in some ways.

I think it would be lovely to learn about parachutes in different atmospheres if they behave properly. Nothing teaches you to be careful like smashing into a mountain because you messed up your densities It might not be convenient, but that is rocket science for you.

Thing is for now, I don't want to be making parachutes for each and single planet. If anything like this comes, it will be when I get around to add the editor window to edit the parameters in game. For now, this would be making things more complex for little to know return. I'm not throwing out the idea, but not now for sure.

@User Unrelated

Yeah, I noticed a few discrepancies in the deployment code. I already applied a bunch of fixes and a new version should be up tonight along with ModuleManager files for stock/other mods. Was the parachute still slightly moving when that happened? Like small parachute noise?

Edited November 14, 2013 by stupid_chris

[User Unrelated]

there was no noise from the chute after I opened it, as far as I could tell... I turn game sound down real low and play

through my ipod onto my stereo system, so I can't quite be sure

The chute was acting stock-like (in the fact that there was a hinge between the chute and the craft) during the first re-entry attempt. After I bounced out of the atmosphere, though, it just sort of got stuck there, and never went back.

It might have something to do with the whole parachute assembly moving back ABOVE the maximum height that the chute would normally open at...

Edited November 14, 2013 by User Unrelated

[stupid_chris]

there was no noise from the chute after I opened it, as far as I could tell... I turn game sound down real low and play

through my ipod onto my stereo system, so I can't quite be sure

The chute was acting stock-like (in the fact that there was a hinge between the chute and the craft) during the first re-entry attempt. After I bounced out of the atmosphere, though, it just sort of got stuck there, and never went back.

It might have something to do with the whole parachute assembly moving back ABOVE the maximum height that the chute would normally open at...

By noise I meant small movement. Like drag noise. Basically was the parachute shaking a little?

Also yeah I spotted the problem, it's the deployment clauses. I just want to know to how far this reaches.

EDIT: so when saying that I was looking at my GitHub code and when I went to my source code, well... it was already fixed. Seems that I noticed that problem earlier today at school and took a few minutes to fix it. So yeah, update tonight with a few hotfixes.

Edited November 14, 2013 by stupid_chris

[rdfox]

For the record, NASA has NEVER used pure atmospheric reefing of the parachutes. Instead, they use a system where the parachute is deployed reefed with an explosive bolt system that holds it until either a barometric, radar-altimeter, or speed-based switch (depending on application) is used to set off the explosive bolts and release the risers, thereby disreefing the parachutes. While they actually do engineer a new parachute for each application (based on load to carry and drag requirements), the basic system is the same, with only the actual canopy and the disreef trigger being altered to suit requirements.

[User Unrelated]

By noise I meant small movement. Like drag noise. Basically was the parachute shaking a little?

Also yeah I spotted the problem, it's the deployment clauses. I just want to know to how far this reaches.

EDIT: so when saying that I was looking at my GitHub code and when I went to my source code, well... it was already fixed. Seems that I noticed that problem earlier today at school and took a few minutes to fix it. So yeah, update tonight with a few hotfixes.

Once the chute was "locked in", there was absolutely no movement. I could rotate the ship in-atmosphere, and the chute would follow as a stationary, rigid body.

Once you roll out the update tonight, I'll try and do some more testing.

I just tested the same chute without leaving the atmosphere (just tossing a module up into the air real quick), and I really like the new opening physics. That sudden jolt of the stock chutes always had me so worried that my stuff would just fall apart. If I was landing something big, I'd pack 2 or 3 spare sets of chutes

Edited November 14, 2013 by User Unrelated

[sumghai]

For the record, NASA has NEVER used pure atmospheric reefing of the parachutes. Instead, they use a system where the parachute is deployed reefed with an explosive bolt system that holds it until either a barometric, radar-altimeter, or speed-based switch (depending on application) is used to set off the explosive bolts and release the risers, thereby disreefing the parachutes. While they actually do engineer a new parachute for each application (based on load to carry and drag requirements), the basic system is the same, with only the actual canopy and the disreef trigger being altered to suit requirements.

Correction: They use mortars to fire out pilot chutes, that in turn pull out the drogues / mains.

[stupid_chris]

Updated to v0.1.1a! Small hotfix that should fix the problems encountered above, along with a new potentially useful feature.

Changelog:

November 13th 2013
v0.1.1a
-Hotfix of a few deployment bugs that could cause weird unresponsive parachutes
-Added a “cutAlt†feature to automatically cut a parachute below a certain altitude.

[CAPFlyer]

So unfortunately RealChute is not really the right name, nor does realistic parachutes deliver what it says on the tin. BetterChutes would probably cover your bases a bit better. Personally I would love to see a proper RealChute, but I have no use for something that changes stock behaviour into different intentionally (still) inaccurate behaviour, even if it would make life easier in some ways.

I think it would be lovely to learn about parachutes in different atmospheres if they behave properly. Nothing teaches you to be careful like smashing into a mountain because you messed up your densities It might not be convenient, but that is rocket science for you.

As the dev, he can name it whatever he wants, so please don't chide him on his choice especially as the first post is clear about what's "in the tin".

Again, I'll restate that "realistic chutes" or "RealChutes" are not possible in this game out of the box. To create "realistic" chute behavior would require a whole new simulation that is beyond even what FAR attempts to create within the program and that's beyond not only the scope of the game as stated by the devs, but really beyond reasonable hardware requirements for 90% of the users as the amount of programming power would require you to at least double the raw computational load of the processors.

[frizzank]

To create "realistic" chute behavior would require a whole new simulation that is beyond even what FAR attempts to create within the program and that's beyond not only the scope of the game as stated by the devs

Even then it would still be a simulation of real life and still not 100% accurate. So again every simulation would be Better Chute regardless of its simulated accuracy.

Your arguing semantics at this point and Real Chute is a good name for conveying what its trying to simulate, in KSP, a game with little yellow men, blowing up rockets on a fictional planet, in a make believe universe.

[smunisto]

Besides we are still playing a game. Same as the reason why the overly-ambitious-overly-realistic-input-commands-with-C-into-computer RemoteTech died.

There is a fine limit into getting the game more realistic(that is to say - more challenging) and for the bigger part of the players this ends around FAR, DR and some other minor tweaks - only things that are supposed to become stock one day, mind you.

Calculating densities? No thank you.

The mod is great, I am waiting for some definite answer on FAR compatibility before install though.

[stupid_chris]

Okay guys, it's fine alright, let's not get heated, I would hate to have to act as a moderator in here. What I do with my plugin and how I name it will always resort to what I want to do with it, I'm already aware that I won't be able to satisfy everyone out there

The mod is great, I am waiting for some definite answer on FAR compatibility before install though.

And I'm still waiting for a confirmation myself. If I have none by tomorrow I'll download FAR and try it myself.

Edited November 14, 2013 by stupid_chris

[Tommygun]

Updated to v0.1.1a! Small hotfix that should fix the problems encountered above, along with a new potentially useful feature.

-Added a “cutAlt†feature to automatically cut a parachute below a certain altitude.

Thank you, I just invented a new game:

"Kerbal Chicken"; how far up can I cut that chute and not destroy the lander.

[drtedastro]

Or you can play catch... Have Bill try to catch Bob's capsule from different altitudes...

[drtedastro]

Is there any future plans to develop a stackable canister that could be filled with drogue and main's..?? I would be nice to be able to create a part that had say an initial high altitude drogue that would be cut and then set of mains or any combination thereof...

the capsules start to look like they have a bad case of warts with lots of multiple packs on them...

Or, maybe it would be possible to take one of the existing packs and re-engineer it to have multiple chutes and actions such as the cut away and then deployment of next set of chutes.

Thanks for any information.

And if this is in the posts above, sorry.... I went through them, but might have missed it....

[stupid_chris]

Thank you, I just invented a new game:

"Kerbal Chicken"; how far up can I cut that chute and not destroy the lander.

That would sure be interesting

But in all seriousness the logic behind this is mostly for occurrences with multiple parachutes. For example you could have a drogue and a few mains and want the drogue to cut as soon as the main chute deploys. It could also serve on a single part with multiple parachutes, and have the first cut when the second deploys.

EDIT:

Is there any future plans to develop a stackable canister that could be filled with drogue and main's..?? I would be nice to be able to create a part that had say an initial high altitude drogue that would be cut and then set of mains or any combination thereof...

the capsules start to look like they have a bad case of warts with lots of multiple packs on them...

Or, maybe it would be possible to take one of the existing packs and re-engineer it to have multiple chutes and actions such as the cut away and then deployment of next set of chutes.

Thanks for any information.

And if this is in the posts above, sorry.... I went through them, but might have missed it....

This is precisely the aim of the cutAlt value. Technically, according to reports I've had, this is already possible. All you need is a part that has multiple parachute transforms on it and you can assign a RealChuteModule to each one of them . I don't think any part has this for now though. But yes, it is a possibility that we could add such a part in the pack eventually.

Edited November 14, 2013 by stupid_chris

[drtedastro]

stupid_chris, looks like i was typing same time as you....