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

[Starwaster]

Looking at this a little more to put things into perspective, let's break down your reentry. During reentry you reached 10 g at MET 30:00 and maxed out the meter at 30:12

• MET 30:00 - 10 g
• MET 30:12 - 15 g
• MET 30:?? - 19 g
• MET 30:22 -  g < 15 g (forces are dropping now rapidly)
• MET 30:36 - 10 g
• MET 30:51 - 5 g

IRL crew would probably experience LOC briefly (which we don't model or simulate) but with no lasting damage. Even if they'd needed to manually deploy the chute for some reason, they probably would have recovered consciousness and enough of their mental faculties to intervene. But the important bit is that they would probably would not have died which is really the only thing that DRE handles here.

[rsparkyc]

4 hours ago, Starwaster said:

I'm not really seeing anything 'obviously wrong' in the video. I think the problem is this: Realism Overhaul expectations. In Reality, humans are more tolerant to g forces than most people realize. We used to get quite a few complaints about crew dying on short suborbital flights when using Realism Overhaul and what I realized was that RO needed its own set of g force parameters for crew. Stock Kerbin reentries are much shorter in duration and g forces inflicted are typically lower than than what you'd get on an Earth reentry. A LOT lower. 

So you should expect g force damage on crew to be a lot more forgiving when using Realism Overhaul. I crafted those parameters myself very carefully using 10 g as the calibration point such that DRE will not start checking for crew death for at least 1 minute at 10 g. And because of random  determination, the precise point at which a crew member dies is going to be a bit longer. And it should be longer given that the tolerance durations were derived from loss of consciousness data which is another reason that the RO configurations have to be more tolerant than for stock, which needs to be a lot more gamey. It may not look it, but it's actually much less tolerant as you pass 10 g. At 19 g the limit is reached after seconds rather than minutes. IRL, humans have survived that kind of g force for minutes without LOC. Durations in KSP must be measured at the MET clock rather than player time because the physics engine clock may be slower. (every time your MET clock turns yellow or red, physics time will be slower than usual)

I'll leave you with this excerpt about human endurance in g force testing. And these are for untrained humans. A trained human with an anti-g suit should be expected to withstand high g.

Earlier experiments reveal that untrained humans were able to stand 17 g eyeballs-in for several minutes without losing consciousness. This is in comparison to 12 g eyeballs-out. The record human tolerance of horizontal axis G force is held by acceleration pioneer John Stapp. He is known to have endured a peak "eyeballs-out" force of 46.2 times the force of gravity. This has proved that the human body is capable of this tolerance of Horizontal Axis G Force. Stapp was to live another 45 years to age 89, but his vision suffered lifelong damage due to these tests."

http://www.gforces.net/human-tolerance-horizontal.html

 

Ok, good to know then.  Looks like I'm going to have to try harder to kill some kerbals.  Thanks!

[Starwaster]

4 hours ago, rsparkyc said:

Ok, good to know then.  Looks like I'm going to have to try harder to kill some kerbals.  Thanks!

Well you could always use the handy dandy DRE menu (picture of lovely sexy cat as an added value bonus).

Either increase the crew g exponent or decrease the crew g limit. It's set to a really high number. You could also increase the kill chance but that requires config editing; I don't think the menu has it. The kill chance for RO is  a base of 1% per frame modified by how long the crew has been over limit. (the math on that part is a little complex and I forget how it works except to say that given sufficient time it works its way up to 100% if the g force conditions stay high)

[Gaarst]

Would it be possible to disable the 85% soft failure thing only on some parts?

Playing RSS and Real Heat and I have issues with my heatshield exploding during reentry as it goes slightly over 85% max temperature. It triggers the max temp fall and causes explosion even though I'm pretty sure it wouldn't reach 100% of its nominal tolerance.

[Starwaster]

9 hours ago, Gaarst said:

Would it be possible to disable the 85% soft failure thing only on some parts?

Playing RSS and Real Heat and I have issues with my heatshield exploding during reentry as it goes slightly over 85% max temperature. It triggers the max temp fall and causes explosion even though I'm pretty sure it wouldn't reach 100% of its nominal tolerance.

I'm sure it's technically possible to code such a thing but I don't think that's the right solution. What shield is doing this and what kind of reentry are you putting it through? Maybe its max temp needs bumping up. Is it a third party shield?

[Gaarst]

34 minutes ago, Starwaster said:

I'm sure it's technically possible to code such a thing but I don't think that's the right solution. What shield is doing this and what kind of reentry are you putting it through? Maybe its max temp needs bumping up. Is it a third party shield?

It's a stock shield (but I'm using a bunch of other mods, Ven's SR is the only one editing it in any way). Max temp is 3300K. When I hit the atmosphere, it heats pretty quickly up to a bit below 2800K, then it starts stabilising, unfortunately, 2800K corresponds to 85% of 3300K, so even though the shield doesn't heat a lot past this moment it still ends up exploding.

Bumping its max heat would probably solve the problem, but I was just wondering if disabling the 85% thing on heatshields would be possible with a simple config.

(Reentry is a lunar Earth reentry of a simple Mk2 pod. Periapsis is set around 55-60km)

[Starwaster]

2 hours ago, Gaarst said:

It's a stock shield (but I'm using a bunch of other mods, Ven's SR is the only one editing it in any way). Max temp is 3300K. When I hit the atmosphere, it heats pretty quickly up to a bit below 2800K, then it starts stabilising, unfortunately, 2800K corresponds to 85% of 3300K, so even though the shield doesn't heat a lot past this moment it still ends up exploding.

Bumping its max heat would probably solve the problem, but I was just wondering if disabling the 85% thing on heatshields would be possible with a simple config.

(Reentry is a lunar Earth reentry of a simple Mk2 pod. Periapsis is set around 55-60km)

Sorry but no such configuration exists

And shouldn't be necessary. Something's not configured right for that shield. Sounds like you don't have Realism Overhaul installed or the maxTemp would be higher than 3300. All RO lunar rated shields have a maxTemp of 3600. For RSS installations that are missing Realism Overhaul, there is a fallback config but the version up for download doesn't adjust the maxTemp....

So, try this: if your RSS folder actually SAYS RealSolarSystem and you DON'T have RO installed then download this updated DeadlyReentry.cfg file and copy it over your existing one in the DeadlyReentry folder.

(If you have some alternate solar system config that only uses RSS as a base then the folder won't say RealSolarSystem  and DRE can't configure for it because it doesn't know about it)

[Gaarst]

8 hours ago, Starwaster said:

Sorry but no such configuration exists

And shouldn't be necessary. Something's not configured right for that shield. Sounds like you don't have Realism Overhaul installed or the maxTemp would be higher than 3300. All RO lunar rated shields have a maxTemp of 3600. For RSS installations that are missing Realism Overhaul, there is a fallback config but the version up for download doesn't adjust the maxTemp....

So, try this: if your RSS folder actually SAYS RealSolarSystem and you DON'T have RO installed then download this updated DeadlyReentry.cfg file and copy it over your existing one in the DeadlyReentry folder.

(If you have some alternate solar system config that only uses RSS as a base then the folder won't say RealSolarSystem  and DRE can't configure for it because it doesn't know about it)

No RO. 3300K are indeed the stock temperatures for heatshields, I didn't know more was needed, I did fine until now!

Where can I download the updated config? There are some lines describing heatshields behaviour for RSS non-RO installs on the DeadlyReentry.cfg but nothing changing temperatures.

[Starwaster]

2 hours ago, Gaarst said:

No RO. 3300K are indeed the stock temperatures for heatshields, I didn't know more was needed, I did fine until now!

Where can I download the updated config? There are some lines describing heatshields behaviour for RSS non-RO installs on the DeadlyReentry.cfg but nothing changing temperatures.

Sorry I forgot to include the link:

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

[Gaarst]

1 hour ago, Starwaster said:

Sorry I forgot to include the link:

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

Thank you for this!

[Gaarst]

@Starwaster Did you change anything else in the custom DeadlyReentry.cfg you gave me? (Compared to v7.4.7.1)

I'm having this when I try using it (I haven't tried to see what changes in game):

I'm using a whole bunch of mods, but this is the first time I see this, with DRE or any other mods.

I tried re-downloading and installing a clean version of DRE, but this still happens.

Edited September 24, 2016 by Gaarst

[Starwaster]

2 hours ago, Gaarst said:

@Starwaster Did you change anything else in the custom DeadlyReentry.cfg you gave me? (Compared to v7.4.7.1)

I'm having this when I try using it (I haven't tried to see what changes in game):

I'm using a whole bunch of mods, but this is the first time I see this, with DRE or any other mods.

I tried re-downloading and installing a clean version of DRE, but this still happens.

No, it was a one line change to the file in the repository. For that to happen there must have been a discrepancy between what's in the repository and what was in the download. I'll look into it  

Nope, just one line. I need to see your output_log.txt file to see where those errors are happening. Also, in the game, click on the DRE menu button and tell me what version it says at the top of the menu.

Edited September 25, 2016 by Starwaster

[Gaarst]

49 minutes ago, Starwaster said:

No, it was a one line change to the file in the repository. For that to happen there must have been a discrepancy between what's in the repository and what was in the download. I'll look into it  

Nope, just one line. I need to see your output_log.txt file to see where those errors are happening. Also, in the game, click on the DRE menu button and tell me what version it says at the top of the menu.

output_log here (lots of mods so lots of stuff inside).

DRE menu in game says I'm using version 7.4.7, even though I just downloaded and re-installed (completely deleted old folder, not overwrote) DRE v7.4.7.1 from GitHub.

I quickly searched through the output_log, and I think the problem is there:

[ModuleManager] Applying node DeadlyReentry/DeadlyReentry/@PART[*]:HAS[@MODULE[ModuleHeatShield],~RSSROConfig[*]]:AFTER[DeadlyReentry] to DeadlyReentry/Parts/deadlyReentry_2.5Heatshield/part/2.5_Heatshield
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 64)

