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

[Jacke]

Thanks for your attention to this, Starwaster. I know it's tough tracking down these tricky issues.

A steeper reentry will get that pod down safely.

Are you still having overheating trouble on the ascent?

Only that one issue on the ascent, needed faster and lower than my usual ascents.

A steeper reentry ?!? Okay....

On   Use Legacy Aerothermodynamics
Off  Alternate Density calc (ignores densityExponent)
On   Alternate Heating Model
On   Warn when it is unsafe to deploy parachutes due to heating
On   Warn when crew are experiencing hazardous levels of g forces

1    Shockwave Multiplier
1    Shoctwave Exponent
1    Temperature Exponent
1    Density Exponent
5    Multiplier

Mk1 pod Kerbin polar orbit 90km, reentry initial periapsis 0km. Ablation started about 50km. About 17km Heatshield 127/250 units, speed about 1000m/s. Temperature spiked to 1169C, destruction of Mk1.

Did that one again. Spacecraft was slowing down and cooling off, heatshield still ablating slowly but lots of units left, then a definite and very quick spike up in temperature. Happened 2nd time about 17,800m at 1023m/s.

MET
21m25s    777C     129     18830m    1130m/s
21m26s    774C     129     18450m    1090m/s
21m27s    771C     128     18250m    1070m/s
21m28s    765C     127     18050m    1050m/s
21m29s    857C     127     17840m    1020m/s
21m30s    964C     127     17620m    1000m/s
21m31s   1089C     127     17260m     960m/s    burning effects
21m32s   1143C     127     17060m     940m/s    burning effects
21m32s   destruction of Mk1

Another lesser issue. The only reentry FX--besides burning of items about to explode--is the glowing of the heatshield. No glowing envelop effect.

[Starwaster]

has the lack of reentry heating been fixed in the recent update (or at all yet)?

'lack of reentry heating' sounds like a bug, and this is very much a subjective thing influenced by a person's mod environment and (all too often) their own expectations.

I'm working on consistent behavior based on better control for the former. The latter will always be an ongoing problem because sooner or later someone is going to launch a pod straight up into the air or on some other suborbital and then complain because they didn't burn up or didn't burn as much ablative as they thought they should.

I can't fix the latter 'bug'. Complain to your local deity, or to evolution.

Thanks for your attention to this, Starwaster. I know it's tough tracking down these tricky issues.

Only that one issue on the ascent, needed faster and lower than my usual ascents.

A steeper reentry ?!? Okay....

Mk1 pod Kerbin polar orbit 90km, reentry initial periapsis 0km. Ablation started about 50km. About 17km Heatshield 127/250 units, speed about 1000m/s. Temperature spiked to 1169C, destruction of Mk1.

Did that one again. Spacecraft was slowing down and cooling off, heatshield still ablating slowly but lots of units left, then a definite and very quick spike up in temperature. Happened 2nd time about 17,800m at 1023m/s.

That sounds about right. There is a definite area of peak heating based on velocity cross referenced with density at a given altitude. The precise altitude varies with reentry angle. For a 500km x 20km orbit that's somewhere around 28km.

For an Apollo reentry (Moon return I think) reentry heating starts more gradually peaking somewhere around 60km. (again, YMMV)

Obviously for something the size of Earth, not Kerbin

Another lesser issue. The only reentry FX--besides burning of items about to explode--is the glowing of the heatshield. No glowing envelop effect.

Are these parts that were at a distance from your actual vehicle? If so there's probably not a lot that I can do right now. Or rather there is but it's not important enough to dedicate coding time to. (it's based on camera distance. The camera that renders reentry effects won't render past a certain distance which is the far clipping plane)

[Sampa]

'lack of reentry heating' sounds like a bug, and this is very much a subjective thing influenced by a person's mod environment and (all too often) their own expectations.

I'm working on consistent behavior based on better control for the former. The latter will always be an ongoing problem because sooner or later someone is going to launch a pod straight up into the air or on some other suborbital and then complain because they didn't burn up or didn't burn as much ablative as they thought they should.

I can't fix the latter 'bug'. Complain to your local deity, or to evolution.

That sounds about right. There is a definite area of peak heating based on velocity cross referenced with density at a given altitude. The precise altitude varies with reentry angle. For a 500km x 20km orbit that's somewhere around 28km.

For an Apollo reentry (Moon return I think) reentry heating starts more gradually peaking somewhere around 60km. (again, YMMV)

Obviously for something the size of Earth, not Kerbin

Are these parts that were at a distance from your actual vehicle? If so there's probably not a lot that I can do right now. Or rather there is but it's not important enough to dedicate coding time to. (it's based on camera distance. The camera that renders reentry effects won't render past a certain distance which is the far clipping plane)

I was using the stock Kerbin, it's been months since I last had this installed in the game. Uninstalled it due to the fact that, with it not working properly, nor was it for others at the time,and was just taking up space with no purpose.

[Jacke]

