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

[enfrocerx78]

I have NO idea... are you saying the resources filled back up...? Wow I have no idea.

That is exactly what I am saying.

If I get some time tomorrow I'll reinstall 7.0.3 and capture a video of i for you. I've honestly never seen anything like it, but it is KSP with mods so I expect anything. For now I reverted to 7.0.1.

[mobiusune]

very nice job starwaster !

Ok, and now the question: can anyone tell my why i have to but all the heatshields the wrong way around to attack them ?

wrong:

http://www.bilder-upload.eu/thumb/9d7755-1431502988.jpg

right, but why ?

http://www.bilder-upload.eu/thumb/2c2ea8-1431503020.jpg

Im sorry starwaster i tried everthing i could, i still have the same problem. The heatshields are facing the wrong way around...

I completly reeninstallerd ksp and only used the newest dre version, but its still not working.

The config files should be correct, they all have the "node_stack_bottom = 0.0, -0.01, 0.0, 0.0, -1.0, 0.0, 1 " entry

example from part_1_25M.cfg:

// --- node definitions ---

// definition format is Position X, Position Y, Position Z, Up X, Up Y, Up Z

node_stack_top = 0.0, 0.1, 0.0, 0.0, 1.0, 0.0, 1

node_stack_bottom = 0.0, -0.12, 0.0, 0.0, -1.0, 0.0, 1

Edited May 17, 2015 by mobiusune

[ss8913]

@Starwaster - I have installed 7.0.2. Still having the severe framerate problem. I did as you suggested and tried reverting to launch - this causes a CTD, with the error log saying I'm out of memory - however the ALT-F12 performance window said I was only using 1.2GB ram before the 'revert'. I'm seeing a lot of errors in output_log from ModularFlightIntegrator complaining about heating stuff, which is why I was previously thinking this might be a FAR compatibility thing, since FAR requires MFI. Here's a link to the crash log directory (zip file containing all 4 files including output_log): https://www.dropbox.com/s/qpqacbwfilc2mb2/2015-05-16_211352.zip?dl=0

[damerell]

This is a little vague, but DRE (+nuFAR) seems a lot more, well, deadly than in 0.90 (with oldFAR).

A couple of times now, I've dropped from LKO a Mk I capsule with a RealChute on its nose by adjusting the periapsis down to about 50km and dropping the engine. In 0.90 this would be completely undramatic; in 1.0 DRE the chute gets up to above 1400 Kelvin (nearly exploding) and the AblativeShielding is exhausted long before getting anywhere near the ground. Am I doing something wrong?

[ghimb2000]

Does it consistently do that? Even if you restart the game?

Is the craft all stock or if not can you still reproduce it with an all stock craft and then send me the craft file please?

Seems like the craft file was built when I had SetiCtt installed which made some parts physicsless. After I uninstalled SetiCtt, while still having the craft loaded on the launchpad, it still lags.

Seems like the craft file also loads the parts physicsless even when the original part is not overidden anymore in the game.

I tried a stock sandbox mode and the error messages are gone.

[Starwaster]

Im sorry starwaster i tried everthing i could, i still have the same problem. The heatshields are facing the wrong way around...

I completly reeninstallerd ksp and only used the newest dre version, but its still not working.

The config files should be correct, they all have the "node_stack_bottom = 0.0, -0.01, 0.0, 0.0, -1.0, 0.0, 1 " entry

example from part_1_25M.cfg:

// --- node definitions ---

// definition format is Position X, Position Y, Position Z, Up X, Up Y, Up Z

node_stack_top = 0.0, 0.1, 0.0, 0.0, 1.0, 0.0, 1

node_stack_bottom = 0.0, -0.12, 0.0, 0.0, -1.0, 0.0, 1

Try moving the shield away very slightly, just a hairsbreadth away.

@Starwaster - I have installed 7.0.2. Still having the severe framerate problem. I did as you suggested and tried reverting to launch - this causes a CTD, with the error log saying I'm out of memory - however the ALT-F12 performance window said I was only using 1.2GB ram before the 'revert'. I'm seeing a lot of errors in output_log from ModularFlightIntegrator complaining about heating stuff, which is why I was previously thinking this might be a FAR compatibility thing, since FAR requires MFI. Here's a link to the crash log directory (zip file containing all 4 files including output_log): https://www.dropbox.com/s/qpqacbwfilc2mb2/2015-05-16_211352.zip?dl=0

