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

[Starwaster]

I feel compelled to ask "why?" on the point of having different densities with stock aero man. Does it really bring anything to the game or is it just realism for realism's sake in a way that won't really be noticeable and may introduce additional bugs? It's not like stock is in any way realistic in the first place.

Any chance for a config file setting to disable that and just use the old vessel.atmDensity bit?

Don't get me wrong, I really appreciate the work you've put into resolving issues here, but I'm admittedly a little leery of additional changes in this regard given the problems that have arisen.

If it weren't noticeable I probably wouldn't have bothered. It affects how fast you pick up heat.

And while it's true that this primarily is aimed at stock, it also affects the Stock Drag Fix mod (the third drag mod which is still stock aero, just without the extra drag from resources).

So this is of definite value to SDF users, especially if they also play Real Solar System. And given that I created and administer SDF, I definitely don't want it left out in the cold.

I don't know if you play Real Solar System at all, but to give a more concrete example, I once tried to duplicate Galileo's atmospheric probe mission. And I quickly found it impossible because a mission to Jool in RSS is like a mission to Jupiter IRL. In stock KSP you're probably only looking at velocities in the upper atmosphere of about 7km/s. Even with the weaker heat shields that 'stock' DRE has, that's still survivable. In RSS you're hitting the atmosphere at about 40 km/s. I wasn't able to pull that off with three stacked heat shields. The reason is that no matter what we did to the atmosphere in RSS, every planet still had the same basic properties as Kerbin. A mission like that is possible if the atmosphere mostly has the density of hydrogen, but not so much if it's like Earth only bigger. The FAR changes coming will benefit users of FAR and NEAR, which not everyone uses. (some people who play RSS may find that notion strange but it is true)

So it's realism for the sake of realism. It's realism for the sake of making the difficulty realistic instead of unrealistically difficult.

And so that not every planet feels the same going in.

So... config setting to override? Maybe... we'll see. I just got this sucker working.

[lajoswinkler]

Either you missed an update or you deployed the chutes into the fiery plasma outside the ship. Update to 6.1. (6.2 will have flight event logs telling you that your chutes failed, if they failed)

Remember, Apollo didn't deploy drogues until ~7km and mains at... ~3km? ~ish?

I've deployed them after the plasma, and during the supersonic effects. Then I've tried deploying them after those, too. Still nothing. The vessel falls down and crashes into the ground regardless of the time of deploying.

I did update to 6.1., that's why I'm puzzled. Could it be another mod messing this up?

Anyway, reentry itself seems to be more dangerous and I applaud that. One thing worries me - can we simulate stuff like throwing probes into Venus? Soviet scientists didn't brake those probes. They'd just arrange an atmospheric periapsis and that was it. Last time I did that in KSP, the probe cores could not withstand the G-force, which is weird because those aren't Kerbals. Machines should tolerate a lot more.

Also, re: the icons, they're not displaying properly in the game. Do they have actual alpha channels or just png transparency? They need alpha channels. (there is an issue with png and alpha in certain graphics packages. Photoshop for instance needs SuperPNG plugin to properly deal with png alpha)

That's weird. They should have alpha channels, I've included them while exporting. Give me some time to figure this out and maybe try with Photoshop. The software I was working with is ancient (like, really) so perhaps that was the reason.

Tell me the format of the file you prefer.

Edited October 11, 2014 by lajoswinkler

[colin_in_space]

Sorry, I am temporarily trapped in 0.24.2, as 0.25 runs like a slug on both my computers. But this deadly reentry mod is no good with 0.24.2. Any chance I can get a link to the last version whioch worked with 0.24.2 (deadly reentry 2 I belive)? searched the forums but can't find a like anywhere.

Thanks : )

[FlowerChild]

I don't know if you play Real Solar System at all, but to give a more concrete example, I once tried to duplicate Galileo's atmospheric probe mission. And I quickly found it impossible because a mission to Jool in RSS is like a mission to Jupiter IRL. In stock KSP you're probably only looking at velocities in the upper atmosphere of about 7km/s. Even with the weaker heat shields that 'stock' DRE has, that's still survivable. In RSS you're hitting the atmosphere at about 40 km/s. I wasn't able to pull that off with three stacked heat shields. The reason is that no matter what we did to the atmosphere in RSS, every planet still had the same basic properties as Kerbin. A mission like that is possible if the atmosphere mostly has the density of hydrogen, but not so much if it's like Earth only bigger. The FAR changes coming will benefit users of FAR and NEAR, which not everyone uses. (some people who play RSS may find that notion strange but it is true)