Are these parts that were at a distance from your actual vehicle? If so there's probably not a lot that I can do right now. Or rather there is but it's not important enough to dedicate coding time to. (it's based on camera distance. The camera that renders reentry effects won't render past a certain distance which is the far clipping plane)

It's a Mk1 pod with a few parts on its nose; nothing is very far from the vehicle. Previously there used to be the trailing corona of glow trailing behind the reentering vehicle. See the screenshots below. The heatshield gets white-hot yet there is no other reentry effects.

That sounds about right. There is a definite area of peak heating based on velocity cross referenced with density at a given altitude. The precise altitude varies with reentry angle. For a 500km x 20km orbit that's somewhere around 28km.

For an Apollo reentry (Moon return I think) reentry heating starts more gradually peaking somewhere around 60km. (again, YMMV)

Obviously for something the size of Earth, not Kerbin

I don't think this is normal peak heating. The spacecraft had already gone through peak heating and was cooling down and ablation was slowing down. Then in the space of 4 seconds the temperature shoots up and the spacecraft is destroyed. That's not normal at all.

To help you analyse this, here's links to all 38 screenshots I did of that test. The 3rd one has the DR settings and debug windows up showing the parameters.

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot0.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot1.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot2.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot3.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot4.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot5.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot6.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot7.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot8.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot9.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot10.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot11.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot12.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot13.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot14.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot15.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot16.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot17.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot18.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot19.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot20.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot21.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot22.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot23.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot24.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot25.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot26.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot27.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot28.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot29.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot30.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot31.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot32.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot33.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot34.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot35.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot36.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot37.png

[Starwaster]

It's a Mk1 pod with a few parts on its nose; nothing is very far from the vehicle. Previously there used to be the trailing corona of glow trailing behind the reentering vehicle. See the screenshots below. The heatshield gets white-hot yet there is no other reentry effects.

Check your KSP settings in Graphics from the main menu? Maybe your AeroFX quality got turned down.

I don't think this is normal peak heating. The spacecraft had already gone through peak heating and was cooling down and ablation was slowing down. Then in the space of 4 seconds the temperature shoots up and the spacecraft is destroyed. That's not normal at all.

To help you analyse this, here's links to all 38 screenshots I did of that test. The 3rd one has the DR settings and debug windows up showing the parameters.

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot0.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot1.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot2.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot3.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot4.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot5.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot6.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot7.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot8.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot9.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot10.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot11.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot12.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot13.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot14.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot15.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot16.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot17.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot18.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot19.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot20.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot21.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot22.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot23.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot24.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot25.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot26.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot27.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot28.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot29.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot30.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot31.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot32.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot33.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot34.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot35.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot36.png

http://www.cuug.ab.ca/jacke/KSP/v0.90/Jacke-BTSM_011/20150205b-1-F-3t_DR-testing/screenshot37.png

I'm not seeing any telltales in those pictures as to why. I even looked at those logs you referenced earlier but I don't see anything in them either. (unless it wasn't doing it at that time? Errors in the wrong place at the wrong time can make parts heat up but that would be a very VERY slow and gradual thing..... so it's probably not that)

Can you put it through that again but this time with the Debug menu open and right click the part? Take a screenshot of it when it starts to flame, or just note down the shockwave temperature and whether that had started to increase and let me know here.

Edited February 6, 2015 by Starwaster

[Jacke]

Check your KSP settings in Graphics from the main menu? Maybe your AeroFX quality got turned down.

That was it. Thanks!

I'm not seeing any telltales in those pictures as to why. I even looked at those logs you referenced earlier but I don't see anything in them either. (unless it wasn't doing it at that time? Errors in the wrong place at the wrong time can make parts heat up but that would be a very VERY slow and gradual thing..... so it's probably not that)

Can you put it through that again but this time with the Debug menu open and right click the part? Take a screenshot of it when it starts to flame, or just note down the shockwave temperature and whether that had started to increase and let me know here.

Here's the last few seconds:

MET         Shockwave   Part
22m13s        811C       770C
22m14s        790C       767C
22m14s        773C       765C
22m15s        761C       807C
22m15s        745C       891C
22m16s        728C       966C
22m17s        711C      1030C
22m17s        692C      1088C      burning
22m18s        677C      1127C      burning
22m18s        660C      1169C      destruction of Mk1

Shockwave temperature continues to fall even as part temperature spikes.

[Starwaster]

Here's the last few seconds:

MET         Shockwave   Part
22m13s        811C       770C
22m14s        790C       767C
22m14s        773C       765C
22m15s        761C       807C
22m15s        745C       891C
22m16s        728C       966C
22m17s        711C      1030C
22m17s        692C      1088C      burning
22m18s        677C      1127C      burning
22m18s        660C      1169C      destruction of Mk1

Shockwave temperature continues to fall even as part temperature spikes.

I don't even know how that's possible.