You installed with CKAN right? Download ModularFlightIntegrator from here and replace the one you have with it: https://ksp.sarbian.com/jenkins/job/ModularFlightIntegrator/

(CKAN is grabbing the wrong version)

This is a little vague, but DRE (+nuFAR) seems a lot more, well, deadly than in 0.90 (with oldFAR).

A couple of times now, I've dropped from LKO a Mk I capsule with a RealChute on its nose by adjusting the periapsis down to about 50km and dropping the engine. In 0.90 this would be completely undramatic; in 1.0 DRE the chute gets up to above 1400 Kelvin (nearly exploding) and the AblativeShielding is exhausted long before getting anywhere near the ground. Am I doing something wrong?

Make your periapsis 20km

Seems like the craft file was built when I had SetiCtt installed which made some parts physicsless. After I uninstalled SetiCtt, while still having the craft loaded on the launchpad, it still lags.

Seems like the craft file also loads the parts physicsless even when the original part is not overidden anymore in the game.

I tried a stock sandbox mode and the error messages are gone.

I'm taking all of the debugging messages out next update. If that's why you and others are lagging then it will stop the lag, but if there's no PartThermalData for a part then it can't undergo heating. The only thing I can think is that another of your mods are interfering with that.

[damerell]

Make your periapsis 20km

I fear my understanding is a bit limited here. I thought that trying to bleed off as much energy as possible in the upper atmosphere was the way to go, and that hammering straight in to where the air is thick would make things worse. Is there some sort of "re-entry for idiots" guide that explains why it's the other way around? Wikipedia's not as much help as I hoped.

[Starwaster]

I fear my understanding is a bit limited here. I thought that trying to bleed off as much energy as possible in the upper atmosphere was the way to go, and that hammering straight in to where the air is thick would make things worse. Is there some sort of "re-entry for idiots" guide that explains why it's the other way around? Wikipedia's not as much help as I hoped.

For a planet Kerbin's size and at the velocities you're coming in at, 20km periapsis lets you brake at a rate that won't kill your Kerbals or burn through your shield too quickly.

Edited May 17, 2015 by Starwaster

[futrtrubl]

I fear my understanding is a bit limited here. I thought that trying to bleed off as much energy as possible in the upper atmosphere was the way to go, and that hammering straight in to where the air is thick would make things worse. Is there some sort of "re-entry for idiots" guide that explains why it's the other way around? Wikipedia's not as much help as I hoped.

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.

Edited May 17, 2015 by futrtrubl

[damerell]

