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

[stupid_chris]

makes landing my spaceplanes so much easier on uneven terrain! pretty much anywhere that's not KSC

would you consider making the amount of deploys a parachute has available as a flowable resources with it's own canisters so we can restock our fully reusable missions?

thanks for the mod!

Something like this is planned, but not exactly by making them a "resource"

Thanks! That is exactly what I needed to know. Never used a mod quite like this before, but it definitely opens up a lot of options! I guess it is like I imagined it would be, and I can see how it allows for some very useful and effective management.

If you have other questions, make sure to check the posts linked in the OP of this thred, they'll usualy have the answers you need.

I am using the stack double chutes but only one of the chute full deploy the other one stay semy-deployed, they have same configuration

I know, other people reported that

[Starwaster]

Something like this is planned, but not exactly by making them a "resource"

So my dreams of 'Parachute in a Can' must remain unrealized?

[stupid_chris]

So my dreams of 'Parachute in a Can' must remain unrealized?

unlesss you thought of making the pod the can, yes, proably

[Aedile]

Okay first off, two things:

First, this new scheme is simple and user friendly. Staple the mod, select the size, select the texture, adjust if you need it. That's all.

I'm sorry to say, the old one was better. It just takes longer to configure now, and the old configuration was simpler, and more user friendly. It's not about how difficult to grasp it it is, it's about how long it takes you to do the same job. If it takes you longer, it's less 'user friendly'. Test how long it will take you to add single drogue chute -

old version - add chute, change predep/dep size

new version - add chute, go to AG, change part size, change textures, change model, change material, change 'must go down', change deployment size, change dep altitudes (or use auto and pray). One also must guess what the maximum values are.

The part size thing is mightily annoying, as the part might not fit. Also, "next size" makes part smaller ?!

The chute calculation doesn't really work with FAR, and the automatic, use vessel mass is kind of useless, as it of course uses the mass of the whole rocket (yes I realize you can use the manual, extra switching...).

Yes also you can't just copy a chute around without having to manually configure them again. In fact, all values from the dialog are cleared.

I'm not sure what leads you to believe the new UI is more user friendly.

I would suggest you add differently configured chutes as sub assemblies

[Aedile]

(edit again)

Is there a link between part size, weight and maximum diameter?

Seems deployment diameter and material and part size changes the mass.

The number of spare chutes does not??

Also what's the sense in using big chute case (for radials) if it cannot hold a bigger chute, than the much lighter smaller case?

Edited April 6, 2014 by Aedile

[CaptainKipard]

Chris could you write a guide or tutorial for all the tweakables with examples of usage?

[stupid_chris]

I'm sorry to say, the old one was better. It just takes longer to configure now, and the old configuration was simpler, and more user friendly. It's not about how difficult to grasp it it is, it's about how long it takes you to do the same job. If it takes you longer, it's less 'user friendly'. Test how long it will take you to add single drogue chute -

old version - add chute, change predep/dep size

new version - add chute, go to AG, change part size, change textures, change model, change material, change 'must go down', change deployment size, change dep altitudes (or use auto and pray). One also must guess what the maximum values are.

The part size thing is mightily annoying, as the part might not fit. Also, "next size" makes part smaller ?!

The chute calculation doesn't really work with FAR, and the automatic, use vessel mass is kind of useless, as it of course uses the mass of the whole rocket (yes I realize you can use the manual, extra switching...).

Yes also you can't just copy a chute around without having to manually configure them again. In fact, all values from the dialog are cleared.

I'm not sure what leads you to believe the new UI is more user friendly.

I would suggest you add differently configured chutes as sub assemblies

Okay let's go through that step by step.

"The part might not fit"? What? Just cycle through them until you find the one that fits. And as you noticed it says "next" size, not "bigger". Because it's cycling through the sizes, not searching for bigger or smaller.

The chute calculation works perfectly fine with FAR, I even took the time to message ferram inquiring about if my method would have any impact in a FAR environment. The chutes do not use stock drag at all, so FAR affects them for absolutely nothing.

The use of "automatic mass" is the best you'll get. Using stage mass would be horribly wrong, and manual mass means that you add them all yourself. The solution is to simply detach the extra, use the chute calculations tool, and reattach the rocket. Simple enough.