DRE checks to make sure that the shockwave temperature is actually greater than the part's temperature or it can't increase temperature of the part.

Was that log file you posted before from the time that this was happening?

[Jacke]

I don't even know how that's possible.

DRE checks to make sure that the shockwave temperature is actually greater than the part's temperature or it can't increase temperature of the part.

Was that log file you posted before from the time that this was happening?

No. I think those were of spacecraft that ran out of heatshield so the shockwave temperature is likely high, what with Multiplier being 25 for them.

Here's the output_log.txt for that data.

The first time I ran that test, I'd confused your instructions and watched the stock debug log. While the spacecraft is going through 22km and lower, I'm hitting screencapture about every second or a bit faster. There were no other log messages between the sequence of "SCREENCAPTURE!!" and the log message announcing the destruction of the Mk1. Nothing stood out in the log in the few seconds that the part temperature was spiking.

Edited February 6, 2015 by Jacke

[Starwaster]

No. I think those were of spacecraft that ran out of heatshield so the shockwave temperature is likely high, what with Multiplier being 25 for them.

Here's the output_log.txt for that data.

The first time I ran that test, I'd confused your instructions and watched the stock debug log. While the spacecraft is going through 22km and lower, I'm hitting screencapture about every second or a bit faster. There were no other log messages between the sequence of "SCREENCAPTURE!!" and the log message announcing the destruction of the Mk1. Nothing stood out in the log in the few seconds that the part temperature was spiking.

Edit your DeadlyReentry.cfg file and find the Mk1pod entry

Find the line that says

	@maxTemp = 1250 // 1700

Change that to

	@maxTemp = 1700

You might also do that reentry with SVEL- (in MechJeb SMARTASS)

I have a sneaking suspicion that because you're basically coming in unguided that as the dynamic pressure eases off right before the end, the batteries (the POT2-XL at the top) are getting exposed and the shockwave is still strong enough to heat them up. I can see in the log that they are catching fire well before the Mk1 is.

Ordinarily that shouldn't be an issue but as you can see above, the Mk1 pod had its maxTemp lowered to 1250. (why the HELL did I do that? I have no idea but it's clearly an act of stupidity on my part)

Even then, that STILL shouldn't be an issue. Overheated parts are only going to transmit enough heat to their parents (the RCS tank) to heat it up to 25%-50%. Which in turn should pass on a like amount of heat to the Mk1.

My suspicion is that another change I made (across the board to all heat shielded parts) is causing the Mk1 to basically act as a sponge. Its conductivity is 0.01 (stock value is 0.12.... or was it 0.22. I forget)

What that means is it can only conduct 0.01 of its own heat back at its parents or children. So I think that the other parts are sending heat into it that it can't get rid of. (basically 12% of their own heat)

The idea behind the conductivity change by the way is that heat shields would serve to actually insulate the things they are shielding because in the old days attaching a shield to the bottom of a part would still cause that part to soak up a lot of heat just through the shield connection. Enough even to potentially destroy some of them (where maxTemps were around 600 or so)

[Jacke]

You might also do that reentry with SVEL- (in MechJeb SMARTASS)

Thanks for that! Kind of hard figuring out all the bells and whistles on some of the MechJeb stuff without much documentation. Now if I could figure out the Translatron....

"]

Edit your DeadlyReentry.cfg file and find the Mk1pod entry

Find the line that says

@maxTemp = 1250 // 1700

Change that to

@maxTemp = 1700

Did another reentry and the Mk1 survived and landed. Had a 14s spike in temperature that peaked out around 1224C, which is less than its lower maxTemp.

I have a sneaking suspicion that because you're basically coming in unguided that as the dynamic pressure eases off right before the end, the batteries (the POT2-XL at the top) are getting exposed and the shockwave is still strong enough to heat them up. I can see in the log that they are catching fire well before the Mk1 is.

Ordinarily that shouldn't be an issue but as you can see above, the Mk1 pod had its maxTemp lowered to 1250. (why the HELL did I do that? I have no idea but it's clearly an act of stupidity on my part)

Even then, that STILL shouldn't be an issue. Overheated parts are only going to transmit enough heat to their parents (the RCS tank) to heat it up to 25%-50%. Which in turn should pass on a like amount of heat to the Mk1.

My suspicion is that another change I made (across the board to all heat shielded parts) is causing the Mk1 to basically act as a sponge. Its conductivity is 0.01 (stock value is 0.12.... or was it 0.22. I forget)

What that means is it can only conduct 0.01 of its own heat back at its parents or children. So I think that the other parts are sending heat into it that it can't get rid of. (basically 12% of their own heat)

The idea behind the conductivity change by the way is that heat shields would serve to actually insulate the things they are shielding because in the old days attaching a shield to the bottom of a part would still cause that part to soak up a lot of heat just through the shield connection. Enough even to potentially destroy some of them (where maxTemps were around 600 or so)

I'd thought about heating from other parts last night too.