Thanks for the detailed explanation man, and it makes a lot more sense for me now. I'm a big fan of being able to bring more diversity to each individual planet, so if these changes expose variables that make that a greater possibility, I'm all for it.

So this is of definite value to SDF users, especially if they also play Real Solar System. And given that I created and administer SDF, I definitely don't want it left out in the cold.

Yup, I can definitely understand that as well, as I'm of course interested in trying to ensure that stock sized Kerbin, stock aero, and by extension of that, BTSM, don't get left out in the cold either

[Starwaster]

I've deployed them after the plasma, and during the supersonic effects. Then I've tried deploying them after those, too. Still nothing. The vessel falls down and crashes into the ground regardless of the time of deploying.

I did update to 6.1., that's why I'm puzzled. Could it be another mod messing this up?

Anyway, reentry itself seems to be more dangerous and I applaud that. One thing worries me - can we simulate stuff like throwing probes into Venus? Soviet scientists didn't brake those probes. They'd just arrange an atmospheric periapsis and that was it. Last time I did that in KSP, the probe cores could not withstand the G-force, which is weird because those aren't Kerbals. Machines should tolerate a lot more.

That's weird. They should have alpha channels, I've included them while exporting. Give me some time to figure this out and maybe try with Photoshop. The software I was working with is ancient (like, really) so perhaps that was the reason.

Tell me the format of the file you prefer.

Parachutes: What is your speed when deploying?

Eve: I've sent quite a few probes to Eve with DRE installed. Both stock Eve and RSS Eve (Venus). I'll send one right now to see how it does.

Icons: Well I know tga works. I use that myself. Especially when importing from Unity because it can compress them down fairly well.

[Starwaster]

Yup, I can definitely understand that as well, as I'm of course interested in trying to ensure that stock sized Kerbin, stock aero, and by extension of that, BTSM, don't get left out in the cold either

With that in mind, I'm not familiar with any changes that BTSM might or might not be affected by. I trust that you'll let me know if something breaks but is there anything about it vis a vis DREC that I should know about?

[FlowerChild]

With that in mind, I'm not familiar with any changes that BTSM might or might not be affected by. I trust that you'll let me know if something breaks but is there anything about it vis a vis DREC that I should know about?

Yup, absolutely man, and I very much appreciate the consideration

BTSM is primarily about a tightly balanced experience, where every change made tends to affect 10 other things, so pretty much anything is bound to affect it one way or another and require a certain amount of tweaking on my part. Nothing that can really be done there other than me adapting to changes as they are made, as I can't really expect you to hold back development of DR on BTSM's account. I run into the same thing with pretty much every vanilla update as well.

Knowing why something is of benefit however always helps in that department, at least with regards to my own sanity, so I hope you forgive me if I pop up here every once and awhile asking that question. I think Rowsdower is getting fairly used to me asking Squad the same thing pretty regularly

[Starwaster]

Version 6.2 update. This takes it back to the previous method of calculating densities except that atmospheric density is different from planet to planet. The differences are subtle, you will notice reentry heating rates are different. Probably the most prominent would be Jool. Aerobraking you'll probably find to be a little easier, but you're still coming in at 2-3 times faster than Kerbin reentries so unshielded parts will go up like popcorn.

Parachute failures are now logged in the Flight Logger.

This is probably the last update for awhile until an expected pull request from Nathan with FAR atmospheric density integration or bug fixes or until I'm ready to finalize toolbar support.

v6.2

*Fixed issue with Jool NaN temperature. (capped low end of getExternalTemperature() to -160)

*Capped low end of ambientTemperature to absolute zero.

*NaN protection for part.temperature

*Added density field to debug GUI

*Replaced hard coded gas constant with per-planet specificGasConstant. (to-do: move that data to config files)

*ReentryPhysics still uses hard coded 287.058 value

*Added flight event logging for parachute failures.

*Added legacyAero config file option. If present and true then density retrieved from vessel.atmDensity

[taniwha]

Starwaster: as of this writing, the thread title still says 6.1.

[Beale]

Thanks for the advice, parachute deployment seems to work fine after updating to 6.2

I am still having G-related deaths, however, despite being disabled in the config.