Leave aside the bafflement on my part; if I come in for periapsis at 20km, the chute (undeployed, just to be clear I haven't made the obvious silly mistake) explodes about 28km up.

I wondered if this is because RealChutes are potentially very light (giving them a very low skin thermal mass, even though RealChutes thinks the case is a fixed mass), but giving the chute the maximum specs for the case size that fits the Mk I doesn't help.

[futrtrubl]

Leave aside the bafflement on my part; if I come in for periapsis at 20km, the chute (undeployed, just to be clear I haven't made the obvious silly mistake) explodes about 28km up.

I wondered if this is because RealChutes are potentially very light (giving them a very low skin thermal mass, even though RealChutes thinks the case is a fixed mass), but giving the chute the maximum specs for the case size that fits the Mk I doesn't help.

Is it well shielded from the air stream? If it is then it is probably conduction moving heat into it from another part. Bring up the heat debug and see where the heat is coming from.

[Frimi_2]

According deadly launches... I think the exitement have been a little early. Parts with low maximal temperature (Jebcasings, Fins, Legs) but eveb with higher values (Illuminators) still get fried for no appearend reason. (part temperature near zero in upper atmosphere)

I can defently confirm the connection between direct sunlight an the pseudo overheatings. By launching at night the overheatings occur later and less likely, but strangly its alwasy the jeb casing that pulverises first. And it happens all inside a procedural faring that states parts are shielded.

So no thermal gradient from near hot surfaces, no atmosphere therefore no condunction, no convection let only the suns radiation as source.

@Starwaster, are you sure the shielded coding is inside?

Or am I missing something?

I noticed aomething wiered in the temperatures, besides very long lines of zeros in the cecimal values... The parts explode if the temperature gets a value ot e.g. 8.079° with a max temperature of 800°

So now, guys depending in with coutry you live in, you will say yea its correct the part regulary is overheating or you will say it can't be. Its eigher 8079°C or it's 8 POINT 079°C

But eigher way, Starwaster... could it be possible that DR interpretating points and komas the wrong way?

Edited May 17, 2015 by Frimi_2

[steve_v]

I'm having issues with parachutes during reentry too, FWIW.

DRE (current), FAR (current git) nothing else that interferes with physics AFAIK.

Skintemp reaches ~1500 and causes destruction long before deployment altitude. The pod itself is at reasonable temperatures, and has plenty of ablator remaining at this point. I can re-enter the pod intact fairly easily, but can't seem to find a placement that keeps the 'chutes cool, even with deliberate aerodynamic shielding.

If the 'chutes are on the outside of the craft they explode, usually at 20-30KM.

I've tried several entry angles (from ~100KM equatorial) ranging from 55KM down to -50KM pe with very limited success.

I don't think it's a design issue as it's just a mk.1 pod with a realchute cone on the top stack node.

It may be just my piloting, and I realize much has changed, but it sure wasn't this deadly in 0.90... Is something up or am I just being a wuss?

--edit--

Nevermind. All working as expected now, having re-installed DRE & FAR, and culled some old local MM stuff.

As you were.

Edited May 17, 2015 by steve_v

[damerell]

Is it well shielded from the air stream? If it is then it is probably conduction moving heat into it from another part. Bring up the heat debug and see where the heat is coming from.

The craft consists of two parts - a Mk I capsule and a RealChute; the former's temperature and skin temperature are well below the chute's, so conduction would rather violate the second law of thermodynamics. The chute is about as well shielded from the airstream as anything can be, being on top of the capsule which is moving directly retrograde.

What I'm getting at is that in 0.90 DRE+FAR, a Mk I capsule with a parachute on top was a reliable re-entry vehicle. In 1.0 land, it's hideously unreliable. I don't know what changed; is it an intentional change in DRE? A flaw? Or just that I used to do something which never should have worked but 0.90 DRE happened not to punish?

[Starwaster]

According deadly launches... I think the exitement have been a little early. Parts with low maximal temperature (Jebcasings, Fins, Legs) but eveb with higher values (Illuminators) still get fried for no appearend reason. (part temperature near zero in upper atmosphere)

I can defently confirm the connection between direct sunlight an the pseudo overheatings. By launching at night the overheatings occur later and less likely, but strangly its alwasy the jeb casing that pulverises first. And it happens all inside a procedural faring that states parts are shielded.

So no thermal gradient from near hot surfaces, no atmosphere therefore no condunction, no convection let only the suns radiation as source.

@Starwaster, are you sure the shielded coding is inside?

Or am I missing something?

I noticed aomething wiered in the temperatures, besides very long lines of zeros in the cecimal values... The parts explode if the temperature gets a value ot e.g. 8.079° with a max temperature of 800°

So now, guys depending in with coutry you live in, you will say yea its correct the part regulary is overheating or you will say it can't be. Its eigher 8079°C or it's 8 POINT 079°C

But eigher way, Starwaster... could it be possible that DR interpretating points and komas the wrong way?

DRE checks for shielding (from cargo bays and and fairings) based on a field called ShieldedFromAirstream (see below). If the property is set then convection heating isn't applied. I didn't do it for radiation heating but I can change that for next update and it would make sense to do so. Though I doubt you're getting parts destroyed from radiant energy. (btw, radiation heating is only calculated from the background and from shockwave temperature. Parts don't radiate heat into other nearby parts. Just FYI)

I'm not sure what you're referring to about long lines of zeroes. As of (I think) last update, everything uses two decimal places of significance only. If you see something different then you need to update.

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

Is it well shielded from the air stream? If it is then it is probably conduction moving heat into it from another part. Bring up the heat debug and see where the heat is coming from.

The craft consists of two parts - a Mk I capsule and a RealChute; the former's temperature and skin temperature are well below the chute's, so conduction would rather violate the second law of thermodynamics. The chute is about as well shielded from the airstream as anything can be, being on top of the capsule which is moving directly retrograde.

What I'm getting at is that in 0.90 DRE+FAR, a Mk I capsule with a parachute on top was a reliable re-entry vehicle. In 1.0 land, it's hideously unreliable. I don't know what changed; is it an intentional change in DRE? A flaw? Or just that I used to do something which never should have worked but 0.90 DRE happened not to punish?

Again, use the debug menu and enable the option that displays thermal information in the action menus. Then you can see exactly where the heat is coming from (convection, radiation or conduction).

Without more info all I can say is I've done a lot of Mk1 reentries and didn't have my chute part burn up on me.

[Sokar408]

I have an issue with DRE and FAR. I have down a clean install of both several times, but I still get the same result every time.

My method of testing is as follows:

Made a craft (Parachute, Mk1 Pod, Heat Shield). HyperEdit'd to 1 mill km orbit. Adjust Prograde Speed by -500. Then let the craft reenter the atmosphere, with the heat shield in front.

What happens?

The heat shield loses about some Ablator, though the Pod's ablator much more rapidly depleted, and the pod is destroyed. The speed of reentry (speed at 70 km altitude) is 2675 m/s, and the speed at which the pod is destroyed is 2509 m/s. This is DRE own 1.25 meter heat shield. Same happeneds with stuck heat shield. Even with a 2.5 meter heat shield, the same thing happens. The interesting thing is, that it doesn't matter if its a pod that is next to the heat shield. If I add a fuel tank there instead, the same thing happens, just a lot more rapidly (the fuel tank explodes). It seems as though the heat shield allows almost all the heat to pass through it, until whatever is next to it.

Is there any solution to this.

[Ser]

Starwaster,

I'm trying a rentry with a craft consisting of a heatshield, a service bay, then go two material bays, a crew pod and a chute. Reentering pointing the heatshiled exactly prograde so the parts are all behind it.

No matter what I do, my material bays always overheat. Am I right that they overheat due to their small thermal mass (160)? In their action menus I see that the main source of the heating is convection (over 2000). What should I do to save them?

[damerell]

Again, use the debug menu and enable the option that displays thermal information in the action menus. Then you can see exactly where the heat is coming from (convection, radiation or conduction).

OK. This is a Mk I + chute re-entering from an 80km orbit by lowering periapsis to 20km, as you suggested. MechJeb is flying it surface retrograde; the chute is as well protected by the capsule as possible. The chute is specced for the maximum vessel mass RealChute will allow in this size; it weighs 200kg with a skin thermal mass of 20kg, about 1/3-1/4 that of the capsule.

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.

At 50km the capsule is at 328K skin, 313K internal. The chute has risen to 988K skin temperature, 555K internal. Flux: -3.6, 193, -2428, 479.

40km: capsule, 407K, 371K. Chute: 1239K, 757K. Chute flux: -5.7, 531, -6535, 537.

At 32km the chute explodes. The capsule is now at 493K skin, 435 internal. Ablation has begun.

The capsule's skin temperature does not exceed 577K during the rest of the descent, with 75% Ablative Shielding left at impact. Everything worked as expected, except that as far as I can make out the chute suffers massive skin heating from the airstream it isn't in, and that destroys it.

I've just read the scored-out text in steve's post above. I'll manually install the most recent FAR, DRE, FlightIntegrator and report back.

[Ser]

The same for my material bays. They have skin temperature at least 200K higher than the parts in front of them.

Edited May 17, 2015 by Ser

[damerell]

I've just read the scored-out text in steve's post above. I'll manually install the most recent FAR, DRE, FlightIntegrator and report back.

Oddly, while the chute exploded at 32km as before, the capsule got much hotter - rising to 977K, and having 0.02 Ablative Shielding left at impact time.

I'm particularly puzzled by this because the manually installed versions seem to be the same as the CKAN-installed versions I had before. (Yes, I did put the fix into FlightIntegrator from upthread.) I am absolutely sure I still used a 20km periapsis.

[Frimi_2]

DRE checks for shielding (from cargo bays and and fairings) based on a field called ShieldedFromAirstream (see below). If the property is set then convection heating isn't applied. I didn't do it for radiation heating but I can change that for next update and it would make sense to do so. Though I doubt you're getting parts destroyed from radiant energy. (btw, radiation heating is only calculated from the background and from shockwave temperature. Parts don't radiate heat into other nearby parts. Just FYI)