Flew another test same conditions as before (Mk1 maxTemp was still 1250). FL-R10 shockwave reported as shielded for the whole reentry up to destruction. And its temp never got hotter than 3C. Also the batteries and RCS quads were always reporting as shielded. Mk1 still burned up as before.

Then I checked the RPM JSI cameras, which you can see as white knobs near the top of the Mk1 in my previous screenshots. They were always getting burned up and I had to up their maxTemp (currently 2500). Did another run watching the JSI camera right-click menu. They are exposed to the shockwave. From 35km to 21km they are hotter than the Mk1, but then they cool to a lower temperature than the Mk1. This is 10s before the temperature spike on the Mk1.

Heat should only flow from the hotter part to the cooler part. Even as it is cooling off, the Mk1 is hotter than the other parts.

I flew another test with the same DR settings. A Mk1 pod with only a Mk16 parachute and a Dragticle (BTSM part for passive reentry orientation) in a retrograde 90km (Mk1 maxTemp was still 1250). This reentry should be hotter than a polar one. (Back with DR 6.1 and 6.2 I could get a Mk1 to reentry okay from a prograde orbit but it would burn up in a polar orbit reentry.) Reentered with initial apoapsis of 0km. During reentry there was only the Mk1, the Mk16 parachute, and a Dragticle. The last 2 parts were always shielded. And it reentered and landed okay.

So somehow parts that are cooler than the Mk1 are causing the Mk1 to spike in temperature well after peak heat of reentry.

Ordinarily that shouldn't be an issue but as you can see above, the Mk1 pod had its maxTemp lowered to 1250. (why the HELL did I do that? I have no idea but it's clearly an act of stupidity on my part)

That's because of "ridiculousMaxTemp = 1250" in DR's DefaultSettings.cfg. Any part with a maxTemp over that gets it multiplied by maxTempScale, which is 0.5.

And then there's BTSM adjustments of DR, contained in its DRPartBalance.cfg

// config file to rebalance Deadly Reentry parts and stock parts with DR heat shields for stock game feel.

@REENTRY_EFFECTS[*]:Final
{
@shockwaveMultiplier = 1.0
@shockwaveExponent = 1.09

@heatMultiplier = 25
@temperatureExponent = 1.03
@densityExponent = 0.85
@startThermal = 750 // formerly set at 250. No longer needed due to DR changes.
@fullThermal = 1150
@afxDensityExponent = 0.8
@gToleranceMult = 2.5
@parachuteTempMult = 0.5

@crewGClamp = 30
@crewGPower = 4
@crewGMin = 5
@crewGWarn = 300000
@crewGLimit = 600000
@crewGKillChance = 0.75

@ridiculousMaxTemp = 2500
@maxTempScale = 0.5

@dissipationCap = True

// the following turns off per planet atmospheric density variation
@legacyAero = True
@useAlternateDensity = False
}

@RESOURCE_DEFINITION[AblativeShielding]:Final
{
@isTweakable = false
}

// Command Pod MK1
@PART[mk1pod]:Final
{
@MODULE[ModuleHeatShield]
{
@dissipation
{
@key,1 = 800 480
}
}
}

// 1.25m Heatshield
@PART[1.25_Heatshield]:Final
{
@MODULE[ModuleHeatShield]
{
@dissipation
{
@key,1 = 800 480
}
}
}

// Heat Shield for Mk 1-2 Pod
@PART[2.5_Heatshield]:Final
{
@MODULE[ModuleHeatShield]
{
@dissipation

{
@key,1 = 800 240
}

}

}

@PART[0625_Heatshield]:Final
{
@MODULE[ModuleHeatShield]
{
@dissipation

{
@key,1 = 800 640
}

}


}

@PART[3.75_Heatshield]:Final
{
@MODULE[ModuleHeatShield]
{
@dissipation

{
@key,1 = 800 60
}

}

}

// probe cores

// Stayputnik Mk1
@PART[probeCoreSphere]:Final
{
!MODULE[ModuleHeatShield]
{
}
}

// nose cones

// Aerodynamic Nose Cone
@PART[noseCone]:Final
{
!MODULE[ModuleHeatShield]
{
}
}

// Protective Rocket Nose Mk7 (large one)
@PART[rocketNoseCone]:Final
{
!MODULE[ModuleHeatShield]
{
}
}

// wings

// AV-R8 Winglet
@PART[R8winglet]:Final
{
!MODULE[ModuleHeatShield]
{
}
}

// Swept Wings
@PART[sweptWing]:Final
{
!MODULE[ModuleHeatShield]
{
}
}

// Delta-Deluxe Winglet
@PART[winglet3]:Final
{
!MODULE[ModuleHeatShield]
{
}
}

// AV-T1 Winglet
@PART[winglet]:Final
{
!MODULE[ModuleHeatShield]
{
}
}

// parachutes