False, if you took the time to read the posts in the OP, you would know that it isn't true. IF you copy a part around, it keeps it's stats. The editor window shows blank fields because the initialization of copied parts is borked, and I cannot do anything about it.

If you want to have them as subassemblies, do it yourself, my mod is as is. At the base, this is something I did for myself. If you don't like it, don't use it.

(edit again)

Is there a link between part size, weight and maximum diameter?

Seems deployment diameter and material and part size changes the mass.

The number of spare chutes does not??

Also what's the sense in using big chute case (for radials) if it cannot hold a bigger chute, than the much lighter smaller case?

Yes, part size influences part weight, as well as diameter and material. No spares do not, and again if you would've read the information post, you would know it. It's something that I have yet to implement in a more complete way, and I don't have the time resources to implement it for now as a placeholder that I would be to promptly change. The spare chutes are not going to be in the parachutes themselves soon enough, they'll be in pods, and they'll have a mass when they are.

AS for the cases, this is /also to change/. I'm still working on this, it's on my todolist, I just haven't gotten to it because I'm busy being a college student trying to pass his semester.

Chris could you write a guide or tutorial for all the tweakables with examples of usage?

This is also something that I am working on, I have written the first parts of a wiki but had to stop because of my midterms. I'll complete it ASAP

Now, a simple note:

When you guys have comments to do about the mod, don't take the passive-agressive tone. It's gonna put me off, and probably you too, and it's not fun for anyone. Inform yourself, read the posts I leave lying around in the OP, read the FAQ, etc. If I don,t agree with you, don't rant off, you'll lose me.

I didn't want to have to make such an announcement, but it seems I have to, because the amount of posts with this tone lately is growing very fast. Even though there is no more "WIP" tag in the title, this mod is still in development. I removed it because I have reached the original scope I planned for this. Everything I'm adding from now on is extra candy because I feel like it, I like doing this, and because I want to give you guys the best. If I stop having fun doing this because the feedback I get is that I'm not working fast enough or that I'm not doing what you think I should do, and that therefore I'm in the wrong, I'll simply stop updating this and do it for myself in my free time.

Don't take this wrong, I do want feedback. What I don't want is feedback that makes me feel attacked and that forces me to do posts like this where I need to defend myself. Criticism is alright, as long as you understand that I'm perfectly in the means of having a different opinion, and that at the end it belongs to me to see what I will/will not do. As far as I know, I've been pretty ongoing on that and I've added most of - if not everything- that you guys proposed.

Thank you.

Edited April 7, 2014 by stupid_chris

[Taki117]

I like this mod, and I haven't been having any troubles with it at all since the update. Thank you Chris!

[Drew Kerman]

I've been waiting for an update to make sure this issue hadn't been reported and handled, but I'm still seeing it. VAB/SPH when I use symmetry to add chutes (like 2 radial chutes on either side of a capsule) only the chute placed under my mouse cursor gets the convenient default settings. I have to manually copy over the settings to the other chute(s) - they all have must go down set to false, and all text fields except those in the weight calculation box are empty. Apply to symmetry counterparts only affects the following things like so:

target planet - not applied

part size - applied

case texture - applied

chute texture - applied

chute model - applied

material - not applied

must go down - not applied

deployment timer - not applied

spare chutes - not applied

autocut speed - not applied

calc mode - not applied

calc main/drogue/drag buttons - applied

craft mass type - not applied

mass calc text fields - none applied

press/alt deploy - not applied

deploy fields - none applied

I did find that since the three chute type chute size calculation buttons work, the three fields they adjust in the deployment settings also properly sync up with "apply symmetry" - but only if the buttons change the fields, not me.

Also, since the dialog is telling me I have x amount of symmetric parts, shouldn't the "Parachutes Used" field load with that number as default? Or am I interpreting that field wrong? Does it relate instead to the Single/Triple chute option? If so, how come clicking those buttons doesn't change this value - the fact that it's not hard locked to 1 or 3 makes me believe its the number of parachute parts you're having deploy at the same time.

finally, I can't see an "arm chute" option in the action menu, although I wonder if this is because I enabled chute arming via staging. If so, I'd also still like to be able to do this via an action group as well

