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

[Darkblade48]

For DRE v5.0, the changelog states that:

*Now will cut chutes when they burn up, rather than destroying the part. Max chute temperature defaults to 1/2 part max temperature

Does this apply to deployed parachutes only, or does it also apply to non-deployed parachutes? If the latter, essentially parachutes will burn up twice as easily as before (v4.8)?

[NathanKell]

The "cut chutes...rather than destroy the part" means it will not do *anything* to the part unless the part exceeds its normal max temperature.

In prior versions, if you deployed a chute when things were too hot, the whole part would go kaboom. Now, the chute is cut but the part stays alive.

If you have RealChutes, this matters, because you'll have a spare chute and can deploy again later.

Consider a part with 1200 max temp. If you deploy a chute and adjusted shockwave temperature is >600, the chute will burn up but the part will be fine. Only if the *part* temperature goes over 1200 will the *part* be destroyed.

[Starwaster]

The "cut chutes...rather than destroy the part" means it will not do *anything* to the part unless the part exceeds its normal max temperature.

In prior versions, if you deployed a chute when things were too hot, the whole part would go kaboom. Now, the chute is cut but the part stays alive.

If you have RealChutes, this matters, because you'll have a spare chute and can deploy again later.

Consider a part with 1200 max temp. If you deploy a chute and adjusted shockwave temperature is >600, the chute will burn up but the part will be fine. Only if the *part* temperature goes over 1200 will the *part* be destroyed.

Nice touch and one I was either going to suggest or submit code for.

Though even 1/2 the part temperature is too lenient. You should base it off the chute's material. Nylon melts at 255C.

Failure might happen sooner, or maybe 255 is fine.

Not sure about Kevlar's melting point..

[RedAV8R]

Per DuPont, KEVLAR doesn't melt, it decomposes (whatever the heck that means). It doesn't do that until 427+C. However, the maximum temp for long term use of Kevlar is 149-177C due to properties/characteristics of KEVLAR changing. I personally wouldn't want to trust a parachute above that ~150C point.

[Starwaster]

Per DuPont, KEVLAR doesn't melt, it decomposes (whatever the heck that means). It doesn't do that until 427+C. However, the maximum temp for long term use of Kevlar is 149-177C due to properties/characteristics of KEVLAR changing. I personally wouldn't want to trust a parachute above that ~150C point.

That explains Siri's refusal to cite me a melting point then.

I thought she was just being obstinate.

I told her to stop it but she replied that she wasn't doing anything so she couldn't stop.