// Mk16 Parachute
@PART[parachuteSingle]:Final
{
!MODULE[ModuleHeatShield]
{
}

!MODULE[ModuleAnimation2Value]
{
}

// overriding DR's changes to default deployment altitude and pressure
@MODULE[ModuleParachute]
{
@minAirPressureToOpen = 0.01
@deployAltitude = 500
}
}

// Mk16-XL Parachute
@PART[parachuteLarge]:Final
{
!MODULE[ModuleHeatShield]
{
}

!MODULE[ModuleAnimation2Value]
{
}

// overriding DR's changes to default deployment altitude and pressure
@MODULE[ModuleParachute]
{
@minAirPressureToOpen = 0.01
@deployAltitude = 500
}
}

// Mk25 Parachute
@PART[parachuteDrogue]:Final
{
!MODULE[ModuleHeatShield]
{
}

!MODULE[ModuleAnimation2Value]
{
}

// overriding DR's changes to default deployment altitude and pressure
@MODULE[ModuleParachute]
{
@minAirPressureToOpen = 0.007
@deployAltitude = 2500
}
}

// Mk2-R Radial-Mount Parachute
@PART[parachuteRadial]:Final
{
// overriding DR's changes to default deployment altitude and pressure
@MODULE[ModuleParachute]
{
@minAirPressureToOpen = 0.01
@deployAltitude = 500
}
}

// other

@PART[trussAdapter]:Final
{
@maxTemp = 1250 // 5000 stock, reduced to 2500 by DR, but still too high
}

// modular girder segment
@PART[trussPiece1x]:Final
{
@maxTemp = 1250 // 5000 stock, reduced to 2500 by DR, but still too high
}

// Modular Girder Segment XL
@PART[trussPiece3x]:Final
{
@maxTemp = 1250 // 5000 stock, reduced to 2500 by DR, but still too high
}

BTSM changes DR's ridiculousMaxTemp from 1250 to 2500. With a ModuleManager syntax ":FINAL" BTSM's 2500 should be used, and from checking maxTemps of parts in the editor it appears it is.

Now that I have a better understanding of what's going on, until you figure out how colder parts cause a temperature spike, I should be able to work around this for now by adjusting maxTemp's and I can allow for halving when over ridiculousMaxTemp.

Do you suggest I stay with these values?

1    Shockwave Multiplier
1    Shoctwave Exponent
1    Temperature Exponent
1    Density Exponent
10    Multiplier

In current DR, they have these default values (changed by BTSM, but I can take care of that):

1    Shockwave Multiplier
1    Shoctwave Exponent
1    Temperature Exponent
0.7    Density Exponent
1    Multiplier

Edited February 6, 2015 by Jacke

[NathanKell]

Things catch fire at 80% maxTemp and are then quickly destroyed, unless Starwaster changed that. So don't think of maxTemp as the maximum practical temperature, think of 80% maxTemp as that; maxTemp is the "go poof" temperature.

[Starwaster]

Thanks for that! Kind of hard figuring out all the bells and whistles on some of the MechJeb stuff without much documentation. Now if I could figure out the Translatron....

I don't often use the Translatron but it has seriously saved my bacon a few times. I was once sending a rescue ship to Duna in one of my favorite canyons. You probably have been there... It's one where you have to make sure your reentry clears the canyon lip before you can land in the canyon. Well I overshot the stranded Kerbals and ended up several kilometers away. So I lifted off about 50m and engaged the Translatron. Settings: Keep Vert, kill H/S (horizontal speed), Speed 0.

That makes sure that vertical speed is 0 and actively counteracts any horizontal speed I accumulate. Then I just pitched over enough to gain horizontal speed. Engines automatically throttle to make sure my vertical speed doesn't drop. When I release the controls it pitches back enough to kill horizontal speed. Great for hovering. And flying above the ground in a tail lander rocket to the stranded Kerbals camp.

Then I checked the RPM JSI cameras, which you can see as white knobs near the top of the Mk1 in my previous screenshots. They were always getting burned up and I had to up their maxTemp (currently 2500). Did another run watching the JSI camera right-click menu. They are exposed to the shockwave. From 35km to 21km they are hotter than the Mk1, but then they cool to a lower temperature than the Mk1. This is 10s before the temperature spike on the Mk1.

Heat should only flow from the hotter part to the cooler part. Even as it is cooling off, the Mk1 is hotter than the other parts.

In real life physics, sure absolutely. KSP parts constantly try to transfer heat between themselves even if the part it's trying to send heat to is hotter than itself (forgive the abuse of the word heat seeing as how this doesn't really follow any known model of heating)

That's governed entirely by part.heatConductivity and changing it or part.heatDissipation can result in some screwy situations. I first experimented with it when trying to improve Real Fuel's heat pumps and it's possible to make parts explode with a bad combination.

I flew another test with the same DR settings. A Mk1 pod with only a Mk16 parachute and a Dragticle (BTSM part for passive reentry orientation) in a retrograde 90km (Mk1 maxTemp was still 1250). This reentry should be hotter than a polar one. (Back with DR 6.1 and 6.2 I could get a Mk1 to reentry okay from a prograde orbit but it would burn up in a polar orbit reentry.) Reentered with initial apoapsis of 0km. During reentry there was only the Mk1, the Mk16 parachute, and a Dragticle. The last 2 parts were always shielded. And it reentered and landed okay.