[stupid_chris]

I've been waiting for an update to make sure this issue hadn't been reported and handled, but I'm still seeing it. VAB/SPH when I use symmetry to add chutes (like 2 radial chutes on either side of a capsule) only the chute placed under my mouse cursor gets the convenient default settings. I have to manually copy over the settings to the other chute(s) - they all have must go down set to false, and all text fields except those in the weight calculation box are empty. Apply to symmetry counterparts only affects the following things like so:

target planet - not applied

part size - applied

case texture - applied

chute texture - applied

chute model - applied

material - not applied

must go down - not applied

deployment timer - not applied

spare chutes - not applied

autocut speed - not applied

calc mode - not applied

calc main/drogue/drag buttons - applied

craft mass type - not applied

mass calc text fields - none applied

press/alt deploy - not applied

deploy fields - none applied

I did find that since the three chute type chute size calculation buttons work, the three fields they adjust in the deployment settings also properly sync up with "apply symmetry" - but only if the buttons change the fields, not me.

It doesn't copy the fields, I've said it a few times now, and it's also mentioned in the posts in the first page. Don't worry, the values do transpose, just not the fields. So click "apply to symmetry counterparts" and carry on.

Also, since the dialog is telling me I have x amount of symmetric parts, shouldn't the "Parachutes Used" field load with that number as default? Or am I interpreting that field wrong? Does it relate instead to the Single/Triple chute option? If so, how come clicking those buttons doesn't change this value - the fact that it's not hard locked to 1 or 3 makes me believe its the number of parachute parts you're having deploy at the same time.

It refers to (parts) as said right next to it, and yes, this is something that will be bundled in next update.

finally, I can't see an "arm chute" option in the action menu, although I wonder if this is because I enabled chute arming via staging. If so, I'd also still like to be able to do this via an action group as well

Yep, if you arm through staging this action group dissapears, because it would do the same as "deploy". So Map "Deploy parachute" and it will arm.

[drtedastro]

Hello Chris.... Does this version have the hooks in it to trigger the drogue on wheels down?? and then cut away at some small m/s????

thanks.

DrTedAstro..

[stupid_chris]

Hello Chris.... Does this version have the hooks in it to trigger the drogue on wheels down?? and then cut away at some small m/s????

thanks.

DrTedAstro..

Nope not yet, but it's planned for next shot

[Aedile]

Okay let's go through that step by step.

"The part might not fit"? What? Just cycle through them until you find the one that fits. And as you noticed it says "next" size, not "bigger". Because it's cycling through the sizes, not searching for bigger or smaller.

The chute calculation works perfectly fine with FAR, I even took the time to message ferram inquiring about if my method would have any impact in a FAR environment. The chutes do not use stock drag at all, so FAR affects them for absolutely nothing.

The use of "automatic mass" is the best you'll get. Using stage mass would be horribly wrong, and manual mass means that you add them all yourself. The solution is to simply detach the extra, use the chute calculations tool, and reattach the rocket. Simple enough.

False, if you took the time to read the posts in the OP, you would know that it isn't true. IF you copy a part around, it keeps it's stats. The editor window shows blank fields because the initialization of copied parts is borked, and I cannot do anything about it.

If you want to have them as subassemblies, do it yourself, my mod is as is. At the base, this is something I did for myself. If you don't like it, don't use it.

Yes, part size influences part weight, as well as diameter and material. No spares do not, and again if you would've read the information post, you would know it. It's something that I have yet to implement in a more complete way, and I don't have the time resources to implement it for now as a placeholder that I would be to promptly change. The spare chutes are not going to be in the parachutes themselves soon enough, they'll be in pods, and they'll have a mass when they are.

AS for the cases, this is /also to change/. I'm still working on this, it's on my todolist, I just haven't gotten to it because I'm busy being a college student trying to pass his semester.

This is also something that I am working on, I have written the first parts of a wiki but had to stop because of my midterms. I'll complete it ASAP

Now, a simple note:

When you guys have comments to do about the mod, don't take the passive-agressive tone. It's gonna put me off, and probably you too, and it's not fun for anyone. Inform yourself, read the posts I leave lying around in the OP, read the FAQ, etc. If I don,t agree with you, don't rant off, you'll lose me.

I didn't want to have to make such an announcement, but it seems I have to, because the amount of posts with this tone lately is growing very fast. Even though there is no more "WIP" tag in the title, this mod is still in development. I removed it because I have reached the original scope I planned for this. Everything I'm adding from now on is extra candy because I feel like it, I like doing this, and because I want to give you guys the best. If I stop having fun doing this because the feedback I get is that I'm not working fast enough or that I'm not doing what you think I should do, and that therefore I'm in the wrong, I'll simply stop updating this and do it for myself in my free time.

Don't take this wrong, I do want feedback. What I don't want is feedback that makes me feel attacked and that forces me to do posts like this where I need to defend myself. Criticism is alright, as long as you understand that I'm perfectly in the means of having a different opinion, and that at the end it belongs to me to see what I will/will not do. As far as I know, I've been pretty ongoing on that and I've added most of - if not everything- that you guys proposed.

Thank you.

First there is no need to get defensive, I am not attacking you. Unless you consider difference of opinion an attack.

You claim the current ui is more user friendly, and it is not, as it takes you longer to accomplish the same task. You can dismiss that as a rant, but the new ui takes more time, there is more chance for misconfiguration (error), and requires more knowledge. Not many people realize how to build a chute from scratch, for example what material to use for drogue, drag etc. If your new design requires 'read the manual' and the old one did not, what does that tell you about user friendliness? And manual is not exactly ready is it? So where else I could get this information other than ask here? I don't recall being here at version 0.3 asking stupid questions - because things were rather obvious.

It does give you more options which I appreciate, there is a workaround with the sub-assemblies, so not that big of a deal, yet less 'user friendly'. This is why I suggested adding some sub assemblies, so people can go and test them in sandbox, or copy over to their game. I am perfectly capable of adding them, and would have offered to provide them so you don't need to lose your own time, but fair enough, if this would somehow ruin your mod, I won't argue.

Now about the part size -

I'm pretty sure you are aware of the issue when using symmetry. You can't do that anymore, at least I am unable to even put the smallest cone on a 2.5 side boosters. Yes I know I can build a single one and then symmetry the whole booster.

About the 'next' size - most of us think of next size as a bigger size. This is for two reasons, most of us count up, and you unlock bigger sizes later. Also in most cultures which write left to right, next is to be placed on the right, it's more intuitive. Both easily fixed with changing the labels.

The calculation does not seem to work very well, I assumed is FAR issue. Still, hit the ground at 12m/s instead of 5m/s. Perhaps was simply coming in too hot. Landing happened at around 1400m, return from LKO. Does atmospheric density affect drag? Do I need to compensate for elevation?

The copying part around - while a copied part keeps the stats, further modification, requires you to enter each and every stat, as the UI cannot pick them up. Which I personally consider less user friendly than the stock tweakables in the 0.3 versions. Consider a case where you add a radial chute to one stage, configure it's properties, copy it to another, and want to tweak something - well you cannot - while you could do that with previous parts. Hence my comment - it was better before. Here you can use subassembly as well with various results.

You also need to remember which one is your original when using symmetry, and which are the copies. I know this is ksp limitation, modular fuels have the same issue. Dare I suggest you add that in the list of known issues?

About the weight - I did not see anything about the case size/max diameter/spares and how they affect weight, or your further implementation plans in the area. A simple 'it's on my to do list', would have done nicely. What information post mentioning this I seem to have missed? It's not in the first post of the this or the dev thread (or its very well burred), so not sure why you feel the need to imply I'm lazy or ignorant, and go on to lecture me about being aggressive. Perhaps your energy is better spent on amending the information. OP information which isn't exactly correct - for example says selecting a drogue chute gives you exactly the same chute as before - well sure except it gives you main chute look, and material. Not that it makes so much difference in behavior other than drag and weight, the autocalc compensates for the most part.

To answer my own question, in case someone else is wondering.

Currently, in my experience

In case of radials, use the smallest case possible, as it fits the same chute, it's lighter, and presents less surface in case of FAR - deadly reentry.

