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

[Starwaster]

I got DRE to blow up a ship on the pad in my career again. Shame the first time it happened last night was during an early tourist mission. Whoops! At least it wasn't an expensive astronaut!

Here's a zip of KSP.log as well as output_log. I don't see a player.log file anywhere around however.

DRE-Boom

The remains of the rocket on the launchpad looked like they were getting reentry heating. Before the boom I had just viewed a vessel that was orbiting kerbin from the tracking station. Then went to VAB and launchpad and instant boom. Just search the log for "Exploded" but I don't see anything strange in the log at or around that point.

Ok, there is an error that occurs when the vessel loads in. The error is in one of FAR's methods but I'm not pointing the finger at FAR... could be an issue with the ModularFlightIntegrator which we both use to override physics.

I'll look into that some more.

So then why set heatproduction to 350 on the basic engine is that realistic?

- - - Updated - - -

Genuinely asking I have no idea

If heatproduction were changed, it would be because maxTemp was lowered. If that happens, heatproduction has to be lowered a proportional amount. So if it's 350 now and DRE did it, that means it was should have been higher before.

Edit: Oh crap, ok I see it now....

Edited May 13, 2015 by Starwaster

[Svm420]

, it would be because maxTemp was lowered. If that happens, heatproduction has to be lowered a proportional amount. So if it's 350 now and DRE did it, that means it was higher before.

It was 40 I misread maxthrust in stock cfg

MODULE    {
        name = ModuleEnginesFX
        engineID = Cruise
        thrustVectorTransformName = thrustTransform
        exhaustDamage = True
        ignitionThreshold = 0.1
        minThrust = 0
        maxThrust = 115
        heatProduction = 40

Your DeadlyReentry.cfg

@PART[JetEngine]{
    @maxTemp = 1800
    @MODULE[ModuleEngines]
    {
        @heatProduction = 350
    }
    @MODULE[ModuleEnginesFX]
    {
        @heatProduction = 350
    }
}

- - - Updated - - -

I am very confused

- - - Updated - - -

Yay not crazy order of magnitude off eh?

Edited May 13, 2015 by Svm420

[Starwaster]

Ok, EVERYONE replace your DeadlyReentry.cfg file (in the DeadlyReentry folder) with this version. (naturally this will be in the next update but grab it now if you want to plane)

https://raw.githubusercontent.com/Starwaster/DeadlyReentry/master/DeadlyReentry/DeadlyReentry.cfg

In fact just grab it now

[Svm420]

WOuld rep you more but can't for now Thank you Starwaster

[Starwaster]

WOuld rep you more but can't for now Thank you Starwaster

well just smack someone else over the head and take their rep

[ss8913]

Use dropbox. If the file is more than a few MB then zip it up

https://www.dropbox.com/s/zuxm8nbt4t7okb7/KSP-DRE-error.log?dl=0

There's the log. It's about 4MB uncompressed. This is after my most recent attempt - I simply started KSP, selected a spaceplane, put it on the runway, saw the FPS be in the toilet (below 10!), and exited KSP. This is the log from that run.

Moving DeadlyReentry/ out of my GameData folder and then repeating the process yielded a nice smooth 60FPS.

I am using the latest version of FAR and DRE, plus several other mods, which should be apparent from the log

[Starwaster]

https://www.dropbox.com/s/zuxm8nbt4t7okb7/KSP-DRE-error.log?dl=0

There's the log. It's about 4MB uncompressed. This is after my most recent attempt - I simply started KSP, selected a spaceplane, put it on the runway, saw the FPS be in the toilet (below 10!), and exited KSP. This is the log from that run.

Moving DeadlyReentry/ out of my GameData folder and then repeating the process yielded a nice smooth 60FPS.

I am using the latest version of FAR and DRE, plus several other mods, which should be apparent from the log

ok do it again but this time revert to launch and see if that clears it up.

Edit:

I'm not seeing anything in that log to tell me why you're having trouble. Was that ksp.log? It seemed sparse. output_log.txt would be better, maybe there's something in that I can use but as is right now, I'm just not seeing where the problem is.

Edited May 14, 2015 by Starwaster

[AngelLestat]

but it makes it easier to burn things up than the stock system was doing. The way it does this is by taking into account only a fraction of your ship's mass.

(mass is part of how you determine how hot something gets. Example: If you have an object massing 100 kg, another massing 1000 kg and they both absorb 100 kW of heat, the first object will experience a temperature increase 10 times greater than the second object)

Sorry if this was explained before, in that case I would love to be pointed to the answer.

I know that 100kw distributed between 100 kg is very different than between 1000kg.

But that heat conduction to other parts is not instant, so not sure what you want to explain with this example.

Also a 1000kg craft with little surface difference in comparison with a 100kg craft will reach lower atmosphere layers at higher speeds.

Or your comparative is just between heatshields mass?

[ArcFurnace]

Sorry if this was explained before, in that case I would love to be pointed to the answer.

I know that 100kw distributed between 100 kg is very different than between 1000kg.

But that heat conduction to other parts is not instant, so not sure what you want to explain with this example.

Also a 1000kg craft with little surface difference in comparison with a 100kg craft will reach lower atmosphere layers at higher speeds.

Or your comparative is just between heatshields mass?

Basically, with the stock system, a certain amount of heat flux (from the shock compression plasma) is applied to parts. However, in the stock system a single part is modeled as having a single temperature throughout that part, and the entire mass of the part contributes to its thermal mass (how much energy you need to add to raise its temperature by a certain amount). This means that for, say, a big heavy fuel tank, it takes quite a lot of heat to heat it up to the point where it explodes from overheating.

This isn't really realistic. The superheated air is only touching the very outside of a part, and it takes time for that heat to work its way inwards. As such, initially only the very outside of a part heats up, and since only a tiny fraction of the part's mass is involved, it heats up a lot faster (same energy into less mass equals more temperature increase). DeadlyReentry models this by splitting a part into "skin" and "core" sections, with the skin being 10% of the part's mass by default (correct me on this if I'm wrong, Starwaster). Then, if the skin of the part heats up above the part's MaxTemp, you get the superheated plasma burning its way through the skin and destroying the fragile insides.