[ModuleManager] Error - Cannot use operators with replace (%) value: @PART[*]:HAS[@MODULE[ModuleHeatShield],~RSSROConfig[*]]:AFTER[DeadlyReentry]

This block repeats for every heatshield, maybe some % is used instead of a @, $ or some other random operators which I know absolutely nothing about.

 

Edit: so the % operator is an "edit-or-create" (just looked it), but since the value is modified with a *= there has to be a value defined in the first place, so the "create" case would throw an error. I'll try changing to an @ and see if it works (though in this case skinMaxTemp might not be defined at all).

Edit2: so changing the % to a @ removes the errors when loading MM patches, but it also removes the changes to the heatshields (still at 3300K).

Edited September 25, 2016 by Gaarst

[Starwaster]

@Gaarst I don't know what I was thinking putting that operator in there. In fact, I don't think I did that. I uh think a chimpanzee put that in.

Yeah...

[kerbarara]

Hey, not asking/requesting/suggesting update...

 

But anyone tried DRE in 1.3? Does it work?

[Starwaster]

21 hours ago, kerbarara said:

Hey, not asking/requesting/suggesting update...

 

But anyone tried DRE in 1.3? Does it work?

1.3 ???

Getting a little ahead of ourselves there? Or did you mean 1.2?

No, it's going to require an update, which i'll release next week when KSP 1.2 goes live.

 