For cones use the one which fits your node, if aerodynamics aesthetics matter more than weight.

It's unknown to me whether or not bigger case has less chance to break, or if chutes break at all (guessing from the OP they don't, I haven't tested that as I have deadly reentry, and will peak G forces/heat before the joint or chute breaks).

This would likely change in the future.

Also combo chute, will not warn you if your craft is too heavy if, your first chute is main and the second drogue - which happens to be it's default configuration. Reversing them gives warning, but the second chute won't fully deploy. So don't have secondary chute open second.

As a unrelated note, what would be pretty nice (especially for drogue chutes), would be option to have a deployment speed, for example, deploy when speed falls under 400m/s. Pre-deploying auto-calculated drogue at the default 30k tends to result in 8-9g.

Not sure on what max diameter is based, I have managed to set cone to either 121 or 70m, any insight on that?

It's an honest feedback. In any case, since you seem find all this insulting, I'll go do something less futile.

[stupid_chris]

First there is no need to get defensive, I am not attacking you. Unless you consider difference of opinion an attack.

The tone you are taking is what forces me to fall back and defend myself. If instead of enumerating how wrong I am, and ask polite questions since you "don't know" as you say many times below, maybe you would have better results.

You claim the current ui is more user friendly, and it is not, as it takes you longer to accomplish the same task. You can dismiss that as a rant, but the new ui takes more time, there is more chance for misconfiguration (error), and requires more knowledge. Not many people realize how to build a chute from scratch, for example what material to use for drogue, drag etc. If your new design requires 'read the manual' and the old one did not, what does that tell you about user friendliness? And manual is not exactly ready is it? So where else I could get this information other than ask here? I don't recall being here at version 0.3 asking stupid questions - because things were rather obvious.

Most of the information is available in the thread, and in the two linked posts in the OP, as I have mentioned many times.

It does give you more options which I appreciate, there is a workaround with the sub-assemblies, so not that big of a deal, yet less 'user friendly'. This is why I suggested adding some sub assemblies, so people can go and test them in sandbox, or copy over to their game. I am perfectly capable of adding them, and would have offered to provide them so you don't need to lose your own time, but fair enough, if this would somehow ruin your mod, I won't argue.

Subassemblies work for parts that can be root parts, and this is only true for the stack chutes.

Now about the part size -

I'm pretty sure you are aware of the issue when using symmetry. You can't do that anymore, at least I am unable to even put the smallest cone on a 2.5 side boosters. Yes I know I can build a single one and then symmetry the whole booster.

I literally answered that question on the previous page. This is not in my court, this is KSP detecting bad collisions. Simply turn on part clipping, or, do as starwaster said, and press x while hovering with the chutes on the boosters to fix it.

About the 'next' size - most of us think of next size as a bigger size. This is for two reasons, most of us count up, and you unlock bigger sizes later. Also in most cultures which write left to right, next is to be placed on the right, it's more intuitive. Both easily fixed with changing the labels.

Unfortunately, you'll realize that next size gives larger radials and smaller cones. I'll try to mess with the sizes in the config.

The calculation does not seem to work very well, I assumed is FAR issue. Still, hit the ground at 12m/s instead of 5m/s. Perhaps was simply coming in too hot. Landing happened at around 1400m, return from LKO. Does atmospheric density affect drag? Do I need to compensate for elevation?

Drag is directly dependant of atmospheric density. The calculations work, but if FAR changes the density, it will act differently. Last I asked this would not be a problem.

The copying part around - while a copied part keeps the stats, further modification, requires you to enter each and every stat, as the UI cannot pick them up. Which I personally consider less user friendly than the stock tweakables in the 0.3 versions. Consider a case where you add a radial chute to one stage, configure it's properties, copy it to another, and want to tweak something - well you cannot - while you could do that with previous parts. Hence my comment - it was better before. Here you can use subassembly as well with various results.

You also need to remember which one is your original when using symmetry, and which are the copies. I know this is ksp limitation, modular fuels have the same issue. Dare I suggest you add that in the list of known issues?

It's not very hard to find out which on you placed first. I'll leave a note in the OP about it, and I do have a workaround in mind, but for now it'll have to be this way.

