Jump to content

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


stupid_chris

Recommended Posts

Great work, as always! Does the new gradual deployment prevent the chutes from tearing off when in full physics warp? If not, I saw a suggestion once to have parachutes opening automatically switch to 1x time warp.

A few other possibilities if you're looking to expand your roadmap:

  • Customisable canopy appearance via image file changing or an in-game selector like flags use.
  • A "damaged" state on collision (like wheels have), similar in appearance/performance to the semi-deployed state.
  • Have the chute cover jettisoned as a non-persistent model (like breaking solar panels), instead of just disappearing on deployment.

Link to comment
Share on other sites

A "damaged" state on collision (like wheels have), similar in appearance/performance to the semi-deployed state.

I did mod one of KSP textures a while back for a damaged chute, but didn't have the skills to write a plugin for it.

I was thinking if you deploy the chute above a certain speed or too soon during reentry, you get this damaged chute with less drag.

Stupid_Chris, you can have the texture, but I imagine you have better source for textures than me.

hruYaNt.png

Link to comment
Share on other sites

If this is a "realistic parachutes" mod, shouldn't you have them spread apart rather than clip into eachother, and to tangle or fail to inflate if they cannot do so?

That's something which always bothered me, that you could put forty chutes right next to eachother and it'd work fine.

This sounds tricky. True, you could measure the chute case's distance radially from the COM, perpendicular to vector of motion, then spread the angle of the graphics of the chutes based on this number. However people often stack the chute pods vertically as well on a ship, and these would still clash. You could stretch the chutes vertically, meaning the spread of them would be a multiple of whatever the physical spread is of the pods they come from, but something tells me it will be hard to get something that still looks good and stop ANY collision of chutes. There are just too many ways to mount them.

Link to comment
Share on other sites

... but something tells me it will be hard to get something that still looks good and stop ANY collision of chutes. There are just too many ways to mount them.

BobCat's solution was making a parachute model that simply included multiple non-overlapping canopies.

This might be the way to go.

Link to comment
Share on other sites

This sounds tricky. True, you could measure the chute case's distance radially from the COM, perpendicular to vector of motion, then spread the angle of the graphics of the chutes based on this number.

Why not set the chutes and their ropes up for collision, filtering it so they only collide with each other if necessary? Let the physics work out where they should end up.

For more fun (and zero FPS), there's cloth physics.

Link to comment
Share on other sites

Can we also have the other way around for deployment rules?

[...]

Is there a way to have both deployment and inflate based of pressure? (I know this would make eve boring but I am not debating that now and it can e resolved with smaller chutes anyway)

I feel a realistic parachute mod should do this. A parachute could not care less about altitude, its behaviour is dictated by the air/gasses it encounters on the way down. It would only make sense to adapt these parachutes accordingly. Realism is not always convenient :D

Link to comment
Share on other sites

You'd have to be careful with that. If it's solely based on pressure the 'fully deployed' status could be a kicker. Land on a high mountain and it might not fully deploy before you hit the ground!

Thinking about it, with a more sharp difference between drogue and full chutes, as long as full chutes deploy higher than any terrain feature it would work. Deploy drogues high, wait till you're near the ground, then deploy the full chutes

Edited by Patupi
Link to comment
Share on other sites

While atmospheric pressure is a component of how chute reefing is determined, it's not the only factor. In fact, it's the reduction in pressure as the vehicle the chute is attached to slows that allows the chute to fully open as the pressure of the air rushing past the outside of the envelope becomes sufficiently low to allow the ram pressure inside the envelope to reef the parachute fully. By changing how the risers are arranged, the material, and the stitching of the envelope, the designers can create "staged" reefing to allow for a single parachute to act both as a drogue and a main. For higher speeds, use of a "reefing ring" on the risers has been used in the past to do the same as the pressure against the ring will "cinch" the risers and prevent the chute from attempting to reef at too high of a speed. The most notable user of this system is the Ballistic Recovery System on the Cirrus airplanes, but it's been used on experimental recovery systems as well.

Basically though, unless you're dynamically simulating the atmosphere of every planet/planetoid/moon in KSP, trying to use pressure/speed to determine the reefing characteristics of a chute is pointless because the data needed to do it right simply isn't generated by the game and would thus require external input to do and with the demand on the processor as high as it is, especially with large craft, I think that will only result in an undesirable reduction in performance.

Link to comment
Share on other sites

Very nice, hopefully no more getting my lander ripped in half when the chute deploys in Eve's thick atmosphere.

This is a question not a request.

Is it possible to model a steerable parafoil that trades some of it's downward vertical speed for forward motion in a simple plugin, or is it something that would take a lot of coding?

http://en.wikipedia.org/wiki/Parafoil

You're not the first to ask this, and to answer frankly: totally out of my domain. Someone could perhaps do this, but lift aerodynamics is complete nonesense to me and I suspect stock lift aerodynamics will be far worse. This plugin is free to be forked so someone who knows that stuff better could do that, i.e. ferram or another modder that already deals with that stuff.

Can we also have the other way around for deployment rules?

That is:

Stock has deployment by pressure and inflate by true altitude

Mod has deployment and inflate both by true altitude.

Is there a way to have both deployment and inflate based of pressure? (I know this would make eve boring but I am not debating that now and it can e resolved with smaller chutes anyway)

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.

