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

[Starwaster]

On 10/26/2017 at 1:35 AM, SSSPutnik said:

Is DRE 7.6.0 running with KSP 1.2.2 64bit supported?

I have DRE menus, but despite some crazed atmospheric plunge I only seem to take aerodynamic damage, not heat.

I only play 64 bit myself and it works fine.

 I don't know what a 'crazed atmospheric plunge' is.... do you mean you're coming in very steep? Aerodynamic damage is what, G forces due to high drag? Too steep and G-force damage will become more of a concern than reentry heating. Not enough time for thermal levels to reach dangerous levels and not enough time for aerodynamic braking so you'll get high G forces in the lower atmosphere.

Edited October 27, 2017 by Starwaster

[Starwaster]

Just thought I'd share this again:

Edited October 28, 2017 by Starwaster

[SSSPutnik]

On 10/27/2017 at 10:08 PM, Starwaster said:

I only play 64 bit myself and it works fine.

 I don't know what a 'crazed atmospheric plunge' is.... do you mean you're coming in very steep? Aerodynamic damage is what, G forces due to high drag? Too steep and G-force damage will become more of a concern than reentry heating. Not enough time for thermal levels to reach dangerous levels and not enough time for aerodynamic braking so you'll get high G forces in the lower atmosphere.

I'm seeing zero ablation and no temp shown when I right click the parts...  Just the temperature part tolerances are shown.

[Starwaster]

On 10/31/2017 at 10:30 PM, SSSPutnik said:

I'm seeing zero ablation and no temp shown when I right click the parts...  Just the temperature part tolerances are shown.

Ok details. I need details about your reentry. I need to know how fast you're coming in when you first hit the atmosphere and I need to know your orbital parameters prior to reentry (ap/pe)

And I need your output_log.txt file and your ModuleManager.ConfigCache file

[PyjackMeat]

Did a test, the new dll doesn't seem to work on 1.3.1.

[dlrk]

On 11/6/2017 at 11:57 AM, PyjackMeat said:

Did a test, the new dll doesn't seem to work on 1.3.1.

Ah, I was so close to upgrading!

[dlrk]

Any news on 1.3.1? Does it work at all? Will a 1.3.1 be released?

[Starwaster]

2 hours ago, dlrk said:

Any news on 1.3.1? Does it work at all? Will a 1.3.1 be released?

I dunno, maybe never.

Or... maybe right now.... 

Change Log: (both DRE 7.6.1 and 7.6.2 for KSP 1.3.0 and 1.3.1 respectively)

Deadly Reentry v7.6.2 https://github.com/Starwaster/DeadlyReentry/tree/v7.6.2

• Recompiled for KSP 1.3.1
• Adjusted heat shield lossConst and pyrolysisLossFactor for improved survivability.

Deadly Reentry v7.6.1 https://github.com/Starwaster/DeadlyReentry/tree/v7.6.1

• Recompiled for KSP 1.3.0
• Rescaled tempRatio for inner kerbal temps. Lower limit = 317K and upper = 322 (scalding) - Clamped to 0-1 for sound volume. Unclamped for fear reaction animation
• Fixed Kerbals not spawning with correct inner temp.
• Fixed Kerbals not healing at *fixedDeltaTime
• Updated files for main DeadlyReentry.cfg,
• Scaled up star systems support.
• (may not be adequate for all custom star systems. This is REALLY something that should be handled by those star system mods)
• Updated RealChute settings
• Moved inflatable configs into their own file
• Fixed 15m HIAD mass (what, like YOU were never off by three orders of magnitude???)
• Updated categories
• Disable overheating destruction. (Parts still burn up due to stock heating)
• skinMaxTemp wasn't being handled during temperature rebalancing.
• NaN detection changed to use Double.isNaN instead of comparing to Double.NaN

[Joker58th]

On 11/16/2017 at 4:34 PM, Starwaster said:

I dunno, maybe never.

Or... maybe right now.... 

LOL...thanks for giving me a good laugh today.  Love it!

[Starwaster]

2 hours ago, Joker58th said:

LOL...thanks for giving me a good laugh today.  Love it!

well I was getting ready to post about release and I go into the thread I see that question so I couldn't resist.

Actually the update for 1.3.0 had been posted like almost a day before but I'd been giving it time to show up on CKAN. If I'd done them both simultaneously, I'm not sure but I think only the latest might have turned up.