I'm not sure what you're referring to about long lines of zeroes. As of (I think) last update, everything uses two decimal places of significance only. If you see something different then you need to update.

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

Okay so far so good. Forget that thing with the decimal places. It's just the teperature mod that doesn't round up the numbers....

Besides shielding from raiation does make sense after all.

Point 1: Exploding Jebs, the casings have a thermal mass of 0. I wasn't able to confirm that is the reason it explodes every time because I can't find the value to edit but I think this might be it. If I understand your coding correctly you calculate the thermal mass as a factor in the overheating limit. Then it makes perfecly sense that it explode instantly.

Point 2: Exploding parts in the upper atmosphere fairing independed explosions. Here also helped turn off the radiation. If turned on after gaining some distance to kerben they survive strangely.

The explodings parts (illuminator, landing struts, solar panels have a thermal mass of 0.12 maybe it would make sense to tweak this value a little?

You know your balancing values better.

But it is kinda odd wy no further explosions happens after gaining some distance. Does Kerben emmit radiation heating?

[Olsson]

There seems to be alot of discussion going on here.

Does this work well with 1.02 and the stock aerodynamics?

Like earlier versions of Deadly Re-entry is the capsule mass offset slightly to create up or downlift if you spin it facing up or down?

[Starwaster]

The same for my material bays. They have skin temperature at least 200K higher than the parts in front of them.

I'll take a look at material bays today. When did you have problems with them, during reentry or launch? Or both?

OK. This is a Mk I + chute re-entering from an 80km orbit by lowering periapsis to 20km, as you suggested. MechJeb is flying it surface retrograde; the chute is as well protected by the capsule as possible. The chute is specced for the maximum vessel mass RealChute will allow in this size; it weighs 200kg with a skin thermal mass of 20kg, about 1/3-1/4 that of the capsule.

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.

At 50km the capsule is at 328K skin, 313K internal. The chute has risen to 988K skin temperature, 555K internal. Flux: -3.6, 193, -2428, 479.

40km: capsule, 407K, 371K. Chute: 1239K, 757K. Chute flux: -5.7, 531, -6535, 537.

At 32km the chute explodes. The capsule is now at 493K skin, 435 internal. Ablation has begun.

The capsule's skin temperature does not exceed 577K during the rest of the descent, with 75% Ablative Shielding left at impact. Everything worked as expected, except that as far as I can make out the chute suffers massive skin heating from the airstream it isn't in, and that destroys it.

I've just read the scored-out text in steve's post above. I'll manually install the most recent FAR, DRE, FlightIntegrator and report back.

I suspect the issue is caused by FAR. Most likely it's affecting stock occlusion of parts. DRE changes how convective heating affects parts but it doesn't change when convection occurs. It relies on the stock code to tell it that something is or is not experiencing convective heating. That part's not under my control.

So I'll have to look at enhancing its survivability, but that has to be done carefully so it doesn't become impervious.

Okay so far so good. Forget that thing with the decimal places. It's just the teperature mod that doesn't round up the numbers....

Besides shielding from raiation does make sense after all.

Point 1: Exploding Jebs, the casings have a thermal mass of 0. I wasn't able to confirm that is the reason it explodes every time because I can't find the value to edit but I think this might be it. If I understand your coding correctly you calculate the thermal mass as a factor in the overheating limit. Then it makes perfecly sense that it explode instantly.

It's unlikely to have thermal mass of 0 unless it had mass 0. It's probably just so low that it's not registering in whatever you're using.

Its (skin) thermal mass is probably something like (back of envelope calculation)

0.0008 (based on its part mass of 10 grams. Yes, that's right. The case weighs 10 grams). I'll try giving it a skinThermalMassMultiplier of 100. That should effectively give it the thermal mass of a 1 kilogram object. We'll see if that helps.

Point 2: Exploding parts in the upper atmosphere fairing independed explosions. Here also helped turn off the radiation. If turned on after gaining some distance to kerben they survive strangely.

The explodings parts (illuminator, landing struts, solar panels have a thermal mass of 0.12 maybe it would make sense to tweak this value a little?

Probably. Their base thermal mass is actually 10x higher but it's their skinThermalMass that's low. Given that these are flat thin plates, it doesn't make sense that they get the same treatment as more voluminous objects.

But it is kinda odd wy no further explosions happens after gaining some distance. Does Kerben emmit radiation heating?

Yes, it does and a substantial amount of it too. IRL, the heat emanating from the Earth has to be accounted for as well, when considering thermal management. Mission planning for future craft utilizing cryogenic fuels have to take that into account as it affects the amount of thermal energy you have to deal with when refrigerating your tanks (for zero-boiloff schemes)

There seems to be alot of discussion going on here.

Does this work well with 1.02 and the stock aerodynamics?

Like earlier versions of Deadly Re-entry is the capsule mass offset slightly to create up or downlift if you spin it facing up or down?

The most recent edition was designed around the stock aerothermodynamics. DRE implements no CoM, CoL or CoP offsets. I'll leave that to other mods like Realism Overhaul

Edited May 17, 2015 by Starwaster

[Adamantium9001]

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?

[ExEvolution]

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