About the weight - I did not see anything about the case size/max diameter/spares and how they affect weight, or your further implementation plans in the area. A simple 'it's on my to do list', would have done nicely. What information post mentioning this I seem to have missed? It's not in the first post of the this or the dev thread (or its very well burred), so not sure why you feel the need to imply I'm lazy or ignorant, and go on to lecture me about being aggressive. Perhaps your energy is better spent on amending the information. OP information which isn't exactly correct - for example says selecting a drogue chute gives you exactly the same chute as before - well sure except it gives you main chute look, and material. Not that it makes so much difference in behavior other than drag and weight, the autocalc compensates for the most part.

As far as I know it's in the posts linked in the OP. Else pardon me if it isn't, I thought it was.

Also combo chute, will not warn you if your craft is too heavy if, your first chute is main and the second drogue - which happens to be it's default configuration. Reversing them gives warning, but the second chute won't fully deploy. So don't have secondary chute open second.

There is a bug with the secondary chute in the current version, that's all. However I have pinned it down and fixed it here.

As a unrelated note, what would be pretty nice (especially for drogue chutes), would be option to have a deployment speed, for example, deploy when speed falls under 400m/s. Pre-deploying auto-calculated drogue at the default 30k tends to result in 8-9g.

I can see about it.

Not sure on what max diameter is based, I have managed to set cone to either 121 or 70m, any insight on that?

It's based on the canopy. Basically, each canopy can be of 70m in diameters. For the triple chute, three canopies of 70m in diameters is the equivalent of one giant 121m canopy. It's set in the TextureLibrary config.

It's an honest feedback. In any case, since you seem find all this insulting, I'll go do something less futile.

Again, as I said at first, the feedback is far from the problem, but the tone you are taking and the passive-agressivity is very annoying, and it's not something I need, I have enough stressful things to manage like that, I don't want to be worrying when I open the forum that someone else might be pooping a brick house in my thread again.

Edited April 7, 2014 by stupid_chris

[Starwaster]

Drag is directly dependant of atmospheric density. The calculations work, but if FAR changes the density, it will act differently. Last I asked this would not be a problem.

I've actually had a concern recently about this. It's been a few versions since I glanced at either your code or Ferram's so maybe something's changed I don't know about, but FAR recently started calculating density based on assigned atmospheric composition. I didn't even think of this until someone mentioned it in the RSS thread, but to cite the example given there, Venus has an atmospheric pressure of almost 90 atm. But its density is only about 55x Earth's. (assuming this is the lack of nitrogen at work).

The very latest RSS tries to model Eve's atmosphere based on Venus and has a pressure value of 90 now. (we're using pressureCurve data instead of the old legacy atmosphere calculations). Pretty sure FAR can handle drag appropriately since it calculates density separately but how will this affect Real Chutes? Can it actually query FAR on density values? And does it?

[stupid_chris]

I've actually had a concern recently about this. It's been a few versions since I glanced at either your code or Ferram's so maybe something's changed I don't know about, but FAR recently started calculating density based on assigned atmospheric composition. I didn't even think of this until someone mentioned it in the RSS thread, but to cite the example given there, Venus has an atmospheric pressure of almost 90 atm. But its density is only about 55x Earth's. (assuming this is the lack of nitrogen at work).

The very latest RSS tries to model Eve's atmosphere based on Venus and has a pressure value of 90 now. (we're using pressureCurve data instead of the old legacy atmosphere calculations). Pretty sure FAR can handle drag appropriately since it calculates density separately but how will this affect Real Chutes? Can it actually query FAR on density values? And does it?

I'm querying the stock values for now, but when I spoke to ferram (it was a while ago) this didn't seem to be a problem. If it changed I might have to query them if FAR is present.

[OrbitalSolutionsLtd]

I have a little problem, some of the parts do not show in the editor, even though I unlocked them in the R&D building. I only have two 1.75m Cones, one inline chute and one radial chute. Maybe I did something bad ?

[stupid_chris]

I have a little problem, some of the parts do not show in the editor, even though I unlocked them in the R&D building. I only have two 1.75m Cones, one inline chute and one radial chute. Maybe I did something bad ?

See the posts in the OP

[Starstrider42]

Hi,

Two questions, neither of which I found in the OP or a forum search:

1. Is there a way to change the default values for the parachutes? I'm using DRE, and the default predeployment height of 20 km is infernally high (pun intended) with that mod. At the moment, I'm working around it by tweaking the parachutes on every ship, but it would be nice if I could do it just once and have it apply to all future ships.
   
2. If I'm using Stock_RealChute_MM.cfg, is there any difference between the stock and RC parachutes other than the former having fewer tweakable options? Is there a specific case where I'd want to use the RC-ified stock chutes?
   

Thanks!

[stupid_chris]

Hi,

Two questions, neither of which I found in the OP or a forum search:

1. Is there a way to change the default values for the parachutes? I'm using DRE, and the default predeployment height of 20 km is infernally high (pun intended) with that mod. At the moment, I'm working around it by tweaking the parachutes on every ship, but it would be nice if I could do it just once and have it apply to all future ships.
   
2. If I'm using Stock_RealChute_MM.cfg, is there any difference between the stock and RC parachutes other than the former having fewer tweakable options? Is there a specific case where I'd want to use the RC-ified stock chutes?
   

Thanks!

For the first one, you need to do it in the part configs. That's the only way to permanently change a part's behaviour.

For the second, the module manager configs are simply to have the RealChute behaviour on stock parts for those who don't like the RC parts/have ships using stock parts. It's not a question of advantages/disadvantages really.

[Starstrider42]

For the first one, you need to do it in the part configs. That's the only way to permanently change a part's behaviour.

For the second, the module manager configs are simply to have the RealChute behaviour on stock parts for those who don't like the RC parts/have ships using stock parts. It's not a question of advantages/disadvantages really.

Ok, that's about what I expected. Thanks!

[ctbram]

I apologise if this question has been asked but I tried searching and could not find an answer and with over 1200+ posts I just gave up.

I have a mk1-2 pod (the 2.5m 3-man) and I attached the abort sequence to an action group. after abort I press the 8-key and the tower should decouple and the three radial chutes deploy. When I click on the chute in the action group editor I get a very scary looking dialogue that pops up with all kind of rocket scientist buttons and dials and switches and lights and boxes to type in numbers and such; not knowing what any of them do I just left them all alone and selected deploy.

When I test it on the pad the tower decouples and the chutes appear to pre-deploy but never fully deploy before my three man crew sadly smash to the ground and die.

Can someone tell me what I need to do to have these work for both coming home from space and having to deploy in an emergancy?

[stupid_chris]

I apologise if this question has been asked but I tried searching and could not find an answer and with over 1200+ posts I just gave up.

I have a mk1-2 pod (the 2.5m 3-man) and I attached the abort sequence to an action group. after abort I press the 8-key and the tower should decouple and the three radial chutes deploy. When I click on the chute in the action group editor I get a very scary looking dialogue that pops up with all kind of rocket scientist buttons and dials and switches and lights and boxes to type in numbers and such; not knowing what any of them do I just left them all alone and selected deploy.

When I test it on the pad the tower decouples and the chutes appear to pre-deploy but never fully deploy before my three man crew sadly smash to the ground and die.

Can someone tell me what I need to do to have these work for both coming home from space and having to deploy in an emergancy?

What is most likely happening is that they don't have the time do deploy.

If you were indeed using the radials, then it should work properly. However, as they are currently set, the whole deployment process would take eight seconds. What you might want to do is open the scary dialog, and scroll to find "Deployment speed (s)" and lower it. It should initially be at 6. Lowering it to 3-4s should give them the time to deploy. Then all you need to do is press "apply to symmetry counterparts" and you should be good to go.

But this is only a problem near the ground. If you actually have some vertical velocity, they'll most likely have the time to deploy.

[fede16071995]

hi, good mod i really like it. my only problem is that the secondary pair of chutes does not have a texture and it seems that they don't have a deploy animation, is that right or its just me ?

[stupid_chris]

hi, good mod i really like it. my only problem is that the secondary pair of chutes does not have a texture and it seems that they don't have a deploy animation, is that right or its just me ?

yeah it's a bug in the current version on stack chutes.