If this is a "realistic parachutes" mod, shouldn't you have them spread apart rather than clip into eachother, and to tangle or fail to inflate if they cannot do so?

That's something which always bothered me, that you could put forty chutes right next to eachother and it'd work fine.

I'm aware and you aren't the first to propose either. This is a big "maybe" for now. This sounds much harder than the stuff I did so far but it's at the end of the roadmap. I might add it when I'm done with the main of the plugin.

So they will open in even the tiniest/thinnest bit of air?

If you are under the required altitude, yes.

Can you modify the properties, so the parachutes only opens if the root part is moving downwards if I want them to do so?

Mind you expand on that idea, not really seeing the utility of this :/

Is it FAR compatible? This looks great, I especially like the idea of parachutes not magically disappearing on the ground. Plane landings in rough terrain about to get a lot better.

I haven't tested it yet in FAR, but if stock parachutes work in FAR, this does for sure.

Great work, as always! Does the new gradual deployment prevent the chutes from tearing off when in full physics warp? If not, I saw a suggestion once to have parachutes opening automatically switch to 1x time warp.

I haven't tested it, but most likely it won't break :) And someone did a plugin just a few days ago to do exactly this, reduce time warp before chutes deploy.

A few other possibilities if you're looking to expand your roadmap:

  • Customisable canopy appearance via image file changing or an in-game selector like flags use.
  • A "damaged" state on collision (like wheels have), similar in appearance/performance to the semi-deployed state.
  • Have the chute cover jettisoned as a non-persistent model (like breaking solar panels), instead of just disappearing on deployment.

That could be added someday. I could add this at the end of the current roadmap.

I did mod one of KSP textures a while back for a damaged chute, but didn't have the skills to write a plugin for it.

I was thinking if you deploy the chute above a certain speed or too soon during reentry, you get this damaged chute with less drag.

Stupid_Chris, you can have the texture, but I imagine you have better source for textures than me.

-snip-

Aye, this could be manageable. For now me and sumghai are talking about models and textures for this, however parachutes work in a weird way, I'll explain below.

Do you think you could add the ability to fire landing rockets at, for example 15 meters AGL ?

That would be for a whole new mod, the aim of this is parachutes themselves.

Why not set the chutes and their ropes up for collision, filtering it so they only collide with each other if necessary? Let the physics work out where they should end up.

For more fun (and zero FPS), there's cloth physics.

Parachutes aren't models, they are transforms. I don't think you can add colliders to them. And cloth physics would be /bad/ for KSP.

Myself I would really like the radio altimeter to activate the chute but that it would not fully open until the air pressure got high enough. Maybe a toggle for both? pressure/altimeter?

Well I could add an if pressure is high enough AND altitude is low enough, but not one or another, because depending on the body you land on this might end up very badly.

EDIT:

Basically though, unless you're dynamically simulating the atmosphere of every planet/planetoid/moon in KSP, trying to use pressure/speed to determine the reefing characteristics of a chute is pointless because the data needed to do it right simply isn't generated by the game and would thus require external input to do and with the demand on the processor as high as it is, especially with large craft, I think that will only result in an undesirable reduction in performance.

That is also what I thought. Parachutes are more complex than they look like, my goal is to make parachutes more realistic by simulating realistic deployment without faring too far away from gameplay and stock behaviour. I'm not trying to do a full reality mod like FAR or the realistic solar system mod, or even like RemoteTech, I'm just trying to improve general gameplay and making the parachutes behave in a more conventional way.

Alright, about parachutes:

A parachutes is made of three things:

First theres the base. This is a model, with a collision box and all.

Then there's the canopy. This is a transform, it does not have a collision box and my knowledge about modeling is null, so I have no idea if it can have one.

Third is the cap, which is ALSO a transform. It can't just be jettisoned like this unfortunately.

My goal with this mod is not to improve the stock, not to recreate parachutes. So for this, I need it to be compatible with the stock module, so modders can create parachutes just like they used to and add this module to it. This limits the possibilities because of how parachutes are made in stock, but for now I do not intend to change the way parachutes fundamentally work.

See here for more details.

Also, thank you everyone for the feedback, this is greatly appreciated :D

Edited by stupid_chris
Link to comment
Share on other sites

For FAR compatibility, set stowedDrag to 0.

True much, the 0.22 is to keep the pod oriented correctly. Since FAR does this itself there's no need to have that. I'll add this to the OP.

Also, tonight I'll be uploading a few ModuleManager files to add stock and mod compatibilities and probably a new version of the plugin with very minor fixes. I might also be writing a small guide to explain the differences with stock and how to use some of the features, some sort of FAQ. Still at school, though, so tonight heh.

Link to comment
Share on other sites

AWESOME! thank you thank you thank you. I'm adding this to my FAR, DE, RT2 "realizim" save right now.

I think you might want to hold that yet, I'm getting reports that it might not be compatible yet with FAR. I'll inquire about it with ferram, I'm not a FAR user and I'm unfamiliar with how it makes parachutes work.

Link to comment
Share on other sites

I think you might want to hold that yet, I'm getting reports that it might not be compatible yet with FAR. I'll inquire about it with ferram, I'm not a FAR user and I'm unfamiliar with how it makes parachutes work.

My first test with the small main chute worked... I'll keep testing.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...