On another note, she also refuses to help me find places to dispose of corpses any more either :(

[StarLiner]

Would there be anyway to get ahold of version 4.8 for 23.5?

Edit: Ignore me, I found it

Edited July 23, 2014 by StarLiner

[RedAV8R]

Would there be anyway to get ahold of version 4.8 for 23.5?

https://github.com/NathanKell/DeadlyReentry/releases

[NathanKell]

Starwaster: planned once Chris adds max temperatures to his chutes

[Darkblade48]

The "cut chutes...rather than destroy the part" means it will not do *anything* to the part unless the part exceeds its normal max temperature.

In prior versions, if you deployed a chute when things were too hot, the whole part would go kaboom. Now, the chute is cut but the part stays alive.

If you have RealChutes, this matters, because you'll have a spare chute and can deploy again later.

Consider a part with 1200 max temp. If you deploy a chute and adjusted shockwave temperature is >600, the chute will burn up but the part will be fine. Only if the *part* temperature goes over 1200 will the *part* be destroyed.

Thanks for the clarification!

[Tortoise]

Says it's not compatible with 24.1 when I loaded it, but we'll have to see.

Edited July 25, 2014 by Tortoise

[panarchist]

Says it's not compatible with 24.1 when I loaded it, but we'll have to see.

That's because it uses Module Manager. MM now notifies whenever the KSP version increments and it encounters a mod compiled under an older version. It's basically an alert to check for updates - frequently the mod will continue to work just fine. NathanKell can confirm, but I'm pretty sure that the 24.1 update isn't mod-breaking for DREC, especially not on 32-bit.

[sumghai]

Says it's not compatible with 24.1 when I loaded it, but we'll have to see.

That's because it uses Module Manager. MM now notifies whenever the KSP version increments and it encounters a mod compiled under an older version. It's basically an alert to check for updates - frequently the mod will continue to work just fine. NathanKell can confirm, but I'm pretty sure that the 24.1 update isn't mod-breaking for DREC, especially not on 32-bit.

panarchist is correct - despite the alert, both FAR and DREC actually still function properly in 0.24.1 in-game.

[Starwaster]

That's because it uses Module Manager. MM now notifies whenever the KSP version increments and it encounters a mod compiled under an older version. It's basically an alert to check for updates - frequently the mod will continue to work just fine. NathanKell can confirm, but I'm pretty sure that the 24.1 update isn't mod-breaking for DREC, especially not on 32-bit.

Actually it's a version checker that each individual mod has incorporated. (or not incorporated)

If a mod does't use the version checker then there won't be any warning displayed that that mod might have compatibility issues.

[NathanKell]

Changelog:

v5.1

*Recompiled for 0.24.1

*Nerfed overpowered 1.25m heatshield, had double the dissipation it should.

[biohazard15]

Can you give any advice on config changes for NEAR? Currently, reentry doesn't feel, um, deadly. I can easily use "traditional" landings at KSP (i.e. aim east of KSP, Pe is underground) with any capsule. Parts aren't burning at all - I can easily deorbit and recover any part, even Kerbodyne ones. I do not want RSS-grade reentry, just some more deadliness

[Starwaster]

Can you give any advice on config changes for NEAR? Currently, reentry doesn't feel, um, deadly. I can easily use "traditional" landings at KSP (i.e. aim east of KSP, Pe is underground) with any capsule. Parts aren't burning at all - I can easily deorbit and recover any part, even Kerbodyne ones. I do not want RSS-grade reentry, just some more deadliness

Only the advice from the front page, start with shockwave exponent, begin increasing until you have the desired level of deadliness.

Press alt-D+R, that opens the debug menu. You'll find shockwave exponent and temperature multiplier among others. An RSS Kerbin shockwave would typically be ~7700 or more, depending on circumstances. Stock Kerbin is going to be around ~2000. If you start getting too high you're going to need those RSS shields.

[Kesselya]

Anyone have any idea why Jebediah dies from G-force damage when my SOI changes from Kerbin to the Mun? I'm not undergoing any acceleration or time warp, it's just the act of the SOI change. I changed the G-Crew-Max to 500 and it stopped for the one SOI change, but I think that's a bit ridiculous to have to do every time I transition from one body to another.

[Taki117]

Anyone have any idea why Jebediah dies from G-force damage when my SOI changes from Kerbin to the Mun? I'm not undergoing any acceleration or time warp, it's just the act of the SOI change. I changed the G-Crew-Max to 500 and it stopped for the one SOI change, but I think that's a bit ridiculous to have to do every time I transition from one body to another.

It's because when you change SOIs the G-meter pegs high (For whatever reason) which shouldn't be an issue (I've never had a Kerbal die because of it) unless you changed a setting somewhere.

[krenshala]

Nathan, I'll just blame it all on a misunderstanding exacerbated by the phrasing I used.

Regardless, I'm glad to see your usual rapid updating. DRE is one of my 'must have' mods now that I've gotten used to it.

[Starwaster]

It's because when you change SOIs the G-meter pegs high (For whatever reason) which shouldn't be an issue (I've never had a Kerbal die because of it) unless you changed a setting somewhere.

There's even code (I think) in DREC to watch for high G force during SOI changes and ignores it on the assumption that it's just more of KSP's usual phantom forces. G force has to either be really high and sustained or really REALLY high over a short period to be lethal. I've had Kerbals survive over 10Gs and I thought for sure they were gonna snuff it until I saw the needle start to drift back down.

I haven't made a manned munar voyage since downloading 0.24 ....

[NathanKell]

Uploaded v5.2, just a recompile.

[Kesselya]

I'm using the Deadly Reentry settings that Scott Manley talked about in his Interstellar Mod video: the Crew G Limit set to 50. I'm going to try and reset all the parameters to the default and pray that it just works with Ferram Aerospace. I just had my crew in my Spaceplane die when I touched down extremely gently (50 m/s horizontal speed, -3 m/s vertical speed).

After that I reloaded my quicksave, and used my abort sequence to descend only the capsule, 2 radial parachutes, and my front gear bay. I landed on the gear bay at 9 m/s and my crew died to G force. I ended up reloading for a 3rd attempt and splashed down my whole plane over the water at the same 9 m/s. The entire plane survived, as did my crew. It feels like something is screwy with the way the wheels touch down on the surface.

Edited July 25, 2014 by Kesselya
additional clarification

[justhearit]

It crashes my ksp at startup after the loading bar hits 100%. any ideas?

[NathanKell]

I do have an idea: please don't post and PM.

I do check the forums quite regularly, especially my own threads, and I do respond to support requests, although poking me by PM after you've posted is *not* liable to make me most want to be helpful.

Now, I need logs, and more information. Exact version of KSP (and 32/64), exact version of DRE, any other mods installed (and their versions) and, most importantly:

Cause the problem. Quit KSP (if it hasn't crashed). Upload your output log (NOT ksp.log) to dropbox or something.

Windows: KSP_win\KSP_Data\output_log.txt OR KSP_win64\KSP_x64_DATA\output_log.txt (depending on which used)

Mac OSX: Open Console, on the left side of the window there is a menu that says 'files'. Scroll down the list and find the Unity drop down, under Unity there will be Player.log Aka Files>~/Library/Logs>Unity>Player.log

Linux: ~/.config/unity3d/Squad/Kerbal\ Space\ Program/Player.log

[justhearit]

I do have an idea: please don't post and PM.

I do check the forums quite regularly, especially my own threads, and I do respond to support requests, although poking me by PM after you've posted is *not* liable to make me most want to be helpful.

Now, I need logs, and more information. Exact version of KSP (and 32/64), exact version of DRE, any other mods installed (and their versions) and, most importantly:

Cause the problem. Quit KSP (if it hasn't crashed). Upload your output log (NOT ksp.log) to dropbox or something.

Windows: KSP_win\KSP_Data\output_log.txt OR KSP_win64\KSP_x64_DATA\output_log.txt (depending on which used)

Mac OSX: Open Console, on the left side of the window there is a menu that says 'files'. Scroll down the list and find the Unity drop down, under Unity there will be Player.log Aka Files>~/Library/Logs>Unity>Player.log

Linux: ~/.config/unity3d/Squad/Kerbal\ Space\ Program/Player.log

version: .24.2 64bit

link to crash output log https://www.dropbox.com/s/za3dfsrmmg97gpe/output_log.txt