This little vehicle is an extreme example, but even some of my standard lifting rockets are killing the crew when nearing the edge of space.

My "fatal" G-limit is set to the standard 90,000.

If I read this right, the Gs should never climb higher than 30

crewGClamp = 30 // Any G level > this is treated as this
	crewGPower = 4 // exponent to the G level. G damage is added at a rate of G^power per second
	crewGMin = 5 // Any G level < this is ignored for crew damage, and G damage is reset
	crewGWarn = 450000 // when G damage reaches this level, warn the player
	crewGLimit = 900000 // when G damage reaches this level, start killing crew
	crewGKillChance = 0.01 // chance per tick a crewmember will die (if damage is > GLimit)

[Aleksey-Forest]

Fairing parts from KWRocketry not protecting loads inside against shockwave http://imgur.com/a/gM1Nr#3

Same issue with Procedural Fairings (http://forum.kerbalspaceprogram.com/threads/39512)

This is a bug or feature?

[lajoswinkler]

Parachutes: What is your speed when deploying?

I think the lowest speed I've tried with was less than 250 m/s, probably close to 200 m/s. It wasn't supersonic, I'm sure of that.

Eve: I've sent quite a few probes to Eve with DRE installed. Both stock Eve and RSS Eve (Venus). I'll send one right now to see how it does.

I'll check everything out again with 6.2. and let you know the details.

Icons: Well I know tga works. I use that myself. Especially when importing from Unity because it can compress them down fairly well.

Working on it.

[Starwaster]

I am still having G-related deaths, however, despite being disabled in the config.

There is no explicit disable setting for g force damage so what did you change to try to disable it?

This little vehicle is an extreme example, but even some of my standard lifting rockets are killing the crew when nearing the edge of space.

Sounds like you need a new standard for lifting rockets. Your current standard can't be considered man-rated. (or Kerbal rated)

My "fatal" G-limit is set to the standard 90,000.

crewGWarn and crewGLimit refer to cumulative G forces. It's like G force damage hit points. If you've been experiencing more than crewGMin then you start accumulating G force 'damage'. Taken from the values below, every frame that your g forces are over 5 you will take cumulative gforce 'damage'. When that accumulated damage (or running total of damage if you prefer) reaches 450,000 then DRE will start displaying a warning for as long as your g force level is over crewGMin. When the accumulated total exceeds 900,000 it starts rolling virtual dice to 'kill' Kerbals.

If I read this right, the Gs should never climb higher than 30

That means it will not add more than 30 at a time. So if the update function runs and your crew actually took 60 worth of damage then it only applies 30 of it. (it's not literally 30g either, the amount of g damage is taken from a formula that uses crewGMin and crewGPower and crewGClamp per update and scaled by delta time so that excessively fast or slow computers don't scale the damage up or down)

crewGClamp = 30 // Any G level > this is treated as this
    crewGPower = 4 // exponent to the G level. G damage is added at a rate of G^power per second
    crewGMin = 5 // Any G level < this is ignored for crew damage, and G damage is reset
    crewGWarn = 450000 // when G damage reaches this level, warn the player
    crewGLimit = 900000 // when G damage reaches this level, start killing crew
    crewGKillChance = 0.01 // chance per tick a crewmember will die (if damage is > GLimit)

So, bottom line is your rocket is just too powerful and you need to scale your rocket's thrust back using thrust limits or you need to throttle back when you get warnings about g force damage. (if you use any mods to measure thrust to weight then your rocket should have a TWR of about 1.25 at sea level.

Fairing parts from KWRocketry not protecting loads inside against shockwave http://imgur.com/a/gM1Nr#3

Same issue with Procedural Fairings (http://forum.kerbalspaceprogram.com/threads/39512)

This is a bug or feature?

There's always been a problem with detecting certain fairings. I believe it to be a problem with their colliders at the forward end. It's always been problematic and if the part lacks colliders in that area then there's nothing DRE can do to detect that part of the fairing. If you have FAR / NEAR installed then DRE will try to use their fairing detection code which is a bit more aggressive in looking for fairings

[Beale]

crewGWarn and crewGLimit refer to cumulative G forces. It's like G force damage hit points. If you've been experiencing more than crewGMin then you start accumulating G force 'damage'. Taken from the values below, every frame that your g forces are over 5 you will take cumulative gforce 'damage'. When that accumulated damage (or running total of damage if you prefer) reaches 450,000 then DRE will start displaying a warning for as long as your g force level is over crewGMin. When the accumulated total exceeds 900,000 it starts rolling virtual dice to 'kill' Kerbals.

Alright, I understand the mechanics of it a bit better now, thank you for the full explanation. But, why did this never happen in older versions? The numbers haven't changed IIRC.

Also, what numbers could you recommend to make G-fatalities practically "switched off" ?

Thank you for the help

[FlowerChild]

*Added legacyAero config file option. If present and true then density retrieved from vessel.atmDensity

Thanks for that man. Very much appreciated.

[skeevy]

Alright, I understand the mechanics of it a bit better now, thank you for the full explanation. But, why did this never happen in older versions? The numbers haven't changed IIRC.

Also, what numbers could you recommend to make G-fatalities practically "switched off" ?

Thank you for the help

[COLOR=#3E3E3E][I]crewGClamp = 30 // Any G level > this is treated as this[/I][/COLOR]
    crewGPower = 4 // exponent to the G level. G damage is added at a rate of G^power per second
    crewGMin = 5 // Any G level < this is ignored for crew damage, and G damage is reset
    crewGWarn = 450000 // when G damage reaches this level, warn the player
    crewGLimit = 900000 // when G damage reaches this level, start killing crew 
[FONT=Verdana]       crewGKillChance = 0.01 // chance per tick a crewmember will die (if damage is > GLimit)[/FONT]

increase crewGMin to 31 or 1G higher than crewGClamp is set at.

You won't get damage until 31G's is hit, only anything over 30G's is set to be registered as 30 so you'll never actually get 31 or more G's.

my fault. the above was bad information

So, if you really just want to kill it outright, you'd do two things. Set crewGKillChance to 0.0 (so crew just can't be killed from g damage) and then if you don't want to see the g force warnings, set crewGMin to something insanely high like 69105

Edited October 11, 2014 by skeevy

[Starwaster]

Thanks for that man. Very much appreciated.

You'll have to add it to the config file yourself for now. Later on it'll go in the settings menu (don't have one YET) and/or debug menu.

Though you should at least give the new system a try

Alright, I understand the mechanics of it a bit better now, thank you for the full explanation. But, why did this never happen in older versions? The numbers haven't changed IIRC.

Also, what numbers could you recommend to make G-fatalities practically "switched off" ?

Thank you for the help

[COLOR=#3E3E3E][I]crewGClamp = 30 // Any G level > this is treated as this[/I][/COLOR]
    crewGPower = 4 // exponent to the G level. G damage is added at a rate of G^power per second
    crewGMin = 5 // Any G level < this is ignored for crew damage, and G damage is reset
    crewGWarn = 450000 // when G damage reaches this level, warn the player
    crewGLimit = 900000 // when G damage reaches this level, start killing crew 
[FONT=Verdana]      crewGKillChance = 0.01 // chance per tick a crewmember will die (if damage is > GLimit)[/FONT]

increase crewGMin to 31 or 1G higher than crewGClamp is set at.

You won't get damage until 31G's is hit, only anything over 30G's is set to be registered as 30 so you'll never actually get 31 or more G's.

No, that doesn't work the way you're thinking it does. Yes crewGMin of 31 would stop g force damage from kicking in until 31 g but then you would be assessed 30 g worth of damage. Behold this piece of code!

[I]// Behold!!!
[/I]               if (Math.Max(displayGForce, geeForce) >= crewGMin) // This says if we're getting Gs more than crewGMin then (see below)
                {
                    gExperienced += Math.Pow(Math.Min(Math.Abs(Math.Max(displayGForce, geeForce)), crewGClamp), crewGPower) * deltaTime; // Take some g force damage no higher than crewGClamp

So, if you really just want to kill it outright, you'd do two things. Set crewGKillChance to 0.0 (so crew just can't be killed from g damage) and then if you don't want to see the g force warnings, set crewGMin to something insanely high like 69105

Edited October 11, 2014 by Starwaster

[FlowerChild]

You'll have to add it to the config file yourself for now. Later on it'll go in the settings menu (don't have one YET) and/or debug menu.

Though you should at least give the new system a try

I definitely will, but at the moment I'm looking forward to a break from all the aerobraking tests I was doing the past couple of days and want to be able to provide an answer for BTSM players as to which version of DR is meant to be installed with it

And yup, found the config setting in the source. Don't worry about the GUI, at least not on my account, as all of BTSM's changes go through the config files via ModuleManager, so the way it is now is ideal for me.

[skeevy]

Thanks for clarifying that for me. I'll edit that post and remove the bad information.

[FlowerChild]

Just noticed a small issue:

It turns out if struts are destroyed during reentry, any decouplers within the area the struts previously connected cease to function (like if you strut a radially attached tank to the main body with a radial decoupler in between and the struts connecting the two burn away). You can trigger them, the sound effect is played, but the parts refuse to separate, although they no longer seem to be considered part of the same vessel.

This seems to apply to docking ports within a previously strutted area as well.

I just noticed this on the same ship I previously posted screenshots of as I was giving my old Jool aerobrake test a go with the new release.

On one hand, it's kinda cool, as it almost feels like the parts were fused together or something. On the other hand, it can definitely feel buggy depending on where it happens on a ship.

EDIT: Another small one:

In the space center view, a small sliver of an icon appears (just a few pixels wide). If you click on it, then what appears to be a WIP DR difficulty menu appears.

Edited October 11, 2014 by FlowerChild

[NathanKell]

Starwaster: woo, release!

I don't immediately have any reason for the bug FlowerChild mentions, alas.

Also, can you edit the thread title (OP->edit->advanced) to change the date? It still says 7 Oct.

[FlowerChild]

I don't immediately have any reason for the bug FlowerChild mentions, alas.

It feels to me like whatever physics connections are created by the struts aren't being destroyed when DR destroys the struts due to heat, but when the decoupler separates, since struts are no longer connecting the two pieces, it isn't deleting those connections as it normally would.

I suspect the same thing applies to fuel lines BTW. I had both on that vessel, and some connections were "fused" that didn't have any fuel lines attached, so it happens with struts alone, but I can't confirm it happens with fuel lines alone given all the connections I had with them were also strutted.

It does make some sense though since struts are physicless parts that automagically apply physics through their connections. They must be a big exception case internally within Squad's code, and may have their own data structures which govern those connections.

EDIT: Checking the strutConnector class, I notice a "BreakJoint()" method, while the FuelLine class has a corresponding "BreakLine()" method. Not entirely certain, but I strongly suspect that calling those methods right before destroying struts or lines would do the trick.

Edited October 11, 2014 by FlowerChild

[Starwaster]

It feels to me like whatever physics connections are created by the struts aren't being destroyed when DR destroys the struts due to heat, but when the decoupler separates, since struts are no longer connecting the two pieces, it isn't deleting those connections as it normally would.

I suspect the same thing applies to fuel lines BTW. I had both on that vessel, and some connections were "fused" that didn't have any fuel lines attached, so it happens with struts alone, but I can't confirm it happens with fuel lines alone given all the connections I had with them were also strutted.

It does make some sense though since struts are physicless parts that automagically apply physics through their connections. They must be a big exception case internally within Squad's code, and may have their own data structures which govern those connections.

EDIT: Checking the strutConnector class, I notice a "BreakJoint()" method, while the FuelLine class has a corresponding "BreakLine()" method. Not entirely certain, but I strongly suspect that calling those methods right before destroying struts or lines would do the trick.

Unfortunately, (aside from g force destruction) DRE doesn't destroy anything. We just keep feeding heat into it until KSP says 'enough!' and blows the parts up.

I'll run some tests on it but I strongly suspect this is something that needs fixing on Squad's side, just like all the other issues with decoupling strutted parts. (i.e., nullifying decoupler forces or causing parts to swing inward if you strutted them to something other than the part the decoupler was connected to. If you haven't experienced that last one, it's a real riot. SRBs suddenly swinging inwards and smashing your fuel tanks even though you put the strongest KWR SRB separators on them)

[FlowerChild]

Unfortunately, (aside from g force destruction) DRE doesn't destroy anything. We just keep feeding heat into it until KSP says 'enough!' and blows the parts up.

I just put together a potential fix which I'm testing out right now. Will let you know how it works out.

I have a good test case here for something that I suspect may be hard to generate one for, and I suspect I know how to resolve it, so I figured I'd lend a hand with it

[NathanKell]

FlowerChild, that makes sense. Squad doesn't often explode parts, so it's understandable there's bugs with it re: struts and lines.

Starwaster: thread title date fix splurg....