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

[Starwaster]

I think people use RealHeat for RSS

I had a peculiar "problem" yesterday. I noticed a few pages back that an aggressive gravity turn can blow you up on ascent. However, yesterday I had a quite inefficient one, basically going up until I depleted my first stage, then going mostly sideways with my second stage. My apoapsis after the first stage was around 60 km, rising a bit as I burned. Then, when I got close to orbital velocity, I started getting atmosphere heating. To the point of my parachute almost exploding! Like wat! I literally could not make it into orbit from 65 km up because by the time I noticed the severity of the problem, I was already going down. I had to abort the mission to save Valentina. Anyone know anything I can do to make it... not awful, while keeping the difficulty of reentry intact?

(I use both FAR and DRE, as well as stock sized Kerbin.)

Un a slightly unrelated note, Jeb died because he did the exact same mission wonderfully, but on the way down the heat shield crashed into the pod when I released it and he died! Not an issue, per se, I just wanted to rage.

Enclose the capsule in a fairing. The latest DRE version will let you add heat shield to the fairings (right click and use the tweak bar) (preferably from the Procedural Fairing mod rather than the stock ones, which can throw errors if you jettison the fairing while the temperature is above ablation temperatures)

- - - Updated - - -

After scrolling through this many posts, I just still cannot figure out what settings I should apply in RSS to get those shields not to explode...

Any already tested settings?

If you have the latest DRE then it will reconfigure its shields to withstand a RSS reentry. Perhaps your reentry profile is the problem (too steep or too shallow). Try aiming for a periapsis of about 60?

[Gryphon]

I think people use RealHeat for RSS

I had a peculiar "problem" yesterday. I noticed a few pages back that an aggressive gravity turn can blow you up on ascent. However, yesterday I had a quite inefficient one, basically going up until I depleted my first stage, then going mostly sideways with my second stage. My apoapsis after the first stage was around 60 km, rising a bit as I burned. Then, when I got close to orbital velocity, I started getting atmosphere heating. To the point of my parachute almost exploding! Like wat! I literally could not make it into orbit from 65 km up because by the time I noticed the severity of the problem, I was already going down. I had to abort the mission to save Valentina. Anyone know anything I can do to make it... not awful, while keeping the difficulty of reentry intact?

(I use both FAR and DRE, as well as stock sized Kerbin.)

Un a slightly unrelated note, Jeb died because he did the exact same mission wonderfully, but on the way down the heat shield crashed into the pod when I released it and he died! Not an issue, per se, I just wanted to rage.

First, how fast are you going on ascent? If your acceleration is really aggressive, then you might be building heat earlier in ascent that you just aren't getting rid of. If so, then building on it going really fast in the upper atmosphere could do the rest of the job.

My launch profile with FAR and DR is full throttle until I get to 3 or 4 kPa of dynamic pressure, about 80m/s or so. Then I throttle down, still keeping TWR above 1. The dynamic pressure will keep increasing, but more slowly. As the ship lightens, I keep throttling down until Dyn. Pressure finally starts dropping. Then I slowly start throttling back up. Sometime after the return to full throttle, I kill the FAR display.

As long as I have enough delta V and TWR (and point the right direction), this gets me to orbit safely all the time. Oh, I should also add that usually at least 1000m/s of the orbital velocity is applied above 70km altitude. I won't claim that this profile gives me maximum efficiency, but it's safe and it works.

I also use KCT, which allows for simulated launches, so I simulate most of my craft before actually building them.

[01010101lzy]

Enclose the capsule in a fairing. The latest DRE version will let you add heat shield to the fairings (right click and use the tweak bar) (preferably from the Procedural Fairing mod rather than the stock ones, which can throw errors if you jettison the fairing while the temperature is above ablation temperatures)

- - - Updated - - -

If you have the latest DRE then it will reconfigure its shields to withstand a RSS reentry. Perhaps your reentry profile is the problem (too steep or too shallow). Try aiming for a periapsis of about 60?