This ends up being a lot closer to how things work in the real world. It also eliminates one of the oddities you can get in the stock system, namely that you can heat up, say, a crew cabin to 1500 °C throughout its entire mass without converting the passengers into piles of ash. Instead, the insulating skin gets hot but the insides stay cool (if everything is functioning correctly).

I believe Starwaster also dramatically increased the rate of heat transfer from the atmosphere to parts to get something that more closely approximates the heat loads you would see in Earth reentry (~11km/s) despite Kerbin reentry's much lower velocities (~2km/s for orbital, somewhat more for Mun/Minmus return or interplanetary but almost never anywhere near Earth reentry velocity). This makes reentry much more, well, deadly. However, the heatshield parts were similarly buffed to ensure this can be survivable.

Edited May 14, 2015 by ArcFurnace

[Starwaster]

That's essentially how it is ArcFurnace. I've been thinking that 10% is actually maybe too much but wonky things start happening if the thermalMass gets too low. Even wonkier things happen when the heat transfer rate or amount are increased too much. For instance, I've been trying for the past day to make the stock heat shields explode faster when they are depleted. A logical step there was to decrease the thermal mass, but when I did that their temperature pinned to 4k and their radiative energy skyrocketed. Turns out that their temperature went up so high (probably high enough to destroy them outright) but then radiative flux kicked in and because radiation is temperature^4 they dumped all of the heat they had picked up. So, it's actually better if the heat transfer rate isn't sped up too much

(although it was unrealistic, a scaled down version of that is how space shuttle tiles worked. The tiles really can't hold very much heat at all, so when they reach thermal equilibrium they're dumping most of what they have in them so it never gets to conduct very much into the shuttle)

Another thing is conduction. It's been claimed a few places on this forum that the low conduction factor of the stock heat shields is bad because they leak enough to the parts they're attached to. Well, that's true, but too much conduction and they don't get to build it up to the point where they should explode either

so the heat shields are vexing me a bit right now.

[jrandom]

On the plus side, you can model shuttle tiles! This would go great with the heat-shield texture on B9 procedural wings!

(me? dropping hints? naaah...)

[AngelLestat]

Ahh now I understand, so my quote is the thing that the official version does, and DRE fix it. It seems that I dint read very well the same text I was quoting

well good work, I will test it in few days when more mods reach the 1.0 status.

[ZilgornZeypher]

I know 64 bit isn't supported officially anymore for windows but the hack still works will the current version of deadly reentry work ok in 64 bit (I know 64 bit can be derpy and I accept that) I mean more in a case of will Deadly rentry's code work the way it should or do I need to look at the 64 bit .dll from before to try and make it work with 64 bit?

[futrtrubl]

I know 64 bit isn't supported officially anymore for windows but the hack still works will the current version of deadly reentry work ok in 64 bit (I know 64 bit can be derpy and I accept that) I mean more in a case of will Deadly rentry's code work the way it should or do I need to look at the 64 bit .dll from before to try and make it work with 64 bit?

I thought they didn't even release 64 bit KSP 1.0 on Windows. We don't mean that playing on 64bit Windows is disabled or unsupported, we mean the 64bit version of KSP ON windows.

[Starwaster]

• Removed legacy engine configurations which were adding pre-KSP 1.0 levels of heat production. (FIRE BAD!)
  
