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

[linuxgurugamer]

6 hours ago, NathanKell said:

@linuxgurugamera CKAN install showed no issues, but I repackaged the archive on github so it ships the latest (4.2.1) ModuleManager, and therefore should be out-of-the-box compatible with KSP 1.12 even on manual installs. You are grabbing from the repo pointed at in CKAN  - https://github.com/KSP-RO/DeadlyReentry/releases/latest - yes?

I use CKAN for all installs.

It's not CKAN complaining, its (I think) ModuleManager.

I'll post a pic when I get home

[Starwaster]

@NathanKell @linuxgurugamer

If you're going to maintain and run a separate repo (even if it's the original from which this one was forked) please discuss any issues with that repo in a separate thread. 

 

[linuxgurugamer]

Oh sorry, I thought he was helping you.

@Starwaster

Edited August 5, 2021 by linuxgurugamer

[Starwaster]

Deadly Reentry update version 7.8.2

The Barbie Edition

• Updated versioning
• Updated version checking code: All version minor from 8 or greater will be accepted. This effectively means the version checker will ignore all further updates. 
• This edition is in memory of Barbie Doll, an FeLV+ cat who passed away recently.

https://github.com/Starwaster/DeadlyReentry/releases/tag/v7.8.2

 

Edited August 6, 2021 by Starwaster

[Starwaster]

I want to clarify a few things. 

As far as I'm concerned, this is still the official release of Deadly Reentry. It prioritizes the stock game first with support for other mods (including those with more realistically sized planetary systems) second. Although I myself prefer larger sized systems (which affects the mod a lot) priority will always be for the stock game.

Regarding the update frequency of this mod: Although I have been at reduced activity levels in KSP, I am still here. I respond to issues created on the repository and address player concerns there and on the forum. Rightly or wrongly the mod is just less likely to be updated for a given KSP update when I see that the mods functioning has not been impaired. Compatibility warnings have always been just that: warnings. Those warnings do not come from KSP itself which has no idea if installed mods are compatible or not. Those warnings come from version checking code in the mod itself. (there is a common version checker which most mods out there share)

Bugs on the other hand will be addressed and an update issued for those when those bugs are submitted to me and when I can verify and track those bugs down.

I am still here.

Edited August 6, 2021 by Starwaster

[NathanKell]

Ah it's great that you're stepping back into more active development @Starwaster! I based the (re-)continuation of DRE's original repo on your having not updated since 1.8, and bugs remaining extant; I'm (as are the whole KSP-RO team) more than happy to combine efforts going forward, one active DRE going forward is far better than two.

[Starwaster]

On 8/5/2021 at 11:22 PM, NathanKell said:

Ah it's great that you're stepping back into more active development @Starwaster! I based the (re-)continuation of DRE's original repo on your having not updated since 1.8, and bugs remaining extant; I'm (as are the whole KSP-RO team) more than happy to combine efforts going forward, one active DRE going forward is far better than two.

I'm not in touch with the RO community anymore so if there are any bugs that you guys are aware of over there please create issues for them on the repo.

Thanks!

Edited August 7, 2021 by Starwaster

[NathanKell]

10 hours ago, Starwaster said:

I'm not in touch with the RO community anymore so if there are any bugs that you guys are aware of over there please create issues for them on the repo.

Thanks!

While, again, I would hope it's possible to combine forces rather than having both the upstream master and the fork around, when I get a chance I will do so. To be clear these are not RO specific bugs, but due to things such as casting GameObjects to object (which is dangerous since DRE is in the habit of operating during reentries when parts, and thus GameObjects, are destroyed), double-counting thermal fluxes and applying negative damage, and the like.

[Starwaster]

33 minutes ago, NathanKell said:

While, again, I would hope it's possible to combine forces rather than having both the upstream master and the fork around, when I get a chance I will do so. To be clear these are not RO specific bugs, but due to things such as casting GameObjects to object (which is dangerous since DRE is in the habit of operating during reentries when parts, and thus GameObjects, are destroyed), double-counting thermal fluxes and applying negative damage, and the like.

That's the first time someone has told me casting to an object was dangerous. We've all been doing it for years in the KSP modding community (RO included) when doing null ref checks and I even asked years ago if this was a safe thing to do before I adopted the practice myself.  If it's null then you just get null object out of it, which you're checking for and then you don't execute your code, or otherwise deal with the null object.

[NathanKell]

1 minute ago, Starwaster said:

That's the first time someone has told me casting to an object was dangerous. We've all been doing it for years in the KSP modding community (RO included) when doing null ref checks and I even asked years ago if this was a safe thing to do before I adopted the practice myself.  If it's null then you just get null object out of it, which you're checking for and then you don't execute your code, or otherwise deal with the null object.

The issue is the C# object can be non-null but the underlying Unity object can be destroyed (i.e. freed in C++). Example:

// For some gameobject foo
MonoBehaviour comp = foo.AddComponent("ComponentType");
GameObject.Destroy(foo);
bool isNull = comp == null;
bool isNullCast = (object)comp == null;

Now, isNull will be true, but isNullCast will be false. That's because you have a C# reference to the component, so GC doesn't clean it up, but Unity has freed the underlying (i.e. unmanaged C++) memory. This is the very reason for the speed increase from casting to object, namely that you shortcircuit Unity doing its extra work to see if the (Unity) object was destroyed.

In some cases this can be safe enough, i.e. when you know that a component will either exist (and not be destroyed), or not exist at all; but if there is a chance of it having been destroyed, doing the casting is unsafe because you will not get the correct answer.

[Starwaster]

Deadly Reentry update version 7.9.0

Some bug fixes submitted by @NathanKell and some other minor adjustments.

• Don't type cast to object when checking for null references.
• Damage internal flux fixes (see PR #56 for details)
• Moved several config patches from :FINAL to :LAST[DeadlyReentry]
• Register part destruction causes with FlightLogger
• Fixed negative damage issue when internal temp over maxOperationalTemp
• Changed behavior when max operational temps are incorrectly configured higher than max temps. (max temp is now increased to match configured max operational temp)

[CreepyShadow]

Haven't found an answer to this yet, which percentage of reentry heating would be roughly comparable to the stock heating?

[Starwaster]

29 minutes ago, CreepyShadow said:

Haven't found an answer to this yet, which percentage of reentry heating would be roughly comparable to the stock heating?

Interpreting your question literally, 100% as Deadly Reentry no longer touches KSP physics. Those now  are deemed adequate to my purposes (and have been for awhile). So quite literally, heating happens at the same rate as before.

The main changes from stock are to the thermal tolerances of every part. The max temperature of everything is capped. Ablative heat shield ablation rate is 10x greater for everything except the Mk1 pod which is 16x greater.

The other changes are in how parts react to overheating. 

Edited November 10, 2021 by Starwaster

[CreepyShadow]

Hmm, yeah my question might have been formulated wrong. Which percentage of reentry heating would make the difficulty of DRE comparable to 100% stock reentry heating. Hope that makes it clearer.

[kcs123]

11 hours ago, CreepyShadow said:

Hmm, yeah my question might have been formulated wrong. Which percentage of reentry heating would make the difficulty of DRE comparable to 100% stock reentry heating. Hope that makes it clearer.

I will try to explain as other user of DRE, in hope that it clear things up slightly. It's not exactly easy to answer that question with exact percent of comparison. DRE behave different in comparison to stock. Once you get used to differences and pay attention to them trough gameplay, overall difficulty does not become much harder than in stock. You need to pay attention on re-entry profile, how you craft is turned trough re-enty and not to forget heat shields on craft.

Once you pay attention to those details, there is no significant difference in terms of difficulty (at least to me). It is rather different behaviour and different gameplay experience, if that make any sense.

[Starwaster]

23 hours ago, CreepyShadow said:

Hmm, yeah my question might have been formulated wrong. Which percentage of reentry heating would make the difficulty of DRE comparable to 100% stock reentry heating. Hope that makes it clearer.

No, it doesn't really make it much clearer. Different players have different ideas about difficulty. Even with DRE (for stock Kerbin) I have to go up to at least 150% before I even start to feel challenged. To me, DRE is more about introducing consequences for poor design choices. No matter what the reentry scale is at, you should always be capable of designing something that can survive your mission's reentry. And a good design will survive 100% of the time. A bad design will probably almost always fail.

As far as the reentry heating slider goes, I think the best suggestion here is for you to run through several reentries and adjust the the slider each time until you find a setting that satisfies your needs. 

[Gordon Dry]

In VAB/SPH I can see how much Ablator/AblativeShielding is used at 2000K - but I would like to know how to calculate this value outside of the game, like in a spreadsheet, by the given numbers

ablationTempThresh
lossConst
lossExp
pyrolysisLossFactor
reentryConductivity

and whatever is needed for that calculation.

When fiddling with those values I really don't want to launch KSP after each change and wait until I can see the change in the VAB...

Edit:
And what do I find? https://github.com/Starwaster/DeadlyReentry/pull/57

Edit:
For real, where even does this info - at the top right - come from? Stock? Mod?

Edit:
Got it, GameData\Squad\Localization\dictionary.cfg

        #autoLOC_6001041 = \nLoss at <<1>>K: <<2>> <<3>>
        #autoLOC_6001042 = / sec.\n(Flux <<1>>W)

So only @SQUAD can help me here

Edited November 23, 2021 by Gordon Dry

[Starwaster]

On 11/23/2021 at 8:31 AM, Gordon Dry said:

In VAB/SPH I can see how much Ablator/AblativeShielding is used at 2000K - but I would like to know how to calculate this value outside of the game, like in a spreadsheet, by the given numbers

ablationTempThresh
lossConst
lossExp
pyrolysisLossFactor
reentryConductivity

and whatever is needed for that calculation.

When fiddling with those values I really don't want to launch KSP after each change and wait until I can see the change in the VAB...

Edit:
And what do I find? https://github.com/Starwaster/DeadlyReentry/pull/57

Edit:
For real, where even does this info - at the top right - come from? Stock? Mod?

Edit:
Got it, GameData\Squad\Localization\dictionary.cfg

        #autoLOC_6001041 = \nLoss at <<1>>K: <<2>> <<3>>
        #autoLOC_6001042 = / sec.\n(Flux <<1>>W)

So only @SQUAD can help me here

As you've figured out, this is from stock (Squad) code. Specifically it comes from ModuleAblator from which ModuleHeatshield derives.

The formula for loss is:

lossConst * Math.Exp(lossExp / infoTemp) * ablator maxAmount * ablator density * 1000

where infoTemp is 2000 by default. (you can add this in as a custom temperature to check against in ModuleHeatshield / ModuleAblator)

My advice to you is to save yourself some pain and touch none of the fields you referenced above except for lossConst

Or if you absolutely must change the others then plug that formula into your spreadsheet.

[Gordon Dry]

@Starwaster thank you. What is the role of pyrolysisLossFactor as it's not mentioned in the formula?

[Starwaster]

22 hours ago, Gordon Dry said:

@Starwaster thank you. What is the role of pyrolysisLossFactor as it's not mentioned in the formula?

That's used to determine how much heat is removed along with the heatshield material that got ablated away. It's ablated amount * density * specificHeatCapacity * pyrolysisLossFactor

[ss8913]

I've noticed with this mod that when KSPIE radiators get hot, they appear to catch on fire and trail fire behind the radiators - often this is harmless as these things hold a ton of heat safely, but it seems something is miscalibrated?  Also the fire effects persist *in vacuum* which doesn't seem possible?  Is there a configuration setting for this?  or is KSPIE incompatible with this mod?

[Starwaster]

23 hours ago, ss8913 said:

I've noticed with this mod that when KSPIE radiators get hot, they appear to catch on fire and trail fire behind the radiators - often this is harmless as these things hold a ton of heat safely, but it seems something is miscalibrated?  Also the fire effects persist *in vacuum* which doesn't seem possible?  Is there a configuration setting for this?  or is KSPIE incompatible with this mod?

Last item first: Should fire effects exist in a vacuum? Maybe, maybe not. But they're there to provide visual feedback that something is wrong and and that the part is taking damage.

Which brings us to the first item: Stock KSP has no concept of part damage. The part has maxTemp and skinMaxTemp properties. If the part's temperature or skin temperature exceeds those values then the part is instantly destroyed.

That's one of the things that DRE changes by introducing the concept of gradual damage.  Part failure is soft(er) and gradual. If you see flames, your part is being damaged which is tracked by DRE.  The way it works is that DRE adds 'operational' temps. which are lower than the stock maxTemp. My rule of thumb (YMMV) is that maxTemp should be the part's vapor temperature and operational temps should be either the part's melting temperature or the temperature at which its material would weaken or soften. The amount of damage dealt, IIRC, depends on the ratio between operational temp and maxTemp.  If the operational temp wasn't explicitly configured then it is 85% of the maxTemp. (97.5% for engines) Setting it to the same value as the part's maxTemp would effectively disable the damage system.

So, TL;DR, DRE has a soft damage system that KSPIE is bumping into because its parts aren't configured to reflect whatever material the radiators are supposed to be made out of. I don't use those radiators myself nor do I use whatever engine or reactors are driving those temperatures up so high so I'm not sure what an appropriate configuration would look like. I'm not even sure what kinds of temperatures they're actually experiencing.

 

[ss8913]

On 5/11/2022 at 5:33 PM, Starwaster said:

Last item first: Should fire effects exist in a vacuum? Maybe, maybe not. But they're there to provide visual feedback that something is wrong and and that the part is taking damage.

Which brings us to the first item: Stock KSP has no concept of part damage. The part has maxTemp and skinMaxTemp properties. If the part's temperature or skin temperature exceeds those values then the part is instantly destroyed.

That's one of the things that DRE changes by introducing the concept of gradual damage.  Part failure is soft(er) and gradual. If you see flames, your part is being damaged which is tracked by DRE.  The way it works is that DRE adds 'operational' temps. which are lower than the stock maxTemp. My rule of thumb (YMMV) is that maxTemp should be the part's vapor temperature and operational temps should be either the part's melting temperature or the temperature at which its material would weaken or soften. The amount of damage dealt, IIRC, depends on the ratio between operational temp and maxTemp.  If the operational temp wasn't explicitly configured then it is 85% of the maxTemp. (97.5% for engines) Setting it to the same value as the part's maxTemp would effectively disable the damage system.

So, TL;DR, DRE has a soft damage system that KSPIE is bumping into because its parts aren't configured to reflect whatever material the radiators are supposed to be made out of. I don't use those radiators myself nor do I use whatever engine or reactors are driving those temperatures up so high so I'm not sure what an appropriate configuration would look like. I'm not even sure what kinds of temperatures they're actually experiencing.

 

@Starwaster what information could I gather that would allow you, or me, or someone, to add a patch to DRE to support those parts?  KSPIE radiators are either titanium or graphene high temperature radiators designed to cool high energy fusion and antimatter reactions, so they have, in theory, pretty high limits.  They support the concept of both convection heat transfer (usually in atmosphere, and the titanium radiators are better than graphene for this), and radiant heat transfer (usually in vacuum, using graphene).

[Starwaster]

2 hours ago, ss8913 said:

@Starwaster what information could I gather that would allow you, or me, or someone, to add a patch to DRE to support those parts?  KSPIE radiators are either titanium or graphene high temperature radiators designed to cool high energy fusion and antimatter reactions, so they have, in theory, pretty high limits.  They support the concept of both convection heat transfer (usually in atmosphere, and the titanium radiators are better than graphene for this), and radiant heat transfer (usually in vacuum, using graphene).

Load the game up, switch to the ship that you saw the fire effects on the radiators.

Then turn on thermal debugging window (shift+alt+F12 -> Physics -> Thermal)

Then right click on the radiator part, open up the part window and expand the thermal section.  When you see the fire effects, screenshot it and submit it here.  (host on Imgur)

That way I can see what kind of heat is flowing into it and what its actual thermal limits are being set to.

[FireFaced]

Could support for NF Spacecraft pods be added? Some of them (notably the Mk1-L 'Nereld', Mk3 'Tethys', and Mk3B 'Pandora") have segments that are exposed to heat during reentry, and visually appear to be ablators, but there is no ablator module. This causes explosion on reentry, which is less than ideal. I would contribute the patch myself but I can't for the life of me find documentation on what modules to use.