[Joker58th]

On 11/17/2017 at 7:41 PM, Starwaster said:

well I was getting ready to post about release and I go into the thread I see that question so I couldn't resist.

Actually the update for 1.3.0 had been posted like almost a day before but I'd been giving it time to show up on CKAN. If I'd done them both simultaneously, I'm not sure but I think only the latest might have turned up.

I'm still new around here but I've been around the forum enough to see the frustration dev's have with people asking for updated versions.  That's what makes your comments so funny.  At least to me... 

[SSSPutnik]

Thank you so much for the update, all working now   Appreciate the work.

[notJebKerman]

I've tried playing with this mod in a 2.5x system, but I've got a problem. Most of the ablator is spent while traveling through the upper atmosphere, when temperatures aren't even high enough to blow up the separated service module.

Steeper reentries require way less shielding. It has even gone to the point that a reentry on a return from the Mun (4+ km/s) requires less shielding than a normal LKO reentry.

Is this caused by the fact that I'm using a rescale mod thaf both increases the velocity on return and the atmosphere height (to 91 km)?

[Starwaster]

4 hours ago, notJebKerman said:

I've tried playing with this mod in a 2.5x system, but I've got a problem. Most of the ablator is spent while traveling through the upper atmosphere, when temperatures aren't even high enough to blow up the separated service module.

Steeper reentries require way less shielding. It has even gone to the point that a reentry on a return from the Mun (4+ km/s) requires less shielding than a normal LKO reentry.

Is this caused by the fact that I'm using a rescale mod thaf both increases the velocity on return and the atmosphere height (to 91 km)?

I think part of the problem you're describing is more an issue of perception than it is a technical issue.

The fact that your ablator is ablating at a low temperature is not a problem. That is how ablators work. The process is called pyrolysis and it begins at a relatively low temperature.  The material used in Apollo's heat shield (AVCOAT 5026/39)  started pyrolyzing at 500 Kelvin which is where both stock and DRE begin as well. Loss was due to erosion of the char layer. (the stock heat shield supports charring but it's only enabled by mods like Realism Overhaul)

The issue with steep reentries vs shallow reentries has been discussed as recently as the page your post appears on; look further up the page for the reentry corridor image I posted. To recap what has been discussed previously, very shallow reentries involve lower heating peaks but longer duration heat loads and low g-forces. Steep reentries have higher heating peaks but lower duration heat loading and high g-forces. So, yes, even though your steep reentry involves higher temperatures you're hitting the dense part of the atmosphere and slowing down a lot sooner and therefore using less of your heat shield.

So, I'm not seeing a problem with the two specific issues you raise (shield ablating away at low temperatures and steep reentries depleting less of your shield than shallow reentries)

That said, different scaled systems require special attention to both the global physics settings and the heat shield pyrolysis numbers. DRE adjusts the shield if Real Solar System or Kerbol 10x are detected but no other star system scales are handled and the physics globals are left alone. So your specific 2x mod needs to take care of those. That's the responsibility of the modder in charge of that mod.

[garwel]

I've been having issues during reentry recently, I think after an update of DRE. My command pods overheat and blow up even before ablator is used up. I can't land anything at all. In my most recent descent, a reentry module with a Salamander pod (from MKS) and a directly attached stock ablative shield was destroyed at around 50 km altitude. It was moving at about 2300 m/s, with Ap of 600 km and Pe of 29 km. Similar things also happened with Mk1 landers, but then I thought it was because they are a bit wider than a 1.25m shield. Previously, I had no problems with such configurations. It looks like thermal conductivity was greatly increased--or something's wrong with heating. Has anyone seen this?

[Starwaster]

1 hour ago, garwel said:

I've been having issues during reentry recently, I think after an update of DRE. My command pods overheat and blow up even before ablator is used up. I can't land anything at all. In my most recent descent, a reentry module with a Salamander pod (from MKS) and a directly attached stock ablative shield was destroyed at around 50 km altitude. It was moving at about 2300 m/s, with Ap of 600 km and Pe of 29 km. Similar things also happened with Mk1 landers, but then I thought it was because they are a bit wider than a 1.25m shield. Previously, I had no problems with such configurations. It looks like thermal conductivity was greatly increased--or something's wrong with heating. Has anyone seen this?

You're not giving me enough information to even take a guess at it.