I had a Pe of about 60km, but the stock shield (because I installed StockRevamp, and the DRE shield doesn't fit the MK1-2 pod anymore) seems to be too weak to stand the heat...

Yes, I had RealHeat installed, but there was nothing different... (Well, when RH and DRE are both installed, which will provide the reentry heat?)

Also, I changed the hsp of AblativeShielding to 700 but my pod still cannot survive the reentry.

--edit--

Testing this config for stock shields, config changed from DRE's RSS config.

@PART
[*]:HAS[ModuleAblator]:AFTER[DeadlyReentry]:NEEDS[RealSolarSystem,!RealismOverhaul]{
    @MODULE[ModuleAblator]
    {
        @name = ModuleHeatShield
        // Globally, the base is 5. Consider making this 8.75 for all but Mk1pod
        @lossConst *= 0.0008
        @pyrolysisLossFactor *= 50
    }
}

--edit--

It worked!

Could you please add it into DRE's RSS config?

Also, my testing convection factor is 4.68 and it works fine.

Edited August 8, 2015 by 01010101lzy

[Starwaster]

Ok, looks like there's a problem a few places in the general config as all ModuleAblator shields are supposed to have already been converted before getting to the RSS section.

[01010101lzy]

Ok, looks like there's a problem a few places in the general config as all ModuleAblator shields are supposed to have already been converted before getting to the RSS section.

Actrually it was more likely to have no ModuleAblator converted...

[Starwaster]

Actrually it was more likely to have no ModuleAblator converted...

... hence why I said there was a problem in some configs

[Hogbobson]

Enclose the capsule in a fairing. The latest DRE version will let you add heat shield to the fairings (right click and use the tweak bar) (preferably from the Procedural Fairing mod rather than the stock ones, which can throw errors if you jettison the fairing while the temperature is above ablation temperatures)

- - - Updated - - -

Fairings worked wonderfully! Thanks!

[Nertea]

Starwaster, I'd like to request some changes to DRE re: it severely messsing with my mod. You do this thing where you define an arbitrary ridiculous maximum temp, and if a part has a higher maxTemp than than, you reduce the it. This breaks my reactors in Near Future Electrical, which depend on the internal temperature reaching a particular value (usually around 800K) to generate power. The reactors try to get to this temperature, then melt down and explode because the maxTemp is lower than expected (typically supposed to be ~1600K)

I don't really get why you do this in plugin code instead of with MM, where you could more easily do dependency checking. I'd like to request you either add a check against a FissionGenerator module before you scale the temp, or alternately if you really must reduce the temperature, actually handle the proper fields in the FissionGenerator (reduce the nominal temperatures). I notice you could still do this LeaveTemp in an added ModuleAeroReentry, but I would really not rather have additional code/patches to unbreak my mods when other mods break them.

[Starwaster]

Starwaster, I'd like to request some changes to DRE re: it severely messsing with my mod. You do this thing where you define an arbitrary ridiculous maximum temp, and if a part has a higher maxTemp than than, you reduce the it. This breaks my reactors in Near Future Electrical, which depend on the internal temperature reaching a particular value (usually around 800K) to generate power. The reactors try to get to this temperature, then melt down and explode because the maxTemp is lower than expected (typically supposed to be ~1600K)

I don't really get why you do this in plugin code instead of with MM, where you could more easily do dependency checking. I'd like to request you either add a check against a FissionGenerator module before you scale the temp, or alternately if you really must reduce the temperature, actually handle the proper fields in the FissionGenerator (reduce the nominal temperatures). I notice you could still do this LeaveTemp in an added ModuleAeroReentry, but I would really not rather have additional code/patches to unbreak my mods when other mods break them.

Why not put leaveTemp in the main body of your part config? That is checked for and added to the part's ModuleAeroReentry during MM config processing.

[Trolllception]

The KSPI mod also suffers from a similar fate as Nertea mentioned above. The radiators are rendered useless since they cannot heat up to the proper temperature to radiate heat.

[Starwaster]

I remember KSPI issues being brought up a couple of months back and some suggestions were made, including suggesting the use of leaveTemp after that no further mention of KSPI problems was made so I assumed that that was the end of it.

If people want to have radiators dissipating gigawatts and gigawatts of heat and DRE compromises their ability to do that.... Well, I think suggesting the use of something that was put in place to allow people to exempt their parts from DRE modification is a reasonable solution.

[Trolllception]

I am going to attempt to add the leaveTemp flag to the KSPI parts for FreeThinker. Is there an example of the proper syntax used on a part somewhere? I am a bit new to KSP modding still. I intend to add the leaveTemp sections using a module manager patch only if DeadlyRentry is present.

Edit: Disregard. I found this flag being used in the mk3 fuselage. %leaveTemp = True

Edited August 14, 2015 by Trolllception

[Starwaster]

I am going to attempt to add the leaveTemp flag to the KSPI parts for FreeThinker. Is there an example of the proper syntax used on a part somewhere? I am a bit new to KSP modding still. I intend to add the leaveTemp sections using a module manager patch only if DeadlyRentry is present.

Edit: Disregard. I found this flag being used in the mk3 fuselage. %leaveTemp = True

If KSPI engines also have a problem then they'll need the updated version of this file: https://raw.githubusercontent.com/Starwaster/DeadlyReentry/master/DeadlyReentry/EngineHeatAdjuster.cfg

(it'll be in the next update for DRE)

[damerell]

Starwaster, I'd like to request some changes to DRE re: it severely messsing with my mod. You do this thing where you define an arbitrary ridiculous maximum temp, and if a part has a higher maxTemp than than, you reduce the it.

I admit the fixed absolute max temperature always struck me as slightly vexing in that it elides the entire difference between parts with a higher maxTemp. (On the other hand, one might reasonably say that titanium melts at 1941K and anything more complicated than a girder getting into that vicinity is absurd).

I'd like to suggest (and I appreciate the answer may be "do your own") two values for ridiculous maxTemps which I'll call n and m, and the range n-infinity is mapped onto n-m via some reasonable function. If a mod specifically needs parts to be able to get to a certain temperature the value of m could then be adjusted.

[Starwaster]

I admit the fixed absolute max temperature always struck me as slightly vexing in that it elides the entire difference between parts with a higher maxTemp. (On the other hand, one might reasonably say that titanium melts at 1941K and anything more complicated than a girder getting into that vicinity is absurd).

I'd like to suggest (and I appreciate the answer may be "do your own") two values for ridiculous maxTemps which I'll call n and m, and the range n-infinity is mapped onto n-m via some reasonable function. If a mod specifically needs parts to be able to get to a certain temperature the value of m could then be adjusted.

what are the advantages over a setting that let's modders opt out and say they'll be responsible for their own max temps?

[Trolllception]

If KSPI engines also have a problem then they'll need the updated version of this file: https://raw.githubusercontent.com/Starwaster/DeadlyReentry/master/DeadlyReentry/EngineHeatAdjuster.cfg

(it'll be in the next update for DRE)

In theory should something like this should work to add the variable to all parts with the Wasteheat resource? I'll have to test once I get home. This will 'break' deadly reentry on all of those parts though since they will have such a high heat tolerance that deadly reentry would have difficulty destroying them. Although I noticed things like KSPI radiators make awesome 120 m/s landing gears since they appear to be almost indestructible already.

@PART

[*]:HAS[@RESOURCE[WasteHeat]:NEEDS[DeadlyRentry]

{

%leaveTemp = True

}

Edit: Actually I may want to filter this a bit more since this may only need to apply to radiators and not solar panels which also contains wasteheat.

Edited August 14, 2015 by Trolllception

[Starwaster]

In theory should something like this should work to add the variable to all parts with the Wasteheat resource? I'll have to test once I get home. This will 'break' deadly reentry on all of those parts though since they will have such a high heat tolerance that deadly reentry would have difficulty destroying them. Although I noticed things like KSPI radiators make awesome 120 m/s landing gears since they appear to be almost indestructible already.

@PART

[*]:HAS[@RESOURCE[WasteHeat]:NEEDS[DeadlyRentry]

{

%leaveTemp = True

}

Edit: Actually I may want to filter this a bit more since this may only need to apply to radiators and not solar panels which also contains wasteheat.

Added a missing bracket and fixed spelling. (also indented because I'm an indentation [CENSORED POLITICAL PARTY THAT WE ARE APPARENTLY NOT ALLOWED TO SAY])

@PART
[*]:HAS[@RESOURCE[WasteHeat]]:NEEDS[DeadlyReentry]
{
    %leaveTemp = True
}

Edited August 14, 2015 by Starwaster

[Trolllception]

Added a missing bracket and fixed spelling. (also indented because I'm an indentation [CENSORED POLITICAL PARTY THAT WE ARE APPARENTLY NOT ALLOWED TO SAY])

@PART
[*]:HAS[@RESOURCE[WasteHeat]]:NEEDS[DeadlyReentry]
{
     %leaveTemp = True
}

Hah. I like the part about the indentation. That bothers me big time when writing Powershell or C# code. In notepad++ I do have the indentation.

I think this will be closer to the version I end up going with. I would rather not have the heat values increased on solar panels as those are prime objects to be destroyed via reentry. I still need to check if this is even needed though since the WasteHeat and heat values used by KSPI is not the same as a stock heating model. I'll update this post/create a new one once i've tested and confirmed this resolves the issues I was experiencing. I will be happy again if I can use FAR + DRE with KSPI. Thanks for the assistance.

@PART
[*]:HAS[@MODULE[*FNRadiator]]:NEEDS[DeadlyReentry]
{
     %leaveTemp = True
}

[Gryphon]

[DeadlyRentry]

...fixed spelling.....

Wait - isn't this the mod for making renting deadlier in KSP? If it's not, that explains a lot about my career game.

[damerell]

what are the advantages over a setting that let's modders opt out and say they'll be responsible for their own max temps?

It would preserve the ordering of maximum temperatures without specific action for a given mod.

[Starwaster]

It would preserve the ordering of maximum temperatures without specific action for a given mod.

But what does that mean?

And, why is it an advantage?

And what IS the proposal?

Can you provide a clear and concise example of it in action? And demonstrate why doing it that way is an advantage to a setting which if applied allows other modders to not have their part's maxTemperature tampered with at all?

Because I'm still not getting it

[damerell]

Well, let's start with "what is the proposal", if you'll forgive a very MS Paint diagram:

The red line is the current behaviour of DRE. The orange line diverges from the red line at the lower of two "ridiculous" temperatures and approaches a higher absolute maximum "ridiculous" temperature; any number of functions might give a suitable curve.

The advantage from my point of view, as a user, is that I might like to preserve the intended ordering of maxTemp in a mod (ie, if part A's maxTemp was below part B's without DRE, that will remain the case albeit that the absolute values will change) without giving the modder carte blanche to make everything indestructible.

[Starwaster]

Well, let's start with "what is the proposal", if you'll forgive a very MS Paint diagram:

http://www.chiark.greenend.org.uk/~damerell/games/ksp/DRE.png

The red line is the current behaviour of DRE. The orange line diverges from the red line at the lower of two "ridiculous" temperatures and approaches a higher absolute maximum "ridiculous" temperature; any number of functions might give a suitable curve.

The advantage from my point of view, as a user, is that I might like to preserve the intended ordering of maxTemp in a mod (ie, if part A's maxTemp was below part B's without DRE, that will remain the case albeit that the absolute values will change) without giving the modder carte blanche to make everything indestructible.

But I don't actually care if another modder makes their parts indestructible. I might not agree with it, I might think it's stupid and pointless but I don't think the original intention of ridiculousMaxTemp was to flat out prohibit that sort of thing. Only to try to sanitize max temp choices that were made without proper consideration as to consequence. (most of those choices were made at a time that predated any sort of reentry heating at all)

[hewi212]

Hey, not sure if anyone has seen this:

But would anyone know how he did those smoke trails?, he said he modified the DR source code to include the effects.

[Starwaster]

Hey, not sure if anyone has seen this:

But would anyone know how he did those smoke trails?, he said he modified the DR source code to include the effects.

The source already has code to emit fire and smoke when a part is on fire. He probably modified that code.

(the current version does not have fire damage in; It's on my TODO list to add it back)