So somehow parts that are cooler than the Mk1 are causing the Mk1 to spike in temperature well after peak heat of reentry.

I could probably demonstrate what's happening by working it out on spreadsheet. The problem doesn't seem happen with externally attached shields. I suspect because they don't allow for attachments.

That's because of "ridiculousMaxTemp = 1250" in DR's DefaultSettings.cfg. Any part with a maxTemp over that gets it multiplied by maxTempScale, which is 0.5.

So you think I decided it should be reduced below the melting point of steel because we had the default set to 1250? Well I guess that's a better explanation than 'I was on drugs' especially since I don't do drugs....

And then there's BTSM adjustments of DR, contained in its DRPartBalance.cfg

// config file to rebalance Deadly Reentry parts and stock parts with DR heat shields for stock game feel.

@REENTRY_EFFECTS
[*]:Final
{
@shockwaveMultiplier = 1.0
@shockwaveExponent = 1.09

@heatMultiplier = 25
@temperatureExponent = 1.03
@densityExponent = 0.85
@startThermal = 750 // formerly set at 250. No longer needed due to DR changes.
@fullThermal = 1150
@afxDensityExponent = 0.8
@gToleranceMult = 2.5
@parachuteTempMult = 0.5

@crewGClamp = 30
@crewGPower = 4
@crewGMin = 5
@crewGWarn = 300000
@crewGLimit = 600000
@crewGKillChance = 0.75

@ridiculousMaxTemp = 2500
@maxTempScale = 0.5

@dissipationCap = True

// the following turns off per planet atmospheric density variation
@legacyAero = True
@useAlternateDensity = False
}

@RESOURCE_DEFINITION[AblativeShielding]:Final
{
@isTweakable = false
}

// Command Pod MK1
@PART[mk1pod]:Final
{
@MODULE[ModuleHeatShield]
{
@dissipation
{
@key,1 = 800 480
}
}
}

// 1.25m Heatshield
@PART[1.25_Heatshield]:Final
{
@MODULE[ModuleHeatShield]
{
@dissipation
{
@key,1 = 800 480
}
}
}

// Heat Shield for Mk 1-2 Pod
@PART[2.5_Heatshield]:Final
{
@MODULE[ModuleHeatShield]
{
@dissipation

{
@key,1 = 800 240
}

}

}

@PART[0625_Heatshield]:Final
{
@MODULE[ModuleHeatShield]
{
@dissipation

{
@key,1 = 800 640
}

}


}

@PART[3.75_Heatshield]:Final
{
@MODULE[ModuleHeatShield]
{
@dissipation

{
@key,1 = 800 60
}

}

}

// probe cores

// Stayputnik Mk1
@PART[probeCoreSphere]:Final
{
!MODULE[ModuleHeatShield]
{
}
}

// nose cones

// Aerodynamic Nose Cone
@PART[noseCone]:Final
{
!MODULE[ModuleHeatShield]
{
}
}

// Protective Rocket Nose Mk7 (large one)
@PART[rocketNoseCone]:Final
{
!MODULE[ModuleHeatShield]
{
}
}

// wings

// AV-R8 Winglet
@PART[R8winglet]:Final
{
!MODULE[ModuleHeatShield]
{
}
}

// Swept Wings
@PART[sweptWing]:Final
{
!MODULE[ModuleHeatShield]
{
}
}

// Delta-Deluxe Winglet
@PART[winglet3]:Final
{
!MODULE[ModuleHeatShield]
{
}
}

// AV-T1 Winglet
@PART[winglet]:Final
{
!MODULE[ModuleHeatShield]
{
}
}

// parachutes

// Mk16 Parachute
@PART[parachuteSingle]:Final
{
!MODULE[ModuleHeatShield]
{
}

!MODULE[ModuleAnimation2Value]
{
}

// overriding DR's changes to default deployment altitude and pressure
@MODULE[ModuleParachute]
{
@minAirPressureToOpen = 0.01
@deployAltitude = 500
}
}

// Mk16-XL Parachute
@PART[parachuteLarge]:Final
{
!MODULE[ModuleHeatShield]
{
}

!MODULE[ModuleAnimation2Value]
{
}

// overriding DR's changes to default deployment altitude and pressure
@MODULE[ModuleParachute]
{
@minAirPressureToOpen = 0.01
@deployAltitude = 500
}
}

// Mk25 Parachute
@PART[parachuteDrogue]:Final
{
!MODULE[ModuleHeatShield]
{
}

!MODULE[ModuleAnimation2Value]
{
}

// overriding DR's changes to default deployment altitude and pressure
@MODULE[ModuleParachute]
{
@minAirPressureToOpen = 0.007
@deployAltitude = 2500
}
}

