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

[tg626]

DeadlyReentry.version is in the wrong place. I find it in the root of the Source download, but it's NOT in the release.

[Starwaster]

What setting are you using? (Easy, Normal, Hard, Alternate or RSS? hint: it should be RSS)

That said, if your shield is exploding at 750 then that's a problem. The heat shield on an Apollo was known to have gone as high as 1260 on one flight. (that wasn't typical though; usually it was lower even on lunar returns.) Anyway, shield parts in DRE are usually at least as high as 1250.

Might help to put up your Module Manager cache file. It's in the GameData and it's named ModuleManager.ConfigCache

That would probably tell me more than logs would in a situation like this.

- - - Updated - - -

DeadlyReentry.version is in the wrong place. I find it in the root of the Source download, but it's NOT in the release.

If you're using the beta then no, there shouldn't be a version file. If I get around to moving the beta to official download then it'll get a version file. But at the rate things are going, I suspect that KSP 1.0 will be upon us before then which will require quite a bit of gutting of DRE to make use of the new heat system

[tg626]

No, the v6.4 release zip has no DeadlyReentry.version file in it. If I download the 6.4 *source* I see it in the ROOT of *that* zip, but not in the DeadlyReentry folder.

Of course if I pull it from the source zip and drop it into my gamedata/deadlyreentry folder AVC sees it and checks it as being up to date.

Right Pane - 6.4 Source Zip

Left Pane - 6.4 Release Zip

[Starwaster]

Ah ok, thanks

[chrisl]

What setting are you using? (Easy, Normal, Hard, Alternate or RSS? hint: it should be RSS)

That said, if your shield is exploding at 750 then that's a problem. The heat shield on an Apollo was known to have gone as high as 1260 on one flight. (that wasn't typical though; usually it was lower even on lunar returns.) Anyway, shield parts in DRE are usually at least as high as 1250.

Might help to put up your Module Manager cache file. It's in the GameData and it's named ModuleManager.ConfigCache

That would probably tell me more than logs would in a situation like this.

Before (v6.5.2 Beta) I tried Normal and Easy, both with and without "Alternate Heating Model". Then I updated to v6.5.3 Beta and put it on RSS (I think AHM turned on automatically along with "Damp Heat Shield Temp to maxTemp). Basically the same results in all cases. Using Easy w/o alternate heating it took a little longer for the shield to overheat and explode, but it still happened. I also havn't played around with the settings since installing v6.5.3 Beta.

I can get you a copy of my ModuleManager.ConfigCache but the file is over 210k lines (5+mb) so I figure I probably shouldn't post it on this thread. Let me know how I can get it to you and I'll send it. In the mean time, here is the section that seems to deal specifically with the FASAApollo_CM_HeatShield:

UrlConfig
{
 name = FASAApollo_CM_HeatShield
 type = PART
 parentUrl = FASA/Apollo/ApolloCSM/FASA_Apollo_CM_HeatShield
 url = FASA/Apollo/ApolloCSM/FASA_Apollo_CM_HeatShield/FASAApollo_CM_HeatShield
 PART
 {
  name = FASAApollo_CM_HeatShield
  module = Part
  author = DennyTX
  rescaleFactor = 1
  scale = 1
  rescaleFactor = 1.0
  node_stack_top = 0.0,0.36,0.0, 0.0, 1.0, 0.0, 4
  node_stack_bottom = 0.0, -0.1, 0.0, 0.0, 1.0, 0.0, 4
  fx_gasBurst_white = 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, decouple
  sound_decoupler_fire = decouple
  category = Utility
  subcategory = 0
  title = Apollo Command Module Heat Shield
  manufacturer = FASA
  description = This part is the ablative heat shield for the Apollo Command Module.
  attachRules = 1,0,1,1,1
  childStageOffset = 1
  mass = 0.152
  dragModelType = default
  maximum_drag = 0.1
  minimum_drag = 0.1
  angularDrag = 2
  maxTemp = 800
  crashTolerance = 12
  breakingForce = 250
  breakingTorque = 250
  RSSROConfig = True
  TechRequired = advFlightControl
  cost = 1,000
  entryCost = 35000
  RP0conf = true
  PhysicsSignificance = 0
  MODEL
  {
   model = FASA/Apollo/ApolloCSM/FASAApollo_Heatshield
   scale = 1.0, 1.0, 1.0
   rotation = 0, 0, 0
   position = 0.0, -0.1, 0.0
  }
  MODULE
  {
   name = BBModule
  }
  MODULE
  {
   name = ModuleHeatShield
   direction = 0, -1, 0
   reflective = 0.08
   ablative = AblativeShielding
   area = 12.7274
   emissiveConst = 0.0003
   lossExp = 10000
   lossConst = 0.045
   pyrolysisLoss = 130000
   loss
   {
    key = 650 0 0 0
    key = 2000 480 0 0
    key = 6000 600 0 0
   }
   dissipation
   {
    key = 300 0 0 0
    key = 800 170 0 0
   }
  }
  RESOURCE
  {
   name = AblativeShielding
   amount = 848
   maxAmount = 848
  }
  MODULE
  {
   name = ModuleShowInfo
  }
 }
}

EDIT: Was doing some more digging and I found where at least part of the issue may be coming from. I sifted through my output_log.txt for any mention of the "FASAApollo_CM_HeatShield" part. By default, FASA is setting maxTemp=3600 for the part. And according to output_log.txt, the part is being modified only by RO, RP0 and Better Buoyancy. After looking at the modifications each of those mods is making, I found that RO is adding the ModuleHeatSheild to the part, and then later changing the maxTemp=800 which happens here:

[ModuleManager] Applying node RealismOverhaul/RealismOverhaul_Global_Config/@PART

[*]:HAS[!MODULE[ModuleEngines*],!MODULE[ModuleHeatShield]]:BEFORE[RealismOverhaul] to FASA/Apollo/ApolloCSM/FASA_Apollo_CM_HeatShield/FASAApollo_CM_HeatShield

Reading that line form output_log.txt, this modification should only be made if the part in question is not an Engine and is not a HeatShield. It's obviously supposed to be a heatshield, though, so that means the "ModuleHeatShield" isn't being applied to the part until after RO changes it's maxTemp. Technically, based on the order the lines appear in output_log.txt, it seems like RO should be adding the ModuleHeatShield first (line 46014 of output_log.txt) and then checking to see if ModuleHeatShield exists later (line 78077 of output_log.txt) but that doesn't seem to be happening. Either way, though, there is no DRE modification being made to this heatshield at all. Shouldn't there be a config change being made by DRE for this part?

EDIT2: So I added a config into DRE for the FASAApollo_CM_HeatShield that matches the config for the "3.75_Heatshield" part that comes with DRE. This time when i tried re-entry, the heat shield peaks at about 950C. My crew ended up dying from excessive G-forces so I'm guessing I'm coming in too steep, so I'm reloading my save and adjusting my periapsis for a shallower entry, but at least the shield isn't exploding. I might suggest adding a DRE config for the FASA Mercury, FASA Gemini (black and white versions) & FASA Big Gemini (black and white versions) capsules, plus the FASA Apollo CM Heatshield.

Edited April 10, 2015 by chrisl

[Starwaster]

Reading that line form output_log.txt, this modification should only be made if the part in question is not an Engine and is not a HeatShield. It's obviously supposed to be a heatshield, though, so that means the "ModuleHeatShield" isn't being applied to the part until after RO changes it's maxTemp. Technically, based on the order the lines appear in output_log.txt, it seems like RO should be adding the ModuleHeatShield first (line 46014 of output_log.txt) and then checking to see if ModuleHeatShield exists later (line 78077 of output_log.txt) but that doesn't seem to be happening. Either way, though, there is no DRE modification being made to this heatshield at all. Shouldn't there be a config change being made by DRE for this part?

No I don't think DRE should be making changes to a config for someone else's mod. A config that they crafted for DRE. It probably worked at some point but they need to rework that config to work with the new DRE. However it wouldn't make sense for them to do so for what is essentially a beta release.

Try patching it with this:

@PART[[COLOR=#333333]FASAApollo_CM_HeatShield]
{
    @maxTemp = 1250
}

The heat shield section itself needs going over; it has some extraneous entries that might have been for an older version of DRE that was deprecated before ever being released (pyrolysisLoss?)

Those dont cause problems but it calls attention to the entire section. Not sure that those configurations are really good. (doesnt matter as much for the alternate heating model and you should leave that enabled especially for settings that were designed to use it specifically)

[Elmetian]

Hi guys, I've got a bit of a problem.

I'm using DR v6.5.3 with 'normal' settings as well as FAR v0.14.7. I'm finding that my struts and fuel lines (as well as B9 air brakes) are exploding on my SSTO before I get anywhere near orbital velocity. They start to overheat at about 30km up and moving at 1200m/s. I've watched the temperatures rise on individual struts and it seems to happen at about 800°C. They're also not being shielded by being placed inside the SXT cargo bay I'm using for some reason.

Is this meant to happen? In 0.25, I could fly the same ascent profile with the same craft and not see any dangerous heating, but with the latest version of DR the temperatures just seem to rise until parts start burning up. This wouldn't be so much of a problem, but when my fuel lines pop everything hits the fan. Suddenly the B9 SABRE begins drawing fuel asymmetrically or cutting out altogether. I'd use the Crossfeed Enabler mod to avoid this, but it mucks with the fuel flow on my other builds.

[chrisl]

No I don't think DRE should be making changes to a config for someone else's mod. A config that they crafted for DRE. It probably worked at some point but they need to rework that config to work with the new DRE. However it wouldn't make sense for them to do so for what is essentially a beta release.

I didn't mean you should add something to DRE for RO. I meant you might want to add something to DRE specifically for FASA parts. Just like you have a "DeadlyReentry-KWRocketryFairings.cfg" for KW Rocketry stuff, and "DeadlyReentry-RealChutes.cfg" for Real Chutes stuff.

[NathanKell]

I've noticed that DRE appears to not default to RSS config when RSS is installed. Can you do a check and apply the RSS config when Kerbin's size is >5x perhaps? Or just have a value in DRE.cfg saying defaultConfig = default and let RSS do @DRE{@defaultConfig = RSS } ?

[Starwaster]

@Narcosis, use the alternate setting instead. (The button on top that says simply Alternate Model, not the radio button that says Alternate Heating Model). It is more forgiving on the ascent. Regarding cargo bays, There's probably nothing I can do about that that we're not already doing. I can't imagine why those would fail where other cargo bay parts are ok and if FAR is installed and FAR thinks that those parts should not be shielded then there's an issue with the cargo bay or between the cargo bay / FAR that needs to be addressed in those mods. (DRE does check with FAR to see if it thinks parts should be shielded, if FAR is installed, and it becomes the main method of determining shielding)

@chrisl, Some clarification: Firstly, when DRE starts cutting part temperatures that it considers to be too high, it does that after ALL configs were processed. (I saw that in your earlier post but didn't address that). Regarding configs, obviously DRE does do a lot of configs for a lot of mods. But those are for mods that lack any DRE consideration at all. i.e. parts that weren't designed for DRE but probably need modification based on their intended use. But if a mod specifically was written with DRE in mind then that set of configs is how the modder thinks it should work with DRE. While I disagree with setting the temperature of a heat shield part so low, I'm not going to countermand what they wrote for DRE. As opposed to something like KWR's parts which weren't designed with DRE in mind at all. See now why I'd be reluctant to do that?

@Nathan, that sounds like a good idea. I'll put something like that in, but I don't know if I'm going to get another update out before 1.0 is upon us. (I hope so; I hope that final 1.0 release isn't that near in the future... and there are a couple of things I would have liked to stick in)

[chrisl]

@chrisl, Some clarification: Firstly, when DRE starts cutting part temperatures that it considers to be too high, it does that after ALL configs were processed. (I saw that in your earlier post but didn't address that). Regarding configs, obviously DRE does do a lot of configs for a lot of mods. But those are for mods that lack any DRE consideration at all. i.e. parts that weren't designed for DRE but probably need modification based on their intended use. But if a mod specifically was written with DRE in mind then that set of configs is how the modder thinks it should work with DRE. While I disagree with setting the temperature of a heat shield part so low, I'm not going to countermand what they wrote for DRE. As opposed to something like KWR's parts which weren't designed with DRE in mind at all. See now why I'd be reluctant to do that?

Again, I'm not suggesting you modify anything in DRE for RO. If you look at the basic FASA mod, there is a "FASA_Apollo_CM_HeatShield.cfg" which has a default maxTemp = 3600 and no "ModuleHeatShield" module. In other words, if I were to play a game with just FASA and DRE installed (with no other mods at all), the "FASAApollo_CM_HeatShield" part would not be treated by DRE like a heatshield because there is nothing in the config to tell the system otherwise. Presumably the high maxTemp of the defulat part would still help to protect the CM during reentry, but it wouldn't act like any of the other heat shields that DRE introduces into the game.

I'm simply suggesting you add a config for default FASA parts just like there are configs for default HOME, KW Rocketry, MkIV Essential, Real Chites and a few other mods.

[futrtrubl]

Again, I'm not suggesting you modify anything in DRE for RO. If you look at the basic FASA mod, there is a "FASA_Apollo_CM_HeatShield.cfg" which has a default maxTemp = 3600 and no "ModuleHeatShield" module. In other words, if I were to play a game with just FASA and DRE installed (with no other mods at all), the "FASAApollo_CM_HeatShield" part would not be treated by DRE like a heatshield because there is nothing in the config to tell the system otherwise. Presumably the high maxTemp of the defulat part would still help to protect the CM during reentry, but it wouldn't act like any of the other heat shields that DRE introduces into the game.

I'm simply suggesting you add a config for default FASA parts just like there are configs for default HOME, KW Rocketry, MkIV Essential, Real Chites and a few other mods.

And he is saying that he will only do configs for mods that have no awareness of re-entry heat. FASA's heatshield is a heatshield whether it has a ModuleHeatShield or not so it's up to the FASA people how it works.

[Starwaster]

Except that it DOES have a heat shield module and its maxTemp isn't being reduced by DRE therefore it's being configured to have lower tolerance. This needs to be kicked over either to FASA or RO.

[darqen27]

Question, When on RSS mode in DRE, my reentry barely uses any shielding, but if i set it on normal mode, i get exploding launches at 1.25 twr. Is this normal behavior?

[NathanKell]

darqen27: RO makes similar changes to "RSS mode" in DRE. RO needs a pass to bring it up to date.

[RainDreamer]

Just updated the beta version, and I am getting instantly exploded on reentry with temperature sudden hike to 1.7k when I am at around 60km when using hard mode. I remember there was a fix or an instruction to fix this with sometimes ago, can anyone remind me what it is? Normal feels a bit too easy.

[Starwaster]

Just updated the beta version, and I am getting instantly exploded on reentry with temperature sudden hike to 1.7k when I am at around 60km when using hard mode. I remember there was a fix or an instruction to fix this with sometimes ago, can anyone remind me what it is? Normal feels a bit too easy.

Stock Kerbin or RSS? (specific configuration plz)

If RSS then use RSS mode instead.

[RainDreamer]

Stock Kerbin or RSS? (specific configuration plz)

If RSS then use RSS mode instead.

Stock kerbin.

[Draconomial]

futrtrubl pointed out an error, guys.

The base mass of the 2.5m heat shield is 0.06t which agrees roughly with the mass of the Huygens 2.7m heat shield at 79kg (though that included ablative mass).

However, the smaller 1.25m heat shield despite being smaller weighs 3x as much at 0.2t. Actually all the other heat shields have the same base structural mass of 0.2t

1.25 Heatshield = .2

2.5 Heatshield = .02

3.75 Heatshield = .2

6.25 Heatshield = .2

The 2.5 heatshield also has less drag than the others. So what should they be, that would be more accurate?

[darqen27]

Updated and now when reentering using the apollo modules the heatshield explodes on re-entry and everyone dies

[Starwaster]

Updated and now when reentering using the apollo modules the heatshield explodes on re-entry and everyone dies

You mean the FASA pack? And/or RO? See my previous response on that (1-2 pages back)

It's how that part is configured by one of those mods

Last two posts: Will address those concerns in a later post today

[Velken]

I'm having a bug when I create massive vessels (like, B9 cube parts)

After building my craft, I click launch and it gets instanttly destroyed, when the games loads the launch pad, all I can see is explosions. (log says: Overheat for all parts). When I remove Deadly Reentry this no longer happens.

Could you take a look why is that happening?

[darqen27]

I added the module heat shield to the Apollo heat shield file and now everything is peachy

Thanks!

Edited April 21, 2015 by darqen27

[Starwaster]

I'm having a bug when I create massive vessels (like, B9 cube parts)

After building my craft, I click launch and it gets instanttly destroyed, when the games loads the launch pad, all I can see is explosions. (log says: Overheat for all parts). When I remove Deadly Reentry this no longer happens.

Could you take a look why is that happening?

Take a look at what exactly?

You're not giving me enough information to go on. It doesn't happen to me and I can't remember anyone else every reporting that either. It sounds like your launch pad collapsed under the weight of your vessel but I don't think it reports overheating for that. Other than that, the only thing I can think of is bad interaction with another mod.

At the very least you should make that log you mentioned available. (output_log.txt if Windows. player.log if Linux / Mac. NEVER ksp.log)

Zip it up and upload it to dropbox, then share the link.

[Velken]

Take a look at what exactly?

You're not giving me enough information to go on. It doesn't happen to me and I can't remember anyone else every reporting that either. It sounds like your launch pad collapsed under the weight of your vessel but I don't think it reports overheating for that. Other than that, the only thing I can think of is bad interaction with another mod.

At the very least you should make that log you mentioned available. (output_log.txt if Windows. player.log if Linux / Mac. NEVER ksp.log)

Zip it up and upload it to dropbox, then share the link.

1-The launch pad stills intact after the explosions

2-I have recorded (with my phone) the bug (sorry for bad video quality, but stills watchable):

3-Dropbox link: https://www.dropbox.com/s/3sndqja6x0f8dhz/output_log.zip?dl=0

4-As far as I know, it coud be: a) KSP engine limitations; B9 mod fault; c)any other mod that I have fault; d)Deadly Reentry fault (since removing it prevents the instant explosion)

I hope it helps.