ModuleManager.ConfigCache and output_log.txt file (or player.log if Linux/Mac)

[garwel]

9 hours ago, Starwaster said:

You're not giving me enough information to even take a guess at it.

ModuleManager.ConfigCache and output_log.txt file (or player.log if Linux/Mac)

Yep, it was more of a grumbling than a bug report. Maybe this is the intended behavior, but a very frustrating one. But here is the output log. I didn't find the MM ConfigCache.

[Starwaster]

10 hours ago, garwel said:

Yep, it was more of a grumbling than a bug report. Maybe this is the intended behavior, but a very frustrating one. But here is the output log. I didn't find the MM ConfigCache.

ModuleManager.ConfigCache file is in your GameData folder

(the value of that file is it tells me at a glance what changes have been made to a particular part's configs or to your physics globals or anything else that relies on config files. The log file will let me track down what is responsible for those changes)

Edited December 11, 2017 by Starwaster

[garwel]

12 hours ago, Starwaster said:

ModuleManager.ConfigCache file is in your GameData folder

(the value of that file is it tells me at a glance what changes have been made to a particular part's configs or to your physics globals or anything else that relies on config files. The log file will let me track down what is responsible for those changes)

It wasn't there. Maybe it's because I used CKAN to remove DRE from my install afterwards and it might delete the ConfigCache.

[Starwaster]

25 minutes ago, garwel said:

It wasn't there. Maybe it's because I used CKAN to remove DRE from my install afterwards and it might delete the ConfigCache.

No that's not why it's not there. You have errors in config files that Module Manager is trying to process and as a result of those errors it does not write out a cache file.

[ModuleManager] ModuleManager: 21801 patches applied, found <color=orange>2 errors</color>
1 error related to GameData/InterstellarFuelSwitch/PatchManager/ActiveMMPatches/CDT7Setups.cfg
1 error related to GameData/WarpPlugin/Patches/RemoteTechFix.cfg

[ModuleManager] Error - more than one pass specifier on a node: InterstellarFuelSwitch/PatchManager/ActiveMMPatches/CDT7Setups/@PART[CDT????|IfsWrapper*]:HAS[@RESOURCE[LiterVolume]]:AFTER[InterstellarFuelSwitch]:FOR[InterstellarFuelSwitch]

[ModuleManager] Error - more than one pass specifier on a node: WarpPlugin/Patches/RemoteTechFix/@PART[computerCore]:FOR[WarpPlugin]:FINAL

 

Edited December 12, 2017 by Starwaster

[garwel]

6 hours ago, Starwaster said:

No that's not why it's not there. You have errors in config files that Module Manager is trying to process and as a result of those errors it does not write out a cache file.

[ModuleManager] ModuleManager: 21801 patches applied, found <color=orange>2 errors</color>
1 error related to GameData/InterstellarFuelSwitch/PatchManager/ActiveMMPatches/CDT7Setups.cfg
1 error related to GameData/WarpPlugin/Patches/RemoteTechFix.cfg

[ModuleManager] Error - more than one pass specifier on a node: InterstellarFuelSwitch/PatchManager/ActiveMMPatches/CDT7Setups/@PART[CDT????|IfsWrapper*]:HAS[@RESOURCE[LiterVolume]]:AFTER[InterstellarFuelSwitch]:FOR[InterstellarFuelSwitch]

[ModuleManager] Error - more than one pass specifier on a node: WarpPlugin/Patches/RemoteTechFix/@PART[computerCore]:FOR[WarpPlugin]:FINAL

 

Huh, thanks. Guess it's something @FreeThinker should know about.

[FreeThinker]

1 hour ago, garwel said:

Huh, thanks. Guess it's something @FreeThinker should know about.

I thought I already fixed this in the latest release. Exactly what version of IFS is used here?

[garwel]

3 minutes ago, FreeThinker said:

I thought I already fixed this in the latest release. Exactly what version of IFS is used here?

It was 2.10.1, I believe.

[FreeThinker]

Just now, garwel said:

It was 2.10.1, I believe.

Well this specific bug was fixed in 2.10.2

[kcs123]

Quote

:AFTER[InterstellarFuelSwitch]:FOR[InterstellarFuelSwitch]

This part cause issue with latest verion of MM. You need to delete " :FOR[InterstellarFuelSwitch]" piece from that line of code. @blowfish explained that issue in SETI thread.

It looks to me that it is very same issue.