// Mk2-R Radial-Mount Parachute
@PART[parachuteRadial]:Final
{
// overriding DR's changes to default deployment altitude and pressure
@MODULE[ModuleParachute]
{
@minAirPressureToOpen = 0.01
@deployAltitude = 500
}
}

// other

@PART[trussAdapter]:Final
{
@maxTemp = 1250 // 5000 stock, reduced to 2500 by DR, but still too high
}

// modular girder segment
@PART[trussPiece1x]:Final
{
@maxTemp = 1250 // 5000 stock, reduced to 2500 by DR, but still too high
}

// Modular Girder Segment XL
@PART[trussPiece3x]:Final
{
@maxTemp = 1250 // 5000 stock, reduced to 2500 by DR, but still too high
}

Yeah, I just saw that today. I knew but had forgotten that BTSM is overriding some things. DRE has a special file used for saving player settings which also uses :FINAL and usually overrides those overrides (because it happens later in the patching process which is alphabetical in order)

However, I was experimenting with changing the order in the beta so I'm not sure that's still true. Have you checked that your settings are still being kept in the debug menu? Or do they revert to BTSM defaults?

Do you suggest I stay with these values?

1    Shockwave Multiplier
1    Shoctwave Exponent
1    Temperature Exponent
1    Density Exponent
10    Multiplier

In current DR, they have these default values (changed by BTSM, but I can take care of that):

1    Shockwave Multiplier
1    Shoctwave Exponent
1    Temperature Exponent
0.7    Density Exponent
1    Multiplier

For now, yes, but I'm still calibrating things so the next beta update will probably use a higher multiplier. In theory, setting all of those to 1 would result in a more natural reentry experience except that Kerbin's smaller size requires faster heating, and KSP also dissipates heat much faster than it should. (read: reduces temperature faster than it should)

One final thought to this very long reply is that in the next beta update I'm going to tie one change I made to the new heating model instead of it being default behavior because it seems clear from our exchanges that my changes are stomping all over Flowerchild's balancing of things. It's one thing for that to be contingent on player's choices because players should have final say in things, but it's another for it to be doing that out of the box.

So next update you might want to try going back to the defaults that BTSM imposes, if you were happy with the way that was working pre-beta. It should work that way again when I'm done.

[FlowerChild]

So next update you might want to try going back to the defaults that BTSM imposes, if you were happy with the way that was working pre-beta. It should work that way again when I'm done.

Not sure if that's really going to happen at this point man, even with the the option you mentioned over PM. From what I'm hearing from players the last non-beta release is distinctly easier than what DR used to be with the settings in BTSM.

At present I'm suspecting that an extensive rebalance to BTSM will be required to accommodate stock reentry effects once 1.0 comes out, and until that time I don't see there being much point in either of us going out of our way to try and accommodate maintaining the different way of balancing things that you and I are going for.

I really do appreciate the effort on your part to minimize the impact through config file settings and such, but at this point I think I've come to view it as a lost cause to try and keep up with the changes that have been occurring to DR.

I'd also appreciate it if BTSM players not bother Starwaster with what are ultimately BTSM specific issues. It's really not fair to be saturating his thread with support requests that really have nothing to do with him like this. BTSM has always made extensive modifications to DR, and any support issues that creates are on my shoulders, not his. It really doesn't make any more sense to be telling Starwaster about problems using BTSM in combination with his mod creates, than it would be to be telling Squad about it, as I'm essentially modding his mod, not the other way around.

Edited February 7, 2015 by FlowerChild

[Jacke]

Thanks for all your attention here, Starwaster. And for the info on the Translatron. I like to be able to do stuff manually and then selectively use aids as I find that helps understanding. Don't think I'll need the Translatron for a while as I'm not too bad on vacuum landings. Haven't pushed a career in BTSM far enough to get to Duna, but I do know about that big east-west just east of the East Far-side Crater on Mun.

[ Heat flows from high temperature to low temperature. ] In real life physics, sure absolutely. KSP [ not so much. ]

Whoa. That's just bent. And I should have guessed.

So you think I decided it should be reduced below the melting point of steel because we had the default set to 1250? Well I guess that's a better explanation than 'I was on drugs' especially since I don't do drugs....

I thought you'd forgotten about ridiculousMaxTemp in your delving in other parts of the code.

And if there's as realistic as possible heat flow (for the strange twist world of the Kerbals where planets have densities greater than anything outside of real world stellar remnants), then sure, give parts realistic yield temperatures. For all we know, Kiron is good to 1700C--or 1873K.

Yeah, I just saw that today. I knew but had forgotten that BTSM is overriding some things. DRE has a special file used for saving player settings which also uses :FINAL and usually overrides those overrides (because it happens later in the patching process which is alphabetical in order)

However, I was experimenting with changing the order in the beta so I'm not sure that's still true. Have you checked that your settings are still being kept in the debug menu? Or do they revert to BTSM defaults?