• Fixed duplicate toolbar button issue
  
• Tweaked convection heating to start EARLIER. Tweaked stock shields to (more or less) their original ablation/pyrolysis levels. For your protection.
  
• Put in checks and guards against null ref errors in UpdateConvection()
  

Known issue:

You may get logged error spam on craft with procedural fairings, namely the base. If this happens just revert to launch, or quicksave then quickload

[smunisto]

Cool, will check to see if something burns up inside PF on launch tonight.

[SR1978]

https://www.dropbox.com/s/zuxm8nbt4t7okb7/KSP-DRE-error.log?dl=0

There's the log. It's about 4MB uncompressed. This is after my most recent attempt - I simply started KSP, selected a spaceplane, put it on the runway, saw the FPS be in the toilet (below 10!), and exited KSP. This is the log from that run.

Moving DeadlyReentry/ out of my GameData folder and then repeating the process yielded a nice smooth 60FPS.

I am using the latest version of FAR and DRE, plus several other mods, which should be apparent from the log

Had the same issue and did some troubleshooting on a clean ksp install.

Have you installed DRE/nuFAR with CKAN? Looks like the version of Modular Flight Integrator delivered by CKAN is not compatible with DRE. Spams the logfile with errors complaining about a modular flight integrator method which cannot be found. Try using the modular flight integrator thats bundled with DRE on github, that works for me. They have the same size but different md5 checksums.

[Revenant503]

I don't think quicksave or revert helps with proc fairings

I got a truckload of this in output_log.txt

MissingMethodException: Method not found: 'ModularFI.ModularFlightIntegrator.get_PartThermalDataList'.

UnityEngine.MonoBehaviour:StartCoroutine_Auto(IEnumerator)

UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator)

DeadlyReentry.ModuleAeroReentry:FixedUpdate()

Ckan install...if that makes any difference but the version numbers match the first page (v7.0.2) and I couldn't see any difference between the packaged ModuleFlightIntegrator and the Ckan version

Just noticed the post above...off to try that

Yep that fixed it...the module flight integrator package on ckan appears to be borked

Edited May 14, 2015 by Revenant503
More info

[Starwaster]

That doesn't sound good. I'll look into it when I'm more fully awake. Thanks for letting me no.

[ZilgornZeypher]

I thought they didn't even release 64 bit KSP 1.0 on Windows. We don't mean that playing on 64bit Windows is disabled or unsupported, we mean the 64bit version of KSP ON windows.

Squad didn't realease KSP 64 bit for windows I know that. However the old "hack" to make KSP run in 64 bit still works. Which was all Squad released really anyway. So I was asking if I needed to update the 64 bit deadly reentry .dll that was used for .90 that someone made or should deadly reentry work more or less correctly without it.

[Snafu225]

Sorry Starwaster but I get really really weird behaviour on reentry.

My craft has an DREC-Heatshield, a coupler node for the US-Bays, a Probe core, two batteries and a Parachute.

On the first try I had a FL-A10 adapter between the probe and the science bays.

While reentering everything worked fine, I had some ablating going on but nothing really that's worth talking about.

Speed was about 1400m/s, altitude must have been around 20k. Suddenly, depends on wether I used the one with adapter or not, either the adapter or the probe core go suddenly poof, without any warning. The stock temperature gauge didn't show anything and everything should be protected by the heatshield. The Ingame log says that those parts overheated. I can try as many times as I want...

Here's the log which is riddled with NREs: https://www.dropbox.com/s/av40verxa8q8uo1/output_log.zip?dl=0

Thanks a lot for this still awesome mod!

[Enceos]

@Starwaster still dropping shieldless pods from Minmus orbit. DRE 7.0.2, 1.0.2 Physics.cfg, max convection. No nuFAR this time.

At 28300 Altitude temperature starts dropping, even though I'm still travelling at orbital velocity. The convection heating starts earlier in this version, but it ends earlier as well.

On the positive note, looked into the ModuleManager cache and found that DRE tweaked down many maxTemps.

Here's the excerpt of the MK1-2 pod:

[SIZE=1]{
    name = Mark1-2Pod
    type = PART
    parentUrl = Squad/Parts/Command/Mk1-2Pod/mk1-2CommandPod
    url = Squad/Parts/Command/Mk1-2Pod/mk1-2CommandPod/Mark1-2Pod
    PART
    {
        name = Mark1-2Pod
        module = Part
        .
        .
        .
        mass = 4
        crashTolerance = 45[/SIZE]
       [B]maxTemp = 1523.15 [/B][COLOR=#ff0000]â¤[/COLOR]
[SIZE=1]        .
        .
        .
[SIZE=2]       emissiveConstant = 0.2[/SIZE]
        .
         [SIZE=2]M[/SIZE][/SIZE]ODULE
       {
           name = ModuleAeroReentry
           skinHeatConductivity = 0.12
       }
       .
       .
       .
[SIZE=1]
    }
}[/SIZE]

I see you decided to change the scale of reference for maxTemps and recalculate it for all parts. If so, command pods should have a maxTemp which will make them burn without heatshields. Around 1200K I think is good, but still only with max convection in settings.

Edited May 14, 2015 by Enceos

[Martinoss]

Check your log, I'm guessing you have errors spamming the log.

Also, I'm thinking there's an issue with Procedural Fairings. If you experienced the FPS drop on a ship that had those, either revert to launch, or quicksave then quickload and it should stop

Same here, i checked my log, errors are indeed spamming but no idea how to get rid of them but for now I will refrain from installing DE from CKAN then.

Edited May 14, 2015 by Martinoss

[Starwaster]

Sorry Starwaster but I get really really weird behaviour on reentry.

My craft has an DREC-Heatshield, a coupler node for the US-Bays, a Probe core, two batteries and a Parachute.http://i.imgur.com/RuTE7vV.png

On the first try I had a FL-A10 adapter between the probe and the science bays.

While reentering everything worked fine, I had some ablating going on but nothing really that's worth talking about.

Speed was about 1400m/s, altitude must have been around 20k. Suddenly, depends on wether I used the one with adapter or not, either the adapter or the probe core go suddenly poof, without any warning. The stock temperature gauge didn't show anything and everything should be protected by the heatshield. The Ingame log says that those parts overheated. I can try as many times as I want...

Here's the log which is riddled with NREs: https://www.dropbox.com/s/av40verxa8q8uo1/output_log.zip?dl=0

Thanks a lot for this still awesome mod!

The A10 has a maxTemp of 1000.... I'll see about bumping that up in the next version.

About that bay, is US properly updated for KSP 1.0? It should be using ModuleCargoBay. Otherwise there's no guarantee that it will shield anything.

Also, the stock heat gauge can't tell that your parts are overheating if it's the outer skin heating up. It's not DRE-aware.

I'll look at the log file to see what errors you're getting. Make sure you're updated to DRE 7.0.2 which I posted last night.

@Starwaster still dropping shieldless pods from Minmus orbit. DRE 7.0.2, 1.0.2 Physics.cfg, max convection. No nuFAR this time.

http://youtu.be/0PvOFvasWls

At 28300 Altitude temperature starts dropping, even though I'm still travelling at orbital velocity. Even though it convection heating starts earlier in this version, it ends earlier as well.

On the positive note, looked into the ModuleManager cache and found that DRE tweaked down many maxTemps.

Here's the excerpt of the MK1-2 pod:

[SIZE=1]{
    name = Mark1-2Pod
    type = PART
    parentUrl = Squad/Parts/Command/Mk1-2Pod/mk1-2CommandPod
    url = Squad/Parts/Command/Mk1-2Pod/mk1-2CommandPod/Mark1-2Pod
    PART
    {
        name = Mark1-2Pod
        module = Part
        .
        .
        .
        mass = 4
        crashTolerance = 45[/SIZE]
       [B]maxTemp = 1523.15 [/B][COLOR=#ff0000]â¤[/COLOR]
[SIZE=1]        .
        .
        .
[SIZE=2]       emissiveConstant = 0.2[/SIZE]
        .
         [SIZE=2]M[/SIZE][/SIZE]ODULE
       {
           name = ModuleAeroReentry
           skinHeatConductivity = 0.12
       }
       .
       .
       .
[SIZE=1]
    }
}[/SIZE]

I see you decided to change the scale of reference for maxTemps and recalculate it for all parts. If so, command pods should have a maxTemp which will make them burn without heatshields. Around 1200K I think is good, but still only with max convection in settings.

Are you sure you did a proper install of 7.0.2? Delete then reinstall? Pretty sure you should be exploding that pod with no shields. Did you post any logs earlier? If not, do so now. output_log.txt (player.log if Linux/Mac)

Same here, i checked my log, errors are indeed spamming but no idea how to get rid of them

Is it the same thing as what I posted though? Procedural Fairings? Did you try reverting to launch or saving then restoring?

[Enceos]

Are you sure you did a proper install of 7.0.2? Delete then reinstall? Pretty sure you should be exploding that pod with no shields. Did you post any logs earlier? If not, do so now. output_log.txt (player.log if Linux/Mac)

Reinstalled and tested. Same $hit At orbital velocity and 27000alt temperature starts dropping. Max peak skin temp for the pod was 960K with default convection settings (40), 1380K with 100 convection.

output_log.txt

Edited May 14, 2015 by Enceos