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

[Starwaster]

I can't remember how much of a handle you think you have on stuff overheating inside procedural fairings, so I don't know whether this is helpful, but I have a craft that will consistently have its fairing-shielded Z-200 battery (Skin Thermal Mass: 0.8) explode after sitting on the lauchpad for a few minutes. I did notice that the fairing was gaining more thermal energy through convection than it was losing through radiation, though (flux: 55 vs -51).

Speaking of flux, what's int flux?

The effect of any fairings or cargo bays on Deadly Reentry is whether or not the mark the part as shielded. If it is shielded then it won't do convection updates. If you're seeing convection happening to something in a fairing then either it's not being marked as shielded or you need to update Deadly Reentry. (the shielding check only went in recently because I thought that such checks were already being done stock, upstream of DRE code execution. I'll probably stick in a check for radiation and shielding next update as well. (otherwise, they will pick up extra radiant energy from supersonic shock)

int flux = internal flux and it's basically anything that is NOT convection, radiation or conduction. It has no real world analogue, it's the means by which other modules can add or subtract heat from a part. (it could be considered either of the 3 but isn't actually handled by any of them) The way it works is that rather than code directly adjusting a part's temperature, they just add or subtract the mount of kilowatts they want to add, and when the thermal code runs, it looks at the net amount of internal flux and calculates the result then clears the internal flux property.

I don't know what happened, I thought it was KW rocketry because I installed it at the same time as the DRE update, which was working fine on the previous version, but the latest DRE update completely killed my FPS. Game runs around 1-2 FPS with it installed now. I was forced to remove it

Either you have a lot of errors being generated or DRE is printing a lot of debug messages to the log. The last update removed 99% of those updates and the next one will remove all of them. If that was the cause of your FPS loss then try reinstalling at the next DRE update.

The bad news is that if you DO have those debugging messages happening then it means that one or more parts on a craft have thermals not working. (it will say in the log 'PartThermalData is NULL')

[Ser]

Starwaster and guys,

It's definitely FAR. All the issues are coming from Conv Flux parameter. I've made some tests and had the same issues of plasma "jumping" over shields and everything to the parts that must be covered from it thus rising the Conv Flux factor in some misterious way. I have removed DRE and tried FAR with stock reentry and problem persisted. Once I removed FAR and kept DRE, everything was obscured from heating like it should: while having parts in a good cover Conv Flux dropped to 0 for them. So I'm sure the issues has been caused by FAR's voxel model somehow.

Edited May 17, 2015 by Ser

[futrtrubl]

At 60km, the skin temperature of the chute is 693K. Its overall temperature is 363K. Conductive: -1.1. Convective: 61.62. Radiative: -574. Int: 377. The capsule's skin temperature is circa 295K, internal 290K.

Wait, a parachute has internal heat generation... that seems very wrong.

[Nayeen]

There are two things you are trying to limit when reentering, g forces and heating.

To limit g force you come in at a shallow angle so you do most of your slowing high up so when you hit the thicker atmosphere you are going slower and so have less drag and thus less g forces.

Conversely to limit the amount of heating you want to come in steeply. This makes peak heating higher, but it actually reduces the amount of heat absorbed by the craft as the heating is for a MUCH shorter period of time.

So it comes down to a balance of how much heat and how much gs you can take. That's why with real life reentries there is a very narrow window of survivable reentry. Too shallow and they cook, too steep and they squish.

KSP has much lower orbital speeds so it's a lot more forgiving with the survivable reentry angles.

PS. This means that if you have probes that don't care too much about gs or aero stress a steep angle can save quite a bit in shielding.

Thanks for this explanation. I was also using very shallow entry angles from LKO (periapsis around 50km) and I lost all my ablative shielding on the stock pod. I was using DRE with older KSP versions and this type of shallow atmospheric entry always worked fine until 1.00/1.02. This explanation regarding the g-forces vs heating balance makes perfect sense now. I never knew there was such a thing as too shallow re-entry.

But I'm wondering how to go about aerobraking? Let's say you are approaching Kerbin at transfer speeds and you are forced to break in the thin upper atmosphere? With the current version of KSP/DRE I can't imagine the ablative would survive long enough for such a manoeuvre?

[Ser]

Wait, a parachute has internal heat generation... that seems very wrong.

Yes, with DRE Int Flux rises and drops together with Conv Flux while the part is exposed to the plasma flow. That's not right, I think. On stock it doesn't.

[Starwaster]

Wait, a parachute has internal heat generation... that seems very wrong.

Yes, with DRE Int Flux rises and drops together with Conv Flux while the part is exposed to the plasma flow. That's not right, I think. On stock it doesn't.

Remember what I said: Anything isn't handled by the other three models. And we're talking about part.temperature. Anytime part.temperature was raised or lowered then there has to be flux in one of those 4 categories.

Now think about skin temperature. If I move heat from the skin to the interior (skinTemperature <-> part.temperature), it's not convection and it's not radiation. It could be construed as conduction but it's not handled by UpdateConduction() and heat didn't move from one part to another. So it's internal, not any of the other 3.

[futrtrubl]

Thanks for this explanation. I was also using very shallow entry angles from LKO (periapsis around 50km) and I lost all my ablative shielding on the stock pod. I was using DRE with older KSP versions and this type of shallow atmospheric entry always worked fine until 1.00/1.02. This explanation regarding the g-forces vs heating balance makes perfect sense now. I never knew there was such a thing as too shallow re-entry.

But I'm wondering how to go about aerobraking? Let's say you are approaching Kerbin at transfer speeds and you are forced to break in the thin upper atmosphere? With the current version of KSP/DRE I can't imagine the ablative would survive long enough for such a manoeuvre?

For aerobraking the density should be low enough that the rate of convective transfer should be low enough and the amount of time in the atmosphere low enough that it should be ok. Only way to be sure is to test it.

- - - Updated - - -

Remember what I said: Anything isn't handled by the other three models. And we're talking about part.temperature. Anytime part.temperature was raised or lowered then there has to be flux in one of those 4 categories.

Now think about skin temperature. If I move heat from the skin to the interior (skinTemperature <-> part.temperature), it's not convection and it's not radiation. It could be construed as conduction but it's not handled by UpdateConduction() and heat didn't move from one part to another. So it's internal, not any of the other 3.

Ahh, makes sense. Was just worried some heat might be double counted.

[Scientist]

not sure if this would fit DRE, or new mod (or if itd need DRE)

when part temp goes up, its not just the part that warms up, its the inside

so uh...kerbal oven anyone? should be an option to cook kerbals if inside temp goes too high for too long

not sure if a new mod would require DRE to access temp values

i would avoid methods of cooling, electric would be too slow, letting some N2 into the cabin to keep it cool would work

in the end though proper heat shielding should keep em alive fine without coolant

[xXIndestructibleEVAXx]

So, is there any progress with compatibility with FAR, or am I missing something, because from what I've seen there are several bugs between this and FAR.

[damerell]

Not so much edited as rewritted to say; Ferram has found a bug after Ser kindly passed this discussion over to the FAR thread, and pushed a fix to github.

I'm pleased to report that after installing that fix locally, I'm back to ordinary death-free re-entry with nuFAR and DRE.

Edited May 17, 2015 by damerell

[ss8913]

@Starwaster - replacing modular flight integrator as you suggested, fixed the framerate problem (yes I had gotten it from CKAN). I'm looking forward to the FAR update, then; right now my spaceplanes are burning up on climb-out at fairly low speeds, including parts inside shielded cargo bays, so... I will wait for the FAR update and will disable DRE in the meantime.

[Adamantium9001]

Wait a minute; something's very wrong here, and I don't think it's what you said, Starwaster:

(This is just before exploding on the launchpad)

Z-200 Rechargeable Battery Pack

Skin Temp: 790.96K
Skin Thermal Mass: 0.80
Rad. Area: 0.00m2
Exp. Area: 0.00m2
ElectricCh...        194/200
Thermal Mass: 8.0
Temp: 287.5
Temp Ext: 312.3
Cond Flux: 0.00
Conv Flux: 0.00
Rad Flux: 3.03
Int Flux: 0.00

With those temperatures, Cond and Int should be hugely negative, right? As for Conv and Rad, are you interpreting the "shielded" flag to mean "completely covered", or just "not being blasted by the oncoming airstream"? If it's the former, then shielded parts should be unable to either gain or lose energy through convection and radiation; if it's the latter, both gain and loss should be possible (and the flux values here should also be hugely negative). It looks to me like shielded parts are having all transfer disabled except for radiative heating.

Edit: crap, it's more complicated than that for convection, isn't it? Ideally, a part protected from oncoming air but not completely enclosed would have different convective potential depending on the local (as in, within a few feet) air movement pattern. In particular, it shouldn't heat up (much) from air compression during reentry, but it should heat up if the ship is sitting on the ground on Eve at the equator, due to the ambient air being hot.

Edited May 17, 2015 by Adamantium9001

[Starwaster]

So, is there any progress with compatibility with FAR, or am I missing something, because from what I've seen there are several bugs between this and FAR.

Wait a minute; something's very wrong here, and I don't think it's what you said, Starwaster:

(This is just before exploding on the launchpad)

Z-200 Rechargeable Battery Pack

Skin Temp: 790.96K
Skin Thermal Mass: 0.80
Rad. Area: 0.00m2
Exp. Area: 0.00m2
ElectricCh...        194/200
Thermal Mass: 8.0
Temp: 287.5
Temp Ext: 312.3
Cond Flux: 0.00
Conv Flux: 0.00
Rad Flux: 3.03
Int Flux: 0.00

With those temperatures, Cond and Int should be hugely negative, right? As for Conv and Rad, are you interpreting the "shielded" flag to mean "completely covered", or just "not being blasted by the oncoming airstream"? If it's the former, then shielded parts should be unable to either gain or lose energy through convection and radiation; if it's the latter, both gain and loss should be possible (and the flux values here should also be hugely negative). It looks to me like shielded parts are having all transfer disabled except for radiative heating.

Edit: crap, it's more complicated than that for convection, isn't it? Ideally, a part protected from oncoming air but not completely enclosed would have different convective potential depending on the local (as in, within a few feet) air movement pattern. In particular, it shouldn't heat up (much) from air compression during reentry, but it should heat up if the ship is sitting on the ground on Eve at the equator, due to the ambient air being hot.

Right now, it means 'don't run UpdateConvection()'

https://github.com/Starwaster/DeadlyReentry/blob/master/Source/DeadlyReentry.cs#L296-L304

DO run UpdateRadiation()

DO run UpdateSkinConduction()

If those last two aren't running then you probably have errors happening in there or else radiation / conduction disabled.

Edited May 18, 2015 by Starwaster

[MrLao]

Hi everyone, a little question here from an amateur aerodynamicist. Starwaster, thanks for your time and effort on this mod, it makes the game much more exiting.

However, my reentries are not at all dangerous at the moment. I'm running FAR 0.15.1+ DRE 7.0.3 installed via CKAN. Just tested a Mk I pod in low orbit, Ap around 120 km, lowering Pe to about 30 for reentry. The ablative shielding stays at 100 all the time, the temperature on the pod is stuck at 287.4 degrees throughout the reentry. Aerodynamics working as predicted, the pod stays in the airstream and doesn't flip. In the debug menu, I get a lot of this:

[Exception]: MissingMethodException: Method not found: 'ModularFI.ModularFlightIntegrator.get_PartThermalDataList'.

So the problem maybe is in Modular Flight Integrator? Maybe I should try manual install instead of CKAN? I tried to look up if this is a known bug but couldn't find anything. I'd be happy for some help or directions.

Thanks again!

Edit: Running Career Mode, 100% Reentry heat setting. Before I installed FAR, I reverted the drag and lift settings from 1.0.2 to 1.0 in the physics.cfg, but if I understand this correct, DRE and FAR doesn't care about this.

Edited May 18, 2015 by MrLao

[Starwaster]

Hi everyone, a little question here from an amateur aerodynamicist. Starwaster, thanks for your time and effort on this mod, it makes the game much more exiting.

However, my reentries are not at all dangerous at the moment. I'm running FAR 0.15.1+ DRE 7.0.3 installed via CKAN. Just tested a Mk I pod in low orbit, Ap around 120 km, lowering Pe to about 30 for reentry. The ablative shielding stays at 100 all the time, the temperature on the pod is stuck at 287.4 degrees throughout the reentry. Aerodynamics working as predicted, the pod stays in the airstream and doesn't flip. In the debug menu, I get a lot of this:

[Exception]: MissingMethodException: Method not found: 'ModularFI.ModularFlightIntegrator.get_PartThermalDataList'.

So the problem maybe is in Modular Flight Integrator? Maybe I should try manual install instead of CKAN? I tried to look up if this is a known bug but couldn't find anything. I'd be happy for some help or directions.

Thanks again!

Edit: Running Career Mode, 100% Reentry heat setting. Before I installed FAR, I reverted the drag and lift settings from 1.0.2 to 1.0 in the physics.cfg, but if I understand this correct, DRE and FAR doesn't care about this.

Yes, the version currently distributed by CKAN is outdated. Use ModularFlightIntegrator from either DRE or FAR installations or grab it here: https://ksp.sarbian.com/jenkins/job/ModularFlightIntegrator/

[MrLao]

Yes, the version currently distributed by CKAN is outdated. Use ModularFlightIntegrator from either DRE or FAR installations or grab it here: https://ksp.sarbian.com/jenkins/job/ModularFlightIntegrator/

Works like a charm! Mk I pod in roughly the same trajectory ended up with only 0.25 ablative shielding left and temperature readings looks more reasonable. I think FAR is working better as well. Thanks!

[blu3wolf]

Yes, the version currently distributed by CKAN is outdated. Use ModularFlightIntegrator from either DRE or FAR installations or grab it here: https://ksp.sarbian.com/jenkins/job/ModularFlightIntegrator/

That seems strange, seeing as CKAN is grabbing the version on GitHub - which was released at the same time as the one you linked.

[Sokar408]

Works like a charm! Mk I pod in roughly the same trajectory ended up with only 0.25 ablative shielding left and temperature readings looks more reasonable. I think FAR is working better as well. Thanks!

How do you get that to work? When I do something similar. Install both mods by hand, HyperEdit a parachute+pod+heatshield craft into a 1 mill orbit, then reduce prograde velocity by 450 m/s (so it has pretty steep reentry), the pod itself explodes and has used all of its own ablatorshield before the heat shield it self has last 30 ablator, and this happens only after about a 250 m/s speed reduction during reentry (so pretty early). I really do not understand why everyone seem to get it working, while I'm left with something that doesn't work at all

[Starwaster]

That seems strange, seeing as CKAN is grabbing the version on GitHub - which was released at the same time as the one you linked.

No it's downloading from Jenkins. There is no actual download on the github site; that's just the source repository. Anyway, Sarbian is/has dealing with/has dealt with the problem so CKAN should be grabbing the right version, or will be if it's not already.

How do you get that to work? When I do something similar. Install both mods by hand, HyperEdit a parachute+pod+heatshield craft into a 1 mill orbit, then reduce prograde velocity by 450 m/s (so it has pretty steep reentry), the pod itself explodes and has used all of its own ablatorshield before the heat shield it self has last 30 ablator, and this happens only after about a 250 m/s speed reduction during reentry (so pretty early). I really do not understand why everyone seem to get it working, while I'm left with something that doesn't work at all

How steep? Set your periapsis to 20. And lose the extra heat shield, you're probably making things harder on yourself. (more mass, worse ballistic coefficient, molten glob of metal attached to your bottom conducting more heat into your pod)

I duplicated your reentry sans extra heat shield. The Mk1 has one builtin

[damerell]

How do you get that to work? When I do something similar. Install both mods by hand, HyperEdit a parachute+pod+heatshield craft into a 1 mill orbit, then reduce prograde velocity by 450 m/s (so it has pretty steep reentry), the pod itself explodes and has used all of its own ablatorshield before the heat shield it self has last 30 ablator, and this happens only after about a 250 m/s speed reduction during reentry (so pretty early). I really do not understand why everyone seem to get it working, while I'm left with something that doesn't work at all

I don't think the FAR fix from yesterday is yet in any release package. You can grab the DLL itself from github.

[Carsaxy]

The DL link for 7.0.3 on GitHub is incorrect: it downloads the 7.0.1

[Olsson]

How does g-forces work with this? I went for a really steep re-entry, moving the bottom of my trajectory to 90 degrees away from my apoapsis so I touch down on the right side if I start on the bottom.

I made it, g forces never really got that high but the re-entry was about the same as a periapsis of 20km.

[Starwaster]

The DL link for 7.0.3 on GitHub is incorrect: it downloads the 7.0.1

I have verified that the 7.0.3 actually downloads 7.0.3.

How does g-forces work with this? I went for a really steep re-entry, moving the bottom of my trajectory to 90 degrees away from my apoapsis so I touch down on the right side if I start on the bottom.

I made it, g forces never really got that high but the re-entry was about the same as a periapsis of 20km.

It starts to get dangerous at 5g. The longer you spend above 5g acceleration, the greater the chance of death. (there is a threshold of accumulated g force that you have to have accumulated before the kill rolls begin)

Very high g force can damage your ship

[Carsaxy]

I have verified that the 7.0.3 actually downloads 7.0.3.

I've downloaded it again less than a minute ago:

DeadlyReentry.version

{    "NAME":"Deadly Reentry",
    "URL":"https://raw.githubusercontent.com/Starwaster/DeadlyReentry/master/DeadlyReentry.version",
    "DOWNLOAD":"https://github.com/Starwaster/DeadlyReentry/releases",
    "GITHUB":
    {
        "USERNAME":"Starwaster",
        "REPOSITORY":"DeadlyReentry",
        "ALLOW_PRE_RELEASE":false,
    },
    "VERSION":
    {
        "MAJOR":7,
        "MINOR":0,
        "PATCH":1,
        "BUILD":0
    },
    "KSP_VERSION":
    {
        "MAJOR":1,
        "MINOR":0,
        "PATCH":2
    },
    "KSP_VERSION_MIN":
    {
        "MAJOR":1,
        "MINOR":0,
        "PATCH":0
    },
    "KSP_VERSION_MAX":
    {
        "MAJOR":1,
        "MINOR":0,
        "PATCH":2
    }
}

[Svm420]

I've downloaded it again less than a minute ago:

DeadlyReentry.version

{    "NAME":"Deadly Reentry",
    "URL":"https://raw.githubusercontent.com/Starwaster/DeadlyReentry/master/DeadlyReentry.version",
    "DOWNLOAD":"https://github.com/Starwaster/DeadlyReentry/releases",
    "GITHUB":
    {
        "USERNAME":"Starwaster",
        "REPOSITORY":"DeadlyReentry",
        "ALLOW_PRE_RELEASE":false,
    },
    "VERSION":
    {
        "MAJOR":7,
        "MINOR":0,
        "PATCH":1,
        "BUILD":0
    },
    "KSP_VERSION":
    {
        "MAJOR":1,
        "MINOR":0,
        "PATCH":2
    },
    "KSP_VERSION_MIN":
    {
        "MAJOR":1,
        "MINOR":0,
        "PATCH":0
    },
    "KSP_VERSION_MAX":
    {
        "MAJOR":1,
        "MINOR":0,
        "PATCH":2
    }
}

Do you realize the version file has nothing really to do with what dll you get?