Appears that BTSM defaults override any saving of changes, possibly due to BTSM disabling the effect of DR Easy/Normal/Hard. Save changes, exit out to Space Centre, goto another rocket, the BTSM defaults are back. I've locked in the suggested settings of 1,1,1,1,10 by putting them into my copy of the BTSM DRPartBalance.cfg.

For now, yes, but I'm still calibrating things so the next beta update will probably use a higher multiplier. In theory, setting all of those to 1 would result in a more natural reentry experience except that Kerbin's smaller size requires faster heating, and KSP also dissipates heat much faster than it should. (read: reduces temperature faster than it should)

One final thought to this very long reply is that in the next beta update I'm going to tie one change I made to the new heating model instead of it being default behavior because it seems clear from our exchanges that my changes are stomping all over Flowerchild's balancing of things. It's one thing for that to be contingent on player's choices because players should have final say in things, but it's another for it to be doing that out of the box.

So next update you might want to try going back to the defaults that BTSM imposes, if you were happy with the way that was working pre-beta. It should work that way again when I'm done.

That would be wonderful.

Of course, the apple cart will soon be truly and completely upset with whatever Squad does with their new aero and reentry heating come the next release. After that, we will be living in a Brave New World which we can barely perceive now.

[not-a-cylon]

I've got a question about balance. The b9 intakes have a max temp of 1700 (also slightly related, there are parts with 1500). The "ridiculousMaxTemp" default is 1250. Would it be unrealistic to set ridiculousMaxTemp to 1800 or would it be better to talk to b9 about setting the b9 parts below the default 1250? Or even another option: set the ridiculousMaxTemp.maxTempScale to another value to handle these things better?

[taniwha]

not-a-cylon: another thing to consider is that bac9 may be thinking of aluminum or titanium where a max temp of 850 is still too high.

[Starwaster]

I'd also appreciate it if BTSM players not bother Starwaster with what are ultimately BTSM specific issues. It's really not fair to be saturating his thread with support requests that really have nothing to do with him like this. BTSM has always made extensive modifications to DR, and any support issues that creates are on my shoulders, not his. It really doesn't make any more sense to be telling Starwaster about problems using BTSM in combination with his mod creates, than it would be to be telling Squad about it, as I'm essentially modding his mod, not the other way around.

In fairness though, I can't put a beta up and not expect feedback on it. And some of Jacke's problems were caused by me meddling with part heat conductivity. (which is a really great idea for a heat shield part but had unanticipated side effects when applied to a capsule with a built in shield and that can have parts attached to it)

I've got a question about balance. The b9 intakes have a max temp of 1700 (also slightly related, there are parts with 1500). The "ridiculousMaxTemp" default is 1250. Would it be unrealistic to set ridiculousMaxTemp to 1800 or would it be better to talk to b9 about setting the b9 parts below the default 1250? Or even another option: set the ridiculousMaxTemp.maxTempScale to another value to handle these things better?

Most materials can't be heated to temperatures that high without serious problems. Arguably, some parts of a high performance jet engine and its intake might operate at temperatures that high but the intake part as a whole probably not so much. (though I can see something like an intake that acts as shielded when closed but unprotected when opened. Easily accomplished with Deadly Reentry.

[FlowerChild]

In fairness though, I can't put a beta up and not expect feedback on it. And some of Jacke's problems were caused by me meddling with part heat conductivity. (which is a really great idea for a heat shield part but had unanticipated side effects when applied to a capsule with a built in shield and that can have parts attached to it)

Hey man, if you're cool with it than so am I, and I certainly didn't any intend any of that to be a criticism of how you're handling things. I tend to feel rather embarrassed when I feel that my problems are being turned into someone else's however, as I don't think that you signed up for running both DR and BTSM support when you took over DR

[RobotsAndSpaceships]

Is anyone maintaining a fork without the supremely annoying "Chute deployment unsafe" warning, or one where it disappears when you hide the HUD? It makes all your screenshots look like crap.

[Starwaster]

Is anyone maintaining a fork without the supremely annoying "Chute deployment unsafe" warning, or one where it disappears when you hide the HUD? It makes all your screenshots look like crap.

It's a shame you don't bother to keep up with current events.

[Jacke]

Is anyone maintaining a fork without the supremely annoying "Chute deployment unsafe" warning, or one where it disappears when you hide the HUD? It makes all your screenshots look like crap.

In DR 6.5.2, there's an option to turn off that warning. Click the DR icon on the stock toolbar to get the DR settings window (and you can do this in any section of the interface) which has it on the second line from the bottom.

[supersonic130]

Any one now where the to download the older versions of D.R. like for ksp 24.2

[Starwaster]

Any one now where the to download the older versions of D.R. like for ksp 24.2

All on the Releases page

https://github.com/Starwaster/DeadlyReentry/releases

[supersonic130]

Thanx i have troubles finding these thing for some reason. Maybe it has somethimg to do wwith me being on my phone and searching for this stuff, but thank you again

[RobotsAndSpaceships]

It's a shame you don't bother to keep up with current events.

I didn't see anything mentioning it in the last three pages of the thread.