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

[AxleGreaser]

i have weird issue that i have perhaps nailed down. (in a way that could be found and corrected)

(first let me caveat this with Im running a lot of (mainly mainstream tweak MKS, KAC scansat, EVE, scatterer, ... yadda ) mods not all of which are labelled as 1.9 compliant)

(AND some ship configurations with a range of masses and part counts also do NOT exhibit this behavior)(I will start checking the bounds boxes of those when i can)

 

Sometimes when returning from space, and I think its only when splashing down as its never happened on land.

The chutes cut out early and drop me from 10m or so. result ship shattering kaboom.

Same SHIP,  same quicksave, EVA once speed is low (chutes fully open) disassemble a few parts (specifically the engine...) get back in... stage via a decoupler, the fuel tank I was only keeping for its recovery value. no problems....

but heres the weird bit where i may have found what seems to be the identifying part of the issue. 9adn hence makes it maybe a realchute addressable issue)

I also am running kOS, and happened to have this script

https://ksp-kos.github.io/KOS/tutorials/display_bounds.html#display-bounds

lying around and so out of an abundance of curiosity I ran it.

The chutes fail not just at about 10m above the water The chutes fail when the lower edge of the bounding box of the radial chute [part] (not just the whole ship)(but it also happens to be the bottom edge of the ship) touches the water.

The bound box of the radial chute extends multiple meters below the ship COM or the lowest part. When i excise(remove) both the motor and the fuel tank

the chute now 'correctly' checks and cuts when some part of the ship that is not a chute bounding box, touches the water. (which IMO is still 'early' but usually survivable.)

FYI: My radial chutes are resized to 70m kevlar (touchdown speed would be sub 3m/s about 2.9)(auo cut is set wayyyyy low at 0.01 or whatever the smallest i can set)

I can possibly (with time and effort) manually edit the many meg saved file with circa 100 ships down to something manageable and reproducible if its required and useful.

 

Also while I am here. Is it a 'feature' or a bug that chutes cut out on splash down contact not when the ship has sunk far enough for the boyancy forces to equilibrate?

 

 

Edited June 11, 2020 by AxleGreaser
reviewed for clarity/extra detailness.

[stupid_chris]

3 hours ago, AxleGreaser said:

 

The bound box of the radial chute extends multiple meters below the ship COM or the lowest part. When i excise(remove) both the motor and the fuel tank

the chute now 'correctly' checks and cuts when some part of the ship that is not a chute bounding box, touches the water. (which IMO is still 'early' but usually survivable.)

That seems to point that a mod you're using is messing with the parachute's collider. Can't help you with this, they are working fine under normal circumstances.

4 hours ago, AxleGreaser said:

Also while I am here. Is it a 'feature' or a bug that chutes cut out on splash down contact not when the ship has sunk far enough for the boyancy forces to equilibrate?

Parachutes cut when the ship they are flying on gets in contact with water or ground, and the ship moves under a specified speed. It's intended.

[AxleGreaser]

3 hours ago, stupid_chris said:

That seems to point that a mod you're using is messing with the parachute's collider. Can't help you with this, they are working fine under normal circumstances.

ta I will see if i can work that out.  (It does seem to only happen when I am in complex game mode doing real missions.. which is a tad frustrating. I was mainly hoping that if I mentioned bounding boxes if there was problem a light would come on.)

I am apparently n going to need to get into modding.... And compiling and debugging my own code. My game just went next level.

I accept your your next anwser. (it is intended behavior)

(I am even open to the idea that fixing it would make the game like too easy and less explosive. (less fun)) but tell you that a place where I will be investigating the physics of chutes once I get my dev environment up to speed. My be i will find something helpful or improving.

That said:

I suspect my description of what i see wasn't detailed enough.  I am also possibly wrong in that  it may not be chutes cutting that drops me in the water but chutes failing... I think it says they failed, but that they failed just as all the forces started rapidly decreasing always made so little physics sense, (the physicist in me) kind of just ignored that fleeting displayed text.  perhaps... what I am seeing is the chutes deciding they failed due the very fist physics tick of the craft decelerating on water contact? (AKA if it looks like a massive force on the craft so the chutes fail...) Indeed now that i think about it as 'code' rather than physics. It may even be that unity set the speed to zero on water contact and then starts the bouyancy simulation from there?. GAK knows,     All i know is the ship behaves in very non (human)physics like way and cuts(breaks?fails) the chute at time when I know for sure the speed in real physics would still be circa 1-2ms/ while the auto cut speed is 0.001 m/s and the chutes also will have just started getting decreasing not increasing forces so they ought to be the opposite of likely to fail.

I can however see that the velocity direction may change pretty damn fast once in contact with water contact and chutes don't cope with or simulate that very realistically.

basically many hours of fruitful programming ahead of me and white box debugging once I open the lid of the mods code. And stick in some judicious printf... debugging.

If I find any useful or helpful I will be back.

(once "easy" thing i might do is get a bog std KSP add just kOS, and then create LOG files the speeds and positions on trivial craft at a max rate of data acquisition which will be about once or more per physics tick...)

(then do it again without kOS as check the same kind and size of splash occurs. (AKA the chutes drops the ship before bouyancy holds it up.) thinking and remembering hard (back many years) it may actually be stock functionality...)

 

3 hours ago, stupid_chris said:

Parachutes cut when the ship they are flying on gets in contact with water or ground, and the ship moves under a specified speed. It's intended.

I am pretty sure I am not seeing this  flying on gets in contact with water or ground, and the ship moves under a specified speed.

specifically I am confident the AND clause is not also true.  ( i may have another clue, it may not so much be chutes being cut (AKA I said the wrong thing) but failing due to mistakenly... ? perceived aero forces))

It is a fast thing....  (hard to see but the human physics absolutely infers the following.) 

Situation:

I typically have auto cut speed at absolute mininum, (0.01m/s) such that on land if my ships fall over on a slope the chutes >hang on< and slow the fall over. it is Sooo low that when i land on slopy ground i need to manually cut chutes as simply the side slip on the lander on its legs is keeping them open. AKA my in game observed behavior ought to be the ship is visually at seeming total rest before they cut.

When my ships very first come into contact with water. And i mean the instant the colliders touch. While bouancy force is still much less that weight of ship. (thus the ship according to human physics must still be going down)

AKA it is still travelling at *very near* constant speed downward (as almost zero water is yet being displaced) the chutes cut.

The ship then splashes hard into the water sinking way.... below balance of flotation.

 

Whatever as i said. I will get back to you if I find something more definitive useful measured or reproducible,.

 

TLDR: Ta for you time. Much love for the mod.  (ball is in my court.)

 

 

Edited June 11, 2020 by AxleGreaser

[stupid_chris]

@AxleGreaser No, the chutes cut when the ship is splashed or landed, and that the vessel's horizontal surface speed is under the set value
https://github.com/ChrisViral/RealChute/blob/master/RealChute/RealChuteModule.cs#L74

As far as aero forces causing it to break, no, that is most definitely not happening. The chutes would have to reach a pretty significant velocity for way more than one physics frame for this to happen.

Something is making the game think your vessel has splashed down, and the RealChute module interprets this as a reason to cut down.

[AxleGreaser]

8 hours ago, stupid_chris said:

No, the chutes cut when the ship is splashed or landed, and that the vessel's horizontal surface speed is under the set value

Ahhhhh, explains everything. Sorry I always assumed that was any speed in any direction. (and we all know what happens when I assume stuff)

unsurprisingly the code does exactly what the code says it does,.

and the code on my machine will say different things any day now real soon now (tm).

 

FYI: Stock DOES NOT cut the chute that early on splash down.  (maybe it used to but my memory isn't what it was.)

(trouble is Ive been using real chute for so long stock feels just weird now)

 

 

What i have done: AKA: where the diagnositic data in spoiler below comes from.

I made a teeny modded game with just KOS, module manager, and included real chute or not.

details of data recorded by KOS in tight (has wait 0. in it so it records data every 0.02 secs) loop is shown below.

With Real chute the craft accelerates downwards from the moment it is splashed down, because as you say the chutes will be cut as its status is splashed and its side ways V is zero.

For non small craft doing water drops they results is substantial breakage. Id hate to try and drop say a staged rocket for "water" launch on say eve using real chute.

I have had enough drama trying to land aeroplanes with chutes that i wanted to build a water base out of. And they have the advantage of large flat bottoms and wings. So they only "fall" 1m or so. 

for really large ships. Might just be a no can do.

 

=================================================================

This might play better for splashing down big craft without breaking them.

public bool GroundStop => this.vessel.LandedOrSplashed  && this.vessel.horizontalSrfSpeed < this.cutSpeed && (this.vessel.verticalSrfSpeed < this.cutSpeed) << probable buggy sugegstion

It (or perhaps some related(see below) variant) probably what will be running on my machine in few hours or so.

I will probably look for something cleverer that  tests for "stopped going downward" so not a speed test but a signed vertical velocity component.)

If when I find a good (fast/efficient and useful) choice I will be back.

untested Addendum:

(I suspect  https://wiki.kerbalspaceprogram.com/wiki/API:Vessel      vessel:verticalSpeed is not physics version of speed and hence is not as physics would say it is strictly unsigned

-ve NUMBERs will be downward velocities....

public bool GroundStop => this.vessel.LandedOrSplashed  && this.vessel.horizontalSrfSpeed < this.cutSpeed && (this.vessel.verticalSrfSpeed > - this.cutSpeed) // possible valid code

and what that would implement is speed must be less than cut speed sideways AND less than CUTSPEED Downwards.

AKA if the ship has hit the ground bounced and is going up at greater than cut speed. The chute would be cut as its positive upward speed is  > - this.cutSpeed

That is if vertical speed as seen by kOS (logged in the file below) is direct reflection of the sign values coming out of Vessel vertical speed.

if not, dot product of  srf_velocity  with upAxis might yield signed velocity in up direction. (assuming upAxis is already normalized)

 

Spoiler

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

75

Spoiler

Im not sure if I ought to paste th 48k Craft file here or not.

As can be seen below:

With real chute the instant the rather long rocket touches the water its vertical speed increases as the chutes were cut.

Ship. Command module with tail fin and a couple of tiny boosters to get it to the ocean and enough fins to just keep it stable.

The tail fin puts the point of splash down contact a long way from where boyancy would float it. That make sthe differening behavior between stock and real chute clearer.

With real chute; (note initial vert speed is low because I used big real chutes)

FLYING,  alt ,6.272611891618 , T , 542.097022704967 Vel ,2.49538353876999 , vert , -2.49538348252466
FLYING,  alt ,6.22279634780716 , T , 542.117022704967 Vel ,2.49556535339097 , vert , -2.49556531738334
FLYING,  alt ,6.17280849756207 , T , 542.137022704967 Vel ,2.4952655370563 , vert , -2.49526546231995
FLYING,  alt ,6.12299294839613 , T , 542.157022704967 Vel ,2.49530214548354 , vert , -2.49530212237627
FLYING,  alt ,6.07300510350615 , T , 542.177022704967 Vel ,2.49541031043977 , vert , -2.49541023544955
SPLASHED,  alt ,6.02318955236115 , T , 542.197022704967 Vel ,2.49393062946312 , vert , -2.49393059071274
SPLASHED,  alt ,5.96940038073808 , T , 542.217022704967 Vel ,2.68776274262311 , vert , -2.68776270214487
SPLASHED,  alt ,5.91189065668732 , T , 542.237022704967 Vel ,2.88142788631032 , vert , -2.88142784285466
SPLASHED,  alt ,5.85031577653717 , T , 542.257022704967 Vel ,3.07481498666008 , vert , -3.0748149406939
SPLASHED,  alt ,5.78502036037389 , T , 542.277022704967 Vel ,3.26781850077007 , vert , -3.26781845130139
SPLASHED,  alt ,5.71575131092686 , T , 542.297022704966 Vel ,3.46037288285454 , vert , -3.46037283046371
SPLASHED,  alt ,5.64267020230182 , T , 542.317022704966 Vel ,3.65235830108943 , vert , -3.65235824475131

 

Without real chute; (note initial vert speed is higher because these are stock chutes two radial and a top.)

There is still strangely some acceleration but MUCH MUCH less, My guess is they did something to the drag coefficient.

And if you watch the chutes exist while the tail fin is entering the water for quite some distance.

By eye they cut the chutes when vert speed gets to zero and turns positive (upwards).

 

FLYING,  alt ,7.07973278011195 , T , 765.203184814294 Vel ,5.55204497411793 , vert , -5.55204473087353
FLYING,  alt ,6.96868249319959 , T , 765.223184814294 Vel ,5.55182694384931 , vert , -5.55182669246898
FLYING,  alt ,6.8577004034305 , T , 765.243184814294 Vel ,5.55256345786749 , vert , -5.55256316264324
FLYING,  alt ,6.74665007926524 , T , 765.263184814294 Vel ,5.55365905604039 , vert , -5.5536587525648
FLYING,  alt ,6.63549850939307 , T , 765.283184814294 Vel ,5.55572940845946 , vert , -5.55572905716326
FLYING,  alt ,6.52434692822862 , T , 765.303184814294 Vel ,5.55829103051228 , vert , -5.55829066905918
FLYING,  alt ,6.41309410496615 , T , 765.323184814294 Vel ,5.56161796636658 , vert , -5.56161757314906
FLYING,  alt ,6.30177305848338 , T , 765.343184814294 Vel ,5.56573838017459 , vert , -5.56573794496484
FLYING,  alt ,6.19035077362787 , T , 765.363184814294 Vel ,5.57033926520914 , vert , -5.57033874098191
FLYING,  alt ,6.0787590345135 , T , 765.383184814294 Vel ,5.57553430540101 , vert , -5.57553374210761
SPLASHED,  alt ,5.96726852259599 , T , 765.403184814294 Vel ,5.57781199151226 , vert , -5.57781139129632
SPLASHED,  alt ,5.85567676858045 , T , 765.423184814294 Vel ,5.58139559892172 , vert , -5.58139497815185
SPLASHED,  alt ,5.74391556414776 , T , 765.443184814294 Vel ,5.58474718633276 , vert , -5.58474653626841
SPLASHED,  alt ,5.63205312483478 , T , 765.463184814294 Vel ,5.58835653687516 , vert , -5.5883558703438
SPLASHED,  alt ,5.52029190550093 , T , 765.483184814294 Vel ,5.59118824898874 , vert , -5.59118756123448
SPLASHED,  alt ,5.40832822432276 , T , 765.503184814294 Vel ,5.59407187370052 , vert , -5.59407115153077
SPLASHED,  alt ,5.29639755433891 , T , 765.523184814294 Vel ,5.59390949992896 , vert , -5.59390874451341
SPLASHED,  alt ,5.1847045395989 , T , 765.543184814294 Vel ,5.59008776522657 , vert , -5.59008696723811
SPLASHED,  alt ,5.07294330548029 , T , 765.563184814294 Vel ,5.58250120654061 , vert , -5.58250041829669
SPLASHED,  alt ,4.96162219566759 , T , 765.583184814294 Vel ,5.57099741708812 , vert , -5.57099659933428
SPLASHED,  alt ,4.85047052509617 , T , 765.603184814294 Vel ,5.55633851218557 , vert , -5.55633769539939
SPLASHED,  alt ,4.73975897929631 , T , 765.623184814294 Vel ,5.53790737581821 , vert , -5.5379065361837
SPLASHED,  alt ,4.62948755419347 , T , 765.643184814294 Vel ,5.5164651304661 , vert , -5.51646429609795
SPLASHED,  alt ,4.51965625735465 , T , 765.6631

 

Loggin KOS code

print "wait for go up".
until ship:altitude > 100 { wait 0.1. }

print "wait until coming down low".
until ship:altitude < 20 { wait 0.1. }

print "let it Rip".

local tStart is time:seconds.
local TimeDown is -1.

until  TimeDown > 5  {  
    if ship:status = "Splashed"  {
    
        if TimeDown < 0 {
            set tStart to time:seconds.
        }    
        set TimeDown to time:seconds - tStart.
    }
    
    log Ship:status + ",  alt ," + ship:altitude + " , T , " + time:seconds  +
            " Vel ," + ship:velocity:surface:mag + " , vert , " +  ship:verticalspeed
        to "splashlogfile.csv" .
        
    wait 0.    // usually waits one physics tick or there abouts. like yield().
 }
 
 Print "done with logging. ".
 

 

 

 

 

 

 

Once again, ta,  love the work, I never fly safe (leave kerbin) without real chutes.

postscript:

Also regarding my other bounding box related issue. yeah that will be my problem to find.

I need to get KOS module on something that crashes and check the (ship:status +vel in real time to a log ) because not every ship does just seemingly some... or it may even be a somewhere thing. or I might get lazy and wait to see if the scatterer or eve update makes it go away. (TBMK scatterer maybe messes with planet surfaces, and the scatterer I'm using but now emotionally/aesthetically wedded to is not yet 1.9.1 compliant.)

8 hours ago, stupid_chris said:

Something is making the game think your vessel has splashed down, and the RealChute module interprets this as a reason to cut down.

Edited June 11, 2020 by AxleGreaser
postscript: grammar etc.

[AxleGreaser]

53 minutes ago, AxleGreaser said:

unsurprisingly the code does exactly what the code says it does,.

The code in this function does what it says it does too.

CopyToCounterparts()

is there a reason it doesn't copy the size of the chutes.

if there was one thing Id as user (rocket designer) like propogated to all symetries its size and hence weight.

 

manually setting everyone in the symmetry group to the same size so I can get balanced rockets has been annoying me for a while.

Indeed I use asymmetric deployment at height strategies. Open enough chutes to get under say 20ms by 200m then open the rest at 100m to impact.

but I always have to manually copy the oversized chutes around my ship. As i need the rocket balanced going up and the chutes balanced coming down.

 

 

[stupid_chris]

1 hour ago, AxleGreaser said:

public bool GroundStop => this.vessel.LandedOrSplashed  && this.vessel.horizontalSrfSpeed < this.cutSpeed && (this.vessel.verticalSrfSpeed > - this.cutSpeed) // possible valid code

RealChute used to be something similar to this. It's been changed for a reason that avoids me right now, it's been six or so years that the core chute code hasn't changed. You are however free to fork it and do this for yourself.

3 minutes ago, AxleGreaser said:

is there a reason it doesn't copy the size of the chutes.

Yes. This code is called from flight. You shouldn't be able to change chute size characteristics in flight, only deployment characteristics. The code that changes it in the editor is here, and does copy the size to symmetry counterparts.

[AxleGreaser]

7 hours ago, stupid_chris said:

RealChute used to be something similar to this. It's been changed for a reason that avoids me right now, it's been six or so years that the core chute code hasn't changed. You are however free to fork it and do this for yourself.

Yes. This code is called from flight. You shouldn't be able to change chute size characteristics in flight, only deployment characteristics. The code that changes it in the editor is here, and does copy the size to symmetry counterparts.

Ill have to check that against how I am using it in the editor as I usually end up copying sizes by hand, because they are not copied using whichever buttons I push. (edit :nope turns out its not size I have problem with being copied but mass see post below. Id always assumed the size was wrong as the mass was wrong.)

given that I think I press the copy to others button. I wonder.

What happens if I start AT a symmetry counter part not the first one placed.  yeah its weird (unlikely) but I m looking for a way it doesn't work for me when the code says it does.

Again my problem.  Some debug printf will let me marry what I am doing to that code, that is correct code. Then Ill find out why I keep end up with asymmetric chutes unless I do them all by hand.

One possibility, is Axle is stupid Axle, whose head is full of grease.

 

another possibility is it is PAD or editor extensions/redux/revisted/whatever. or one of the other umpteen(?) editor mods that I normally use messing with symmetry so that valid code in your mod misses the other chutes.

Edited June 12, 2020 by AxleGreaser
edit: clearing up misleading (wrong) observations

[AxleGreaser]

9 hours ago, stupid_chris said:

RealChute used to be something similar to this. It's been changed for a reason that avoids me right now, it's been six or so years that the core chute code hasn't changed. You are however free to fork it and do this for yourself.

Yes. This code is called from flight. You shouldn't be able to change chute size characteristics in flight, only deployment characteristics. The code that changes it in the editor is here, and does copy the size to symmetry counterparts.

Edit :AND Note the baviours described happen with Stock Radial chutes when copying to symmetry counter parts BUT not with the equivalent real chute chutes. Hence my obv solution is to use real chutes.

Again you are correct the code does what it says it does. 

Does it also recompute the mass of the counter parts? After it copies the size?

 

I have chute on rocket right now which claims it is a 70m chute but claims its weight is still only  0.093t in the toggle info panel

while the one I manually edited changed to 0.357 tonne.

because I am remembering how to stop assuming. I have verified that the editor has moved the COM marker off center towards the chute I edited and made heavier and away from the ones I copied to that did not get heavier. 

and they did not get heavier both according to toggle info and the game/VAB COM calculator/display tool.

(to make it easier to see (in the linked images below) I put the 3 chutes on the end of two girders so the mass being changed was along way out from center of a light craft.)

Spoiler

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

13

Spoiler

To be very detailed what I did to reporduce exactly.

Deleted every preset because I don't like them.

made my own preset a  //  main 70m x pre 3.5m  0.01s cutout kevlar chute.

It has a mass of  0.357 tonnes. (As check in case I missed a step above)

I add one normal radial chute with symmetry 3.

I select my preset. (pres "select preset" : that preset GUI closes) (says it succeeded and it did as the editor display my presets values via toggle info)

I then press "apply to all symmetry counter parts"  it also says it suceeded.

And if I go look (with toggle info) yes indeed the chutes are now all 70m kevlar with 0.01m/s cutouts etc.....

but none of the other masses are reported to be changed by toggle info.

AND

the editor says COM is off center.

Kerbal engineer if I had it installed would I believe claim the thrust now had torque.

if youre scratching your head and saying yeah but my code says. ( I agree)

this LOC

template.mass = this.templateGUI.mass;

looks like it works... or is correct.  (but toggle inof absolutely reports a 70m  chute counter part has mass of 0.93 t not 0.357

(and my experience is the rocket will fly a bit crooked when launched)

but I do wonder about tweak scale and the problems they have that require  "KSP Recall".

 

 

metrically heavier chute.

images of  info box and the displaced COM and the craft.  (thepoint of the images is that i should be able to get a 70m chute that only weighs the original mass of the chute. So it doesnt matter much how I got there that shouldn't happen (TBMK understanding)

Spoiler

 

 

 

 

Spoiler

https://imgur.com/ZXFhQM1

https://imgur.com/EMbiRiz

 

Edited June 12, 2020 by AxleGreaser

[jpkerman]

On 6/8/2020 at 12:12 AM, stupid_chris said:

There are already four textures you can chose from.

Then my game must be buggered.  I get no option to change the stack chute container color.  It stays white.  The only changes to the textures are the color markers for the different types of chute.  I was looking for a black/white to match the MK-1 pod and black for the Mk2 pod. 

[AxleGreaser]

4 hours ago, AxleGreaser said:

I have chute on rocket right now which claims it is a 70m chute but claims its weight is still only  0.093t in the toggle info panel

Edit :AND Note the baviours described happen with Stock Radial chutes when copying to symmetry counter parts BUT not with the equivalent real chute chutes.

I have new weirdnesses.

I have my manual preset with a 70m chute, with 3.5 m prechute, material  kevlar with an autocutout of 0.01m/s.

I place one brand new out of the list copy of a stock radial chute. (with 3 fold symmetry) I select my preset above copy it to others. The application of parameters success! dialogs both appear, one when i choose the preset one when I do the copy.

I choose toggle info on one of the copies it says yep it is Kevlar, 70 m predeploy of 3.5m but its mass is the default 0.093t

sooooo... mischevious me wonders what happens if I copy that strangely light chute onto its symmetry counterparts.... (can I get mass balanced set of cheated underweight chutes?) ( i could call that clever engineering and move on..?)

(not yes i can 'cheat' place 6 fold symmetry copy from one to all the other remove the 3 I don;t want including the heavy one that I edited.)(im almost scared to try in case that works)

When I click on the radial counterpart that toggle info just claimed was Kevlar....

Nope the RealChute Parachute editor now reports to me that it is Nylon....

hang on.. the toggle info window is still open and yep it says the >same chute< is kevlar.

Now mass being wrong might be some algorithm or computation but a chute being both Kevlar and Nylon at the same time.... thats something else.

Undaunted I press on (nothing exploded, yet, kerbal engineering must proceed) So I copy to all symmetry counterparts the Nylon and  Kevlar 70m chute that weigh too little (0.093t) to "really" be a70m chute from any material.

and .... that makes the formerly 70m kevlar light chute (was created by copy symmetry) heavier and "toggle info" window notices it is now nylon and (still) 70m  and its gets as heavy as 70m nylon chute would be.

The first chute, the one I set the preset on... It according to the info wind is now Nylon, but the parachute editor claims it is still Kevlar. and its keeps its 70m kevlar chute mass whatever its mass really is)

And the third chute the one I hadn't looked at yet, It thinks it is a 70m Nylon chute in both the info and editor windows.

 

Bottom line it is not just mass that is behaving weirdly material Nylon vs Kevlar is doing borked stuff too.

Also as mentioned but not tested recently I found this "feature" when trying to work out why my supposedly symmetrical rockets flew crooked.

 

Edited June 12, 2020 by AxleGreaser

[stupid_chris]

@AxleGreaser This mod is nearly seven years old. It has not been significantly updated in nearly three years. I'm not supporting it anymore either. The bugs have been ironed out a very long time ago, and with no new features being added, I believe it's safe to say that no new bugs are being introduced. I suggest you strip your install of other mods, and test on a new save file. If you can get to reproduce something on a a clean install reliably, document it, and get me the log files. I'll take a look then. But for now, I can only assume that this is local to your install.

1 hour ago, jpkerman said:

Then my game must be buggered.  I get no option to change the stack chute container color.  It stays white.  The only changes to the textures are the color markers for the different types of chute.  I was looking for a black/white to match the MK-1 pod and black for the Mk2 pod. 

Yes, that's the selection you have, and it's what it's staying as for now. Once again, this mod is not in development anymore.

[Tokamak]

This mod is one of my basic vital mods, so thank you!

I'd love a bit of help though. I know the dev isn't supporting it any more, but KSP players in general tend to be helpful, so I thought I ought to ask.

 

Landing safely on Duna is a pain, for obvious reasons. I'm trying to do it with parachutes only, to simplify my supply drop craft, but hyperediting to Duna for test after test is getting tiresome. Is there a way to just make a reasonable guess as to whether a given set of parachutes will give me my target speed in a particular atmosphere?

I know that RS tells you if it thinks you don't have enough parachute to land safely, but as far as I can tell it only takes into account the currently selected parachute and its symmetry counterparts, which doesn't help if you are using multiple stack chutes, or radial chutes in a variety of areas.

If not in the interface itself, I would be more than happy to just have an equation to manually use with a calculator for speed = f(area,drag_coefficient) if anyone knows the relationship. 

[Tonas1997]

When RealChutes says "pre-deployment altitude" does it mean ASL or terrain-relative? I'm configuring a Mars lander and this information can be vital

[Tokamak]

5 minutes ago, Tonas1997 said:

When RealChutes says "pre-deployment altitude" does it mean ASL or terrain-relative? I'm configuring a Mars lander and this information can be vital

I believe it's whichever you have selected on your altimeter.

[Tonas1997]

Just now, Tokamak said:

I believe it's whichever you have selected on your altimeter.

That's good to know, thanks!

[stupid_chris]

9 hours ago, Tokamak said:

Landing safely on Duna is a pain, for obvious reasons. I'm trying to do it with parachutes only, to simplify my supply drop craft, but hyperediting to Duna for test after test is getting tiresome. Is there a way to just make a reasonable guess as to whether a given set of parachutes will give me my target speed in a particular atmosphere?

It is in fact in the action group windows. Put the parachutes you want on your craft, select Duna in the action group menu, and put in your landing parameters. When you hit apply it'll tell you if it can fit such a big parachute. If it doesn't, you can try to use a triple canopy, but things will be getting very expensive for very little return. You can also try using kevlar to help. Landing only with parachutes on Duna is hard, I suggest you instead try to use drogues to slow you down and stabilize and do a final burn to stop completely.

8 hours ago, Tonas1997 said:

When RealChutes says "pre-deployment altitude" does it mean ASL or terrain-relative? I'm configuring a Mars lander and this information can be vital

It's actually always ASL. Parachutes are ground dependant objects.

[AxleGreaser]

On 6/12/2020 at 4:44 AM, stupid_chris said:

RealChute used to be something similar to this. It's been changed for a reason that avoids me right now, it's been six or so years that the core chute code hasn't changed. You are however free to fork it and do this for yourself.

FYI:

I looked through the revision history and didn't find what it used to do that used vertical velocity instead of only horizontal.

I have implemented some (2) patches in my local version.

1 The vertical velocity described recently change does do what it looks like it might

but it is not enough to make real chute behave more like stock on splash down. (and hence break large ships less.)

once I started paying close attention the chutes are not actually cut but are (briefly) reported to have  "parachute has been destroyed due to aero forces and heat"

judicious Debug log code in parachute.cs tracked the odd cause of that down too.

When ships with chutes touch down in water their chute temp suddenly spikes to from about 303k to >6ook when ambient air temps are reported at about 313K...

That turns out to be because the conductivity of water is so high that the math assumes a vast 2000 times as much energy flows in the chute in the next clock tick as in the past one.

(to be clear the simulation math computes the 10 degree thermal gradient produces a 300k temp change in one physics tick)

AKA one of the assumed approximations used in the temp calculation math was violated and thus gave unreal results.

2 The cheap fudge solution (works near enough on most planets...?) is to clamp the chute temp to no warmer than environment when splashed.

(A "better" more generally robust solution would be to also if the chute was initially warmer than the environment clamp it to no cooler than the environment at the end of the calculation

and to only do either if issplashed() is true.)  (the later is because in very low conductivity environment like high atmosphere or space being hotter or colder due to thermal radiation is also possible. )

I will be testing out the code I have, in my main game, and get back to here if sometime I decide its solid.

 

 

Edited June 14, 2020 by AxleGreaser

[Tokamak]

14 hours ago, stupid_chris said:

It's actually always ASL. Parachutes are ground dependant objects.

I stand corrected.

[stupid_chris]

6 hours ago, AxleGreaser said:

That turns out to be because the conductivity of water is so high that the math assumes a vast 2000 times as much energy flows in the chute in the next clock tick as in the past one.

The parachutes only use convective flux and emissive flux for temperature calculation. Conductive flux is not used at all.

[AxleGreaser]

On 6/15/2020 at 9:32 AM, stupid_chris said:

The parachutes only use convective flux and emissive flux for temperature calculation. Conductive flux is not used at all.

yeah sorry, the code does indeed refer to it as convective (this.Vessel.convectiveCoefficient) flux of the water on the first update after splash down that value is hundreds of times higher than the air was

that in turn drive the temp quite physically unrealistically through the roof, in that one update it raises the temp of the chute by 300c due to the 10C or so  diff in temp.

So to be clear... contact of a chute (at=303C) with  water(at 314C) causes, ... according to the code, the cute to heat up to > 600C and then the chute fails earlier than similar chutes in stock do. 

This causes larger craft to break on splash down where they would not in stock.

I know that the temp changes makes no RW physical sense, it is however what the RC simulation code does presently in KSP.

It does that because of the huge thermal flux (caused by Modelling inaccuracies induced by) the sudden massive value of this.Vessel.convectiveCoefficient.

I have a relatively trivial patch that removes (works around) the problem, but i need to play test it some more.

AKA: Where to from here?  I will be back a bit later... probably with a functioning pull request.

 

Edited June 16, 2020 by AxleGreaser

[stupid_chris]

1 hour ago, AxleGreaser said:

AKA: Where to from here?  I will be back a bit later... probably with a functioning pull request.

I've mentioned this before, but this mod is not in development anymore. This code has been stable and functional for over four years now, the parachute code is mostly unchanged itself since 2014. I'm not supporting this mod anymore, and therefore I'm not making an update with a patch that has the potential of causing far more trouble than it is solving. It's hard to predict how this will impact otherwise, and I'm not willing to release it as I am not going to be supporting it, and if something were to go wrong, you end up with angry users without support.

I'm sorry, you are free to patch it on your side, but it's simply not worth me distributing this to thousands of users.

 

I also want to note that you are still facing this bounding box issue, and that this very well might be affecting how fast the parachutes think they're moving underwater. I said it before, and I'll say it again, but if you can reproduce this reliably, under stock conditions save for RC, with accompanying logs, a craft file I can reproduce it with, and reproduction steps, I'll take a look at it and see what's up. Otherwise it's unfortunately staying as is. Stability is king for long term releases.

[AxleGreaser]

1 hour ago, stupid_chris said:

and if something were to go wrong, you end up with angry users without support.

I'm sorry, you are free to patch it on your side, but it's simply not worth me distributing this to thousands of users.

Well in that case i wont get back to you with patch to fix the observed behavior issue.

1 hour ago, stupid_chris said:

I also want to note that you are still facing this bounding box issue,

Well no that not the case, That is only a potential issue in my actual campaign game (this patch work has been done on brand new install) for just that kind of reason.

the comments above are from observations of code executing in a clean install with no to zero other mods running, in sand box game, with the behavior being observed being the first flight on any ship in the game.

And

the observation that

this.Vessel.convectiveCoefficient changes drastically on splash down is trivially confirmable. (it is both expected and actual behavior) (Splashed ships have (and should have) a comparatively huge value for this variable.))

That that (a large temp rapid temp change) would (from simply reading the code) is the expected behavior from reading the code,

and then that has been confirmed by observation ( added Debug.Log() statments ) does is observed to produce a temp spike of +300C on splash down is also trivially confirmable.

but yes "but this mod is not in development anymore."

and yes it is always your choice whether to pull a claimed to work patch into your mod or not.

 

1 hour ago, stupid_chris said:

I said it before, and I'll say it again, but if you can reproduce this reliably, under stock conditions save for RC, with accompanying logs, a craft file I can reproduce it with, and reproduction steps, I'll take a look at it and see what's up.

Well yeah any patch I provided would have the problem it was saying it solved included. But i am not sure I understand what not in development means.

Every craft falling into the water under any conditions, (with chutes open) experiences a sudden change in this.Vessel.convectiveCoefficient every craft where the temp of the chutes was just below ambient which given the math will I think be every craft as it only has simple radiation convection model where that is the equlibrium condition. So to be safe every craft that has had it chutes open for more than few secs. Will when it touches the water have thermal gradient of some degrees between the chute and the outside world. In the first physics tick after the craft touches the water the temp of the chute will spike dratstically upwards to be much hotter than ambient.) For a small craft this produces the survivable effect of cutting the chute earlier than stock chutes. For larger craft it causes breakage, when the chutes suddenly heat to over 600C (internally known temp variable this.chuteTemperature) on contact with water.

Demo Craft file that will launch hands free at the sea supplied (will be linked here) shortly when i pick somewhere to upload it. This craft has a particularly long tail fin so it is clear when the the craft visually phsyically touches the water. (is when the chutes are reported to fail)

 

 

===========

1 hour ago, stupid_chris said:

and that this very well might be affecting how fast the parachutes think they're moving underwater.

as previously mentioned this is about an issue of the chutes on the very first physics up date when the ship is reported to be splashed down. the chutes are in no real sense under water and the issue is when the chutes are failed, the ship then falls the remaining distance into the water and parts are destroyed. They are not underwater when something happens.

Do note I have not only printed out that value but basically every value in the computation and observed them all change, the one that changed drastically and caused the 300C temp spike (in a single phsyics tick) is this one this.Vessel.convectiveCoefficient

Also

Nothing is really "under water".  This issue is not about chutes behavior "under water". It is what happens when ships with chutes first physically touch the water.

The convectiveCoefficient is so enormously large that it computes the amount of energy to be transferred by the 10C temp gradient and it is enough to raise the temp of the chute by 300c. I know a 300C temp change being made by 10c Temp gradient makes no sense it is however what the code does. That claim is not based on my code or the mods it is based on me (bench testing) doing the thermal physics (using the formulas your code uses) of what goes on using the numbers your mod uses comparing it with what your mods function then computes and concluding yes its simulation math is wrong when convectiveCoefficient is so very high and the surface area to volume ratio so very high that, in the real world, it would have come to thermal equilibrium in much less time than one simulation timestep.

but yes it is always your choice whether to pull patch into your mod or not.

So it is irrelevant whether the bug is real or the potential patch works.

My code on on my machine works, I personally have no problems. Thanks for your time .

and

Always enjoyed and long used the mod, thought i might give something back and fix a glitch Ive noticed as a player for years but lived around.

cu.

 

 

Edited June 16, 2020 by AxleGreaser

[stupid_chris]

1 hour ago, AxleGreaser said:

Well yeah any patch I provided would have the problem it was saying it solved included. But i am not sure I understand what not in development means.

Every craft falling into the water under any conditions, (with chutes open) experiences a sudden change in this.Vessel.convectiveCoefficient every craft where the temp of the chutes was just below ambient which given the math will I think be every craft as it only has simple radiation convection model where that is the equlibrium condition.

I simply can't reproduce that though. I've been active out here because I've started playing KSP in personal time again for the first time in nearly two or three years. I've logged about 100h over the past two or three weeks, and I've sent lots of different missions, with splashdowns on laythe and kerbin. I have not had a single parachute breaking up in this time. A very bright and clear message appears on the screen when it does, I'm confident I'd have noticed it. Without being able to reproduce it reliably, I can't try to fix it. I do want to make some time this summer to put out the new parts, and I could have a jab at this if I can reproduce it and fix it confidently, but the solution does not lie in just disabling everything if splashed. This could have insane adverse effects. It might solve part of the problem, but cause another more dramatic elsewhere. This is why I'm reluctant to deploy a user patch to thousands of users that I'm not willing to support reliably, because quite frankly, it's more demanding than I can handle.

1 hour ago, AxleGreaser said:

Always enjoyed and long used the mod, thought i might give something back and fix a glitch Ive noticed as a player for years but lived around.

cu.

And don't get me wrong, I appreciate that. But developing something, and supporting something are wildly different. I don't mod for KSP anymore because supporting drained me right out of all the energy I had. I'm not going back there for the foreseeable future.
If you can produce me a solid bug report, you can drop it on the github repo's issues, and I'll take a crack at it if I have the time to spare, but I can't promise anything.

[Tokamak]

10 hours ago, AxleGreaser said:

Well in that case i wont get back to you with patch to fix the observed behavior issue.

...

Always enjoyed and long used the mod, thought i might give something back and fix a glitch Ive noticed as a player for years but lived around.

The cool thing about Open Source software is that you can fork it if you want to.