[kerbarara]

6 hours ago, Starwaster said:

1.3 ???

Getting a little ahead of ourselves there? Or did you mean 1.2?

No, it's going to require an update, which i'll release next week when KSP 1.2 goes live.

 

Yep. 1.2, sorry.

 

Edit. Do you know of the top what were the changes?

Edited October 6, 2016 by kerbarara

[Starwaster]

14 hours ago, kerbarara said:

Yep. 1.2, sorry.

 

Edit. Do you know of the top what were the changes?

Mainly a recompile but some changes were necessary to allow a recompile. And it's version # and version checker adjusted

[linuxgurugamer]

14 hours ago, kerbarara said:

Yep. 1.2, sorry.

 

Edit. Do you know of the top what were the changes?

I did the same typo/mistake on one of my threads also

[lajoswinkler]

Now that the game simulates reentry damage, as well as Kerbal/parts high G problems, what does DRE exactly manage?

[Starwaster]

2 hours ago, lajoswinkler said:

Now that the game simulates reentry damage, as well as Kerbal/parts high G problems, what does DRE exactly manage?

Good question!

DRE had increasingly less to do lately. Mostly it balances temperature limits and will continue to do so because stock limits are too OP. (Short answer)

As far as stock g force damage, Kerbals only black out in 1.2. There is no chance of death. So DRE still has a place there. 

Stock part damage is not g force related, it is dynamic pressure. And it is all or nothing. DRE g force damage is cumulative and persistent. Most players don't realize that because if their craft is taking damage then it's probably going to be destroyed. Damaged craft are more vulnerable to further damage but can be repaired by an engineer. (Level requirement based on damage level)

[Starwaster]

Ok, so Re: KSP 1.2 and DRE

The update still isn't ready, mostly because I'm trying to decide what to do about certain new KSP 1.2 features. One such feature being the ability to move DRE settings into KSP's own settings menus. I've thought about doing that but I think I'd rather miss the ability to make changes in real time and see how they affect the crew. Mostly we're just talking about g-force damage as the menu doesn't have much else in it.

Of course, DRE is also a collection of config files, so you can still install the current version in KSP 1.2 if you need any of the parts and of course for max temperature balancing. (the non-part cfgs needing Module Manager, as always)

Edited October 11, 2016 by Starwaster

[Starwaster]

Ok, apparently something I said earlier is incorrect... parts can be destroyed by g-force stresses... in stock KSP 1.2. Not sure if that was the case at the time of that earlier post or if it was added after that.

Edited October 29, 2016 by Starwaster

[rinzler4171]

Hello Starwaster,

I can't seem to find where Deadly Reentry for 1.2 is, may I know where I can find it, or when it will be released?

Thanks!

(Thanks for the reply, should have paid more attention to the content above)

Edited October 31, 2016 by rinzler4171

[Starwaster]

8 hours ago, rinzler4171 said:

Hello Starwasher,

I can't seem to find where Deadly Reentry for 1.2 is, may I know where I can find it, or when it will be released?

Thanks!

...

When it's ready.