[1.12.*] Deadly Reentry v7.9.0 The Barbie Edition, Aug 5th, 2021

[damerell]

(tl;dr for people just trying to preserve their chutes; if I am not mistaken, you are always safe at or below 273 m/s but, unless the atmosphere is much less dense than Kerbin's, have little margin above that.)

It's a rule of thumb that, in Earth's atmosphere, shockwave temperature in Kelvin equals vessel velocity in m/s. That's what DRE uses. However, parts have their temperatures in Celsius, hence the conversion. Safe limit is (part chute temp multiplier) * chutepart.maxTemp, vs (velocity in m/s - 273.15) * density^densityExponent -- unless Starwaster has tweaked it since I wrote it.

Gotcha, I didn't know that rule of thumb. (But, even with the density multiplier, does it give a sensible answer for Duna/Eve/Jool?) However, presently the test is:

bool cut = ambient + Math.Pow(density, ReentryPhysics.densityExponent) * shockwave * 10f > part.maxTemp * ReentryPhysics.parachuteTempMult;

That additional factor of ten surely significantly promotes chute destruction (at least above 273 m/s). If we are just high enough on Kerbin that density^densityexponent = 1, for example, and using a RealChute with a temperature tolerance of 3100 C (whoah!), the safe speed is about 350 m/s; in your code, about 1 km/s. But wait! 3100 C is much too high (although the Wiki lists part heat tolerances as Kelvin and then also says heat is measured on an unknown scale which, on the 2HOT thermometer, can go down to -429, which would imply it has to be Fahrenheit, although since Squad aren't American it seems unlikely they'd use so mad a unit, although the huge stock part heat tolerances actually make more sense in Fahrenheit, but on the other hand Kerbin's surface 20 degrees implies Centigrade, gah, and I see the old DR thread wrestles with this) and DeadlyReentry-RealChutes.cfg does this:

@PART  
[*]:HAS[@MODULE[RealChuteModule]]:Final {  @maxTemp = 1150  }

and DRE also halves any maxTemp over 2500, getting stock chutes down to 1550C. So (in that density^exponent =~1 scenario) a stock chute will rip off at about 310 m/s and a RealChute at 300 m/s. Without the x10 factor, you can do about 670m/s stock, 570m/s RealChute. I wonder if that x10 factor is too high? The effect is that, while you're always safe below 273m/s, the death zone is very close above it - in the calculations above, a RealChute is destroyed when the rule of thumb says the shockwave is at a princely 30C or so. I wouldn't much care to stick my head out the cockpit in a 300 m/s wind, but I'm not sure a mere 30 degrees heat would significantly increase the inconvenience. (A more radical proposal would be to abandon this calculation and propose that any chute is destroyed at supersonic speeds.)

Edited October 28, 2014 by damerell
fix wordwrap catastrophe

[Felbourn]

I have just installed RSS for the first time in several months, and I'm trying to do an A4/V2 replica. I have the exact mass and thrust of the replica "just right" now, but it burns up during liftoff. I'm beginning to debug this, so I don't need need help with that part of it. I will eventually figure something out. It could be a maxTemp is wrong, or my RSS settings could be wrong. There are many reasons, and I'll find it.

But.

While beginning to investigate this, I started trying to teach myself exactly how DRE works. In the process, I came upon this for heat shields.

// now comes the parameters for if the shield is ablative.
ablative = AblativeShielding // what resource to use up when ablating.
loss
{ // Set the loss rates at various *shockwave* temperatures. The actual loss rate will also be modified by atmospheric density at the time.
	key = 650 0 0 0 // start ablating at 650 degrees C
	key = 1000 64 0 0 // peak ablation at 1000 degrees C
	key = 3000 80 0 0 // max ablation at 3000 degrees C
}

I plotted this out and got this:

The comments are confusing me. Normally I think "peak" is the max, but the comments also indicate the "max" value is 80, but at the same time neither the peak nor the max are really either of these values since the plotted curve has a 95 max between approximately 1700 and 1800 degrees C.

Is it intentional that the peak/max is in reality between the two plot points? Or is there some clamping going on that I am not understanding?

[Starwaster]

(tl;dr for people just trying to preserve their chutes; if I am not mistaken, you are always safe at or below 273 m/s but, unless the atmosphere is much less dense than Kerbin's, have little margin above that.) Gotcha, I didn't know that rule of thumb. (But, even with the density multiplier, does it give a sensible answer for Duna/Eve/Jool?) However, presently the test is:

bool cut = ambient + Math.Pow(density, ReentryPhysics.densityExponent) * shockwave * 10f > part.maxTemp * ReentryPhysics.parachuteTempMult;

That additional factor of ten surely significantly promotes chute destruction (at least above 273 m/s). If we are just high enough on Kerbin that density^densityexponent = 1, for example, and using a RealChute with a temperature tolerance of 3100 C (whoah!), the safe speed is about 350 m/s; in your code, about 1 km/s. But wait! 3100 C is much too high (although the Wiki lists part heat tolerances as Kelvin and then also says heat is measured on an unknown scale which, on the 2HOT thermometer, can go down to -429, which would imply it has to be Fahrenheit, although since Squad aren't American it seems unlikely they'd use so mad a unit, although the huge stock part heat tolerances actually make more sense in Fahrenheit, but on the other hand Kerbin's surface 20 degrees implies Centigrade, gah, and I see the old DR thread wrestles with this) and DeadlyReentry-RealChutes.cfg does this:

@PART  
[*]:HAS[@MODULE[RealChuteModule]]:Final {  @maxTemp = 1150  }

and DRE also halves any maxTemp over 2500, getting stock chutes down to 1550C. So (in that density^exponent =~1 scenario) a stock chute will rip off at about 310 m/s and a RealChute at 300 m/s. Without the x10 factor, you can do about 670m/s stock, 570m/s RealChute. I wonder if that x10 factor is too high? The effect is that, while you're always safe below 273m/s, the death zone is very close above it - in the calculations above, a RealChute is destroyed when the rule of thumb says the shockwave is at a princely 30C or so. I wouldn't much care to stick my head out the cockpit in a 300 m/s wind, but I'm not sure a mere 30 degrees heat would significantly increase the inconvenience. (A more radical proposal would be to abandon this calculation and propose that any chute is destroyed at supersonic speeds.)

First, throw out any information you got off the wiki. Anyone can edit that so there's no uniformity there. People edit that who still think stock resource volume units are in liters.

Second, Re: Celsius vs Fahrenheit: It's Celsius. The game does not impose a lower limit on temperatures at all. I could set it to -69,105 in DRE code and the stock code would allow it.

RealChutes vs Stock chute tolerances are exactly the same. By the time DRE is finished with them, they have a final maxTemp of 1150. The parachute temperature multiplier is currently 0.25 by default giving canopies a virtual maxTemp of 287.5. I'm probably going to bump the multiplier up a bit to give canopies a virtual maxTemp corresponding to Nylon 6-6 which is a more heat resistant fabric and is often used in NASA's chutes. (Curiosity chutes were made of this; the lines were made of something stronger, I forget what). (it would be nice to grab the Real Chute material field and treat different canopies according to their material properties, but it's a tricky thing to deal with. Kevlar has a higher 'melting' point but is substantially weaker at high temperatures. All we really deal with right now is failure due to high temperatures)

Finally, yeah the *10 multiplier does make them more prone to destruction, but without the multiplier they become essentially invulnerable. I'd like to change it but don't want to upset the current balance which in spite of complaints I feel is working appropriately.

And, FINALLY finally (I lied about the first Finally):

Soonâ„¢

[Starwaster]

I have just installed RSS for the first time in several months, and I'm trying to do an A4/V2 replica. I have the exact mass and thrust of the replica "just right" now, but it burns up during liftoff. I'm beginning to debug this, so I don't need need help with that part of it. I will eventually figure something out. It could be a maxTemp is wrong, or my RSS settings could be wrong. There are many reasons, and I'll find it.

But.

While beginning to investigate this, I started trying to teach myself exactly how DRE works. In the process, I came upon this for heat shields.

// now comes the parameters for if the shield is ablative.
ablative = AblativeShielding // what resource to use up when ablating.
loss
{ // Set the loss rates at various *shockwave* temperatures. The actual loss rate will also be modified by atmospheric density at the time.
    key = 650 0 0 0 // start ablating at 650 degrees C
    key = 1000 64 0 0 // peak ablation at 1000 degrees C
    key = 3000 80 0 0 // max ablation at 3000 degrees C
}

I plotted this out and got this:

http://i.imgur.com/9XMYaVi.png

The comments are confusing me. Normally I think "peak" is the max, but the comments also indicate the "max" value is 80, but at the same time neither the peak nor the max are really either of these values since the plotted curve has a 95 max between approximately 1700 and 1800 degrees C.

Is it intentional that the peak/max is in reality between the two plot points? Or is there some clamping going on that I am not understanding?

Where are you getting a value of 95 from? What are you using to plot that with?

I don't think the in-game curve is going to be like that, although it's theoretically possible due to the vagaries of how Unity deals with curve data. The shield data lacks tangents so the game could be doing something weird I suppose, but again, where are those numbers really coming from?

And BTW, that shield configuration isn't really RSS appropriate. If you haven't already you want to get the RSS / RO heat shield config from the front post. (typical highest shield loss curve maxes at 6000 and not 3000)

[Felbourn]

Where are you getting a value of 95 from?

The numbers come from using Unity to plot the FloatCurve using those values. (I'm a Unity game developer, software engineer, so I had Unity handy to plot it out.)

I don't think that config is MY config. I pulled it off the github just now because I was at work, on lunch, and wanted to keep researching DRE during my break. I figured whatever I had at home might be close to it though, and anyway I am not having trouble with heat shields. It's just a yak I found and started shaving along the way that raised this question. I'm just trying to learn this mod more deeply at the moment.

[Felbourn]

P.S.

Adding this tangent-less key would lower the peak, but also turns it into sort of two linear lines. I have no idea what sort of curve shape was intended. (log, bell, etc)

key = 930 60 // maybe 61

Or add the tangent:

key = 1000 64 0.03 0.03

Edited October 28, 2014 by Felbourn
added tangent code section

[Wolfox]

Can i ask, will there ever be Win64 support? So far its the only mod (well besides RealChutes) which does not work on ksp 0.25 Win64-bit, 32-bit can´t even think about being stable with my load of mods, OpenGL is kinda broken on my PC, but 64, everything runs smoothly, never experienced any crash (played 10+ hours), just some mods have difficulties with compatibility...

[Starwaster]

P.S.

Adding this tangent-less key would lower the peak, but also turns it into sort of two linear lines. I have no idea what sort of curve shape was intended. (log, bell, etc)

key = 930 60 // maybe 61

Or add the tangent:

key = 1000 64 0.03 0.03

Linear should be fine. If that curve is happening in-game then we (I) should put that in. Sigh.

BTW there's another factor in there that affects where things actually max out (yes, the peak vs max is confusing, I'm not sure who wrote that)

That factor is atmospheric density. So the point where REAL maximum ablation occurs during an actual reentry isn't really reflected on that curve....

[Felbourn]

Linear should be fine. If that curve is happening in-game then we (I) should put that in. Sigh.

I think the second idea I showed with the tangents included looks better than the one I showed with an extra key at 60-61 (the first one has a "jagginess" at the turning points).

This is for this:

key = 650 0
key = 1000 64 0.03 0.03
key = 3000 80

It's of course a nerf to make this change.

Edited October 28, 2014 by Felbourn
it's a nerf comment added

[NathanKell]

Two things:

1, the original curves did not have tangents; I added 0 0 tangents so it should not have plotted as you originally showed, but instead flat at each point, with ease in/outs between points. That said, your final addition of tangents seems closest to what was intended.

2. That curve only controls loss rate, which is dependent on shockwave temperature. Temperature dissipation is based on the other curve, which is dependent on shield temperature. This is wrong, but I didn't get around to changing it from legacy DRE until the rework.

Oh, and the docs are all from ialdabaoth I think.

Starwaster, if you don't want to mess with it all, you might want to just grab the rework of heat shields from a few commits back (before the "undo" commit) since that has the advantage of being physically correct. You might also just want to switch to a fixed number for dissipation (dissipation.evaluate(dissipation.maxtime) perhaps, for backwards compatibility) rather than using a separate curve.

[Felbourn]

Two things:

1, the original curves did not have tangents; I added 0 0 tangents so it should not have plotted as you originally showed

I'm dumb. I thought 0 meant "default" or "no tangent." Derp. This is the real curve for the original data. Now I "get it."

[taniwha]

It's just a yak I found and started shaving along the way that raised this question.

Ah, "there's a hole in the bucket, dear Liza"

[NathanKell]

The 0.3 0.3 is actually probably better, though the final and starting points should have 0 0 each (so it's ease in and out for them).

Maybe something more sharply sloped than 0.3 0.3? Assuming Starwaster wants to keep that way of modeling the shield.

Thanks for the work on this Felbourn, btw!

It's because IIRC FlowerChild (or maybe Taverius?) reported the lack of tangents as causing exactly the weirdness you showed in the first (tangentless) curve that it does have tangents now.

[Starman4308]

Can i ask, will there ever be Win64 support? So far its the only mod (well besides RealChutes) which does not work on ksp 0.25 Win64-bit, 32-bit can´t even think about being stable with my load of mods, OpenGL is kinda broken on my PC, but 64, everything runs smoothly, never experienced any crash (played 10+ hours), just some mods have difficulties with compatibility...

There will be Windows x64 support when Windows x64 stops being an unstable piece of crap for so many players. Some get Windows x64 to work well: it seems to come down to unknown differences in hardware/software.

There are numerous other mod authors who disable their mods for x64: I suspect these are mostly concentrated around those who change gameplay in major ways, because they are more prone to getting bug reports which stem from x64 being unstable.

[Starwaster]

2. That curve only controls loss rate, which is dependent on shockwave temperature. Temperature dissipation is based on the other curve, which is dependent on shield temperature. This is wrong, but I didn't get around to changing it from legacy DRE until the rework.

Starwaster, if you don't want to mess with it all, you might want to just grab the rework of heat shields from a few commits back (before the "undo" commit) since that has the advantage of being physically correct. You might also just want to switch to a fixed number for dissipation (dissipation.evaluate(dissipation.maxtime) perhaps, for backwards compatibility) rather than using a separate curve.

What's wrong with it exactly? Doesn't the current system reflect heat radiation, which is based on how hot the radiating item is?

I'll try your suggestion locally to see how it works out but it doesn't seem like it's really necessary?

[Felbourn]

What's wrong with it exactly? Doesn't the current system reflect heat radiation, which is based on how hot the radiating item is?

I'll try your suggestion locally to see how it works out but it doesn't seem like it's really necessary?

I'd say leave it alone. It's "close enough" in my opinion the way it is now, once I put in the 0 0 tangents properly. "My way" would make things a little harder for players due to the slightly higher values just to the right of the peak point, and could be game-breaking in some instances where people were riding right on the line between success and failure already. Also, even if they were not, if they end up not noticing the difference, why bother making a change no one is going to notice. Thanks for the education. This helped ME but I think things should stay as they are and save you some effort.

[NathanKell]

No, that's supposedly the temperature reduction from ablation. Radiation is handled by KSP (heatDissipation). And if you ablate 1kg of ablative from a shield of a given size, it should always result in the same reduction of temperature. As it is now, you get less reduction when the shield isn't hot.

[damerell]

Finally, yeah the *10 multiplier does make them more prone to destruction, but without the multiplier they become essentially invulnerable. I'd like to change it but don't want to upset the current balance which in spite of complaints I feel is working appropriately.

However, that *10 multiplier is essentially a second part to parachuteTempMult - if parachuteTempMult were 0.025 by default, the *10 could vanish.

I appreciate the current balance is about right, but it seems to be getting the right answer for the wrong reason; the shockwave temperature is, in fact, quite cool, but it's multiplied up by a fudge factor because chutes would otherwise work at supersonic speeds.

[Felbourn]

No, that's supposedly the temperature reduction from ablation. Radiation is handled by KSP (heatDissipation). And if you ablate 1kg of ablative from a shield of a given size, it should always result in the same reduction of temperature. As it is now, you get less reduction when the shield isn't hot.

More education. Thanks! So the change to 0.03 (not 0.3 -- that would make things very broken, peaking at 150 around 1700 C) will actually nerf things a little.

[Wolfox]

There will be Windows x64 support when Windows x64 stops being an unstable piece of crap for so many players. Some get Windows x64 to work well: it seems to come down to unknown differences in hardware/software.

There are numerous other mod authors who disable their mods for x64: I suspect these are mostly concentrated around those who change gameplay in major ways, because they are more prone to getting bug reports which stem from x64 being unstable.

Oh, I understand. It´s unfortunate that some people are not reading big yellow text underneath the loading bar saying, that Win64 version is unstable on its own and cause crashes unrelated to mods. But, if its disabled by developer of a mod, does exist some way for me to enable it for x64? Of course, if its simple enough to do (like changing config files) and author would not mind? Looks like I am one of these rare cases, when x64 is stable (unlike heavily modded x32). I promise I wont bother anybody with pertinent bugs (If its dissablement isn´t bug on its own, but its disabled by author). :-)

EDIT: If it is a bug, please, forgive me for bothering you guys.

Edited October 29, 2014 by Wolfox

[Starman4308]

Oh, I understand. It´s unfortunate that some people are not reading big yellow text underneath the loading bar saying, that Win64 version is unstable on its own and cause crashes unrelated to mods. But, if its disabled by developer of a mod, does exist some way for me to enable it for x64? Of course, if its simple enough to do (like changing config files) and author would not mind? Looks like I am one of these rare cases, when x64 is stable (unlike heavily modded x32). I promise I wont bother anybody with pertinent bugs (If its dissablement isn´t bug on its own, but its disabled by author). :-)

Some mods, just ask the author and they'll send you a version.

In general, you can just go into the source code, eliminate the compatibility check, and recompile, given that you never redistribute without author's permission.

[Wolfox]

Some mods, just ask the author and they'll send you a version.

In general, you can just go into the source code, eliminate the compatibility check, and recompile, given that you never redistribute without author's permission.

I am afraid I dont have the knowledge and instruments to alter the source code, so I guess I will ask the author, if he will be so kind :-) Thanks for answers!

[Starwaster]

Of course, if its simple enough to do (like changing config files) and author would not mind? Looks like I am one of these rare cases, when x64 is stable (unlike heavily modded x32).

EDIT: If it is a bug, please, forgive me for bothering you guys.

It's not that simple, the source code has to be changed and recompiled. Nobody minds if you do that unless it gets redistributed and results in extra work for the developer. (i.e. having to deal with 64 bit requests which have no solution possible). You do a thing like that then you better take ownership of the situation

[Entropius]

I've got a couple questions. Hopefully they're not too dumb:

1. The inflatable heat shield has no ablation resource, which I assume means it's therefore perfectly reusable (is that correct?). But I also figure there's still some sort of limit on it's capacity to tolerate heat. If there is a limit, what is it? Is there some sort of maximum temperature at which it will fail?

2. I see that when I EVA and right-click parts there's some reference to parts being damageable and repairable. How does DRE's "damage" on parts work? I was under the impression that in KSP part damage was binary: Either it's exploded or it's intact. But this suggests otherwise. So what kinds of damage should I be able to repair?

[Starwaster]

I've got a couple questions. Hopefully they're not too dumb:

1. The inflatable heat shield has no ablation resource, which I assume means it's therefore perfectly reusable (is that correct?). But I also figure there's still some sort of limit on it's capacity to tolerate heat. If there is a limit, what is it? Is there some sort of maximum temperature at which it will fail?

2. I see that when I EVA and right-click parts there's some reference to parts being damageable and repairable. How does DRE's "damage" on parts work? I was under the impression that in KSP part damage was binary: Either it's exploded or it's intact. But this suggests otherwise. So what kinds of damage should I be able to repair?

1. The inflatable works by having a higher than usual reflective rating (25% of all incoming heat is simply ignored). You can see its maximum temperature rating in the VAB by hovering the mouse cursor over the part's icon in the catalog. I don't consider it to be reusable as there's no way to deflate it and it has high drag when inflated.
   
2. I don't think DRE's damage system has ever really worked. There are two points at which you're supposed to take damage: When the vessel is undergoing high G and you hear creaking as the parts are stressed. And when parts are on fire. Those two events tend to result in destruction if you actually get to them so I've never really been in a situation to notice if something got damaged or not, as a player. Since taking over this mod It's been on my mind to look at the damage system and see if it actually is working but I haven't got to it yet. (realistically it should take some sort of resource to repair something...)