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

[Wanderfound]

I would very much disagree. I've ridden through about a minute and a half in some reentries with bits of my plane starting to burn but ultimately staying intact(ish).

It varies a lot based on how fast you're coming down. Overheated level flight can be sustained for quite a while, but an over-hot dive is an express ticket to boomtown, IME.

[Starwaster]

It varies a lot based on how fast you're coming down. Overheated level flight can be sustained for quite a while, but an over-hot dive is an express ticket to boomtown, IME.

Agreed, YMMV, not only according to your reentry profile but depending on craft design as well.

[kendoka15]

Is there somewhere I could find detailed info on the new difficulty settings? It's set to easy by default but I don't know if it's easier then before

[Tellion]

I just managed to *finally* make a reentry-capable shuttle for a 6.4x install yesterday and then this patch comes along. Nerf asap!!!!!

[Starwaster]

Is there somewhere I could find detailed info on the new difficulty settings? It's set to easy by default but I don't know if it's easier then before

No I haven't drafted anything yet (it's Easy by default? Ok sorry I thought I fixed that. Should be Normal by default)

Keep in mind that these settings are still being worked on and may change.

Easy:

densityExponent = 0.9 (Reentry heating doesn't start until deeper in the atmosphere)

crewGMin = 10 (Kerbals can withstand up to 10g before they are at risk. )

parachuteMultiplier = 0.5 (Parachutes are twice as durable so you can deploy them higher)

Normal

Is mostly the original default settings except that the density exponent has changed from 0.85 to 0.8 and the

heatMultiplier = 20 (reduced from 25 to compensate for the extra heating.)

Hard

densityExponent = 0.6 (heating starts VERY early in reentry)

heatMultiplier = 1 (typically this would be around 25)

temperatureExponent = 1.55 (using this to control heat instead of heatMultiplier which is ignored by heatshield loss curve)

useAlternateDensity = True (this is very easy to misuse and is only used by Hard level so that lower atmospheric heating isn't excessive)(density is greatly reduced)

others:

Dissipation Cap (If True, then heat shields will begin dissipating more and more heat as they approach destruction level)

Legacy Aerothermodynamics (older heat model used. All planets have the same heating for a given velocity and atmospheric pressure)

Edited November 13, 2014 by Starwaster

[Starwaster]

Found and squashed error in the RealChute patches. Will be in next update or you can download the file here (right click and save as). (overwrite the existing file in the DeadlyReentry folder)

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

[jpkerman]

My capsules seem to be flipping over (nose first) now unless i keep SAS 'on' . Added nothing new except DRE 6.3.1 beta. Deleted all old files first. Is this part of the update? No more free fall re-entry?

[White Owl]

Just tried this, used the default normal settings, and launched a rocket. Parts inside a procedural payload fairing caught fire and exploded during launch. I reverted the flight, changed to the legacy mode, and relaunched without issue.

Is the new version not compatible with payload fairings?

[sp1989]

Just tried this, used the default normal settings, and launched a rocket. Parts inside a procedural payload fairing caught fire and exploded during launch. I reverted the flight, changed to the legacy mode, and relaunched without issue.

Is the new version not compatible with payload fairings?

Proc fairings do nothing unless you are useing FAR. Fairings don't protect payloads otherwise. FAR recognizes fairings stock doesnt. So because of the destiny changes your payloads are now blowing up.

[White Owl]

Proc fairings do nothing unless you are useing FAR. Fairings don't protect payloads otherwise. FAR recognizes fairings stock doesnt. So because of the destiny changes your payloads are now blowing up.

I always use FAR. Sometimes I forget that others don't. You're right that I should've stated this was with FAR.

Also using RSS 6.4-scale, if that matters. Yeah, launch and orbital velocities are higher and I expect temps to be higher too... but why was stuff inside the fairing burning up instead of the fairing?

[Starwaster]

My capsules seem to be flipping over (nose first) now unless i keep SAS 'on' . Added nothing new except DRE 6.3.1 beta. Deleted all old files first. Is this part of the update? No more free fall re-entry?

DeadlyReentry does not affect aerodynamics. Unless you count drag settings on any of the chute parts. I did do some changes to the stock chutes and Real Chute parts and I think that did include drag, but I use the same parts and I haven't noticed a problem with it. If it is an issue though I can revert that part of it out. (drag wasn't even an important change, the patch to those parts mostly added weak heat shielding to make them more like the heat shielded nose cones)

Just tried this, used the default normal settings, and launched a rocket. Parts inside a procedural payload fairing caught fire and exploded during launch. I reverted the flight, changed to the legacy mode, and relaunched without issue.

Is the new version not compatible with payload fairings?

That part of the plugin only affects how atmospheric density is calculated (and with it, how much heat is transferred from the shockwave to the vessel parts).

It doesn't affect fairings and how they shield parts at all. If it worked after switching to Legacy mode then that was coincidence. Whether or not fairing enclosed parts are considered shielded is determined in one of several ways

1. FAR is checked to see if it thinks a part is shielded. If FAR is not installed, returns false or an error occurs when getting the shielded state then..
   
2. A ray is fired from the part along its flight path to a distance of 10 meters. If the ray hits anything at all (including parts that broke off or were jettisoned from the ship) then the part is considered shielded.
   
3. (there is also a stock KSP property that is checked for a shielded state but nothing currently uses that property)
   

So basically it comes down to either FAR or a raycast, and both can fail for various reasons. FAR because (as near as I can tell) it checks a box shaped area, and parts very close to the edges of the fairing can fall outside the box. The raycast can fail if it slips between the fairing parts, which can happen when it the part is dead center and the ray passes exactly along the long axis between the fairing front. I also suspect a problem with the colliders on the front part of the fairing. Finally, because the ray is 10 meters long, parts farther away from the fairing front than 10 meters will fail the raycast test.

Honestly I have always had issues with the Procedural Fairing reliably passing the raycast test. FAR is more accurate and even it can fail as mentioned above. I once had plans to use the PF parts to make a Copernicus styled aeroshell for Duna/Mars reentry and that's when I noticed it had a problem. So what you're telling me isn't really news and it's not particular to this new version. You're only just now noticing it. Sorry

Proc fairings do nothing unless you are useing FAR. Fairings don't protect payloads otherwise. FAR recognizes fairings stock doesnt. So because of the destiny changes your payloads are now blowing up.

See my reply to White Owl above. DRE does have its own method for determining shield state if FAR is not installed or if the FAR test fails, so it's not accurate to say that fairings do nothing if FAR isn't installed. (but as mentioned, both can fail)

Edited November 16, 2014 by Starwaster

[White Owl]

Fair answer, thanks. Yes, it was the part directly along the centerline, top of the stack. And then the part underneath it. And the one under that!

[Starwaster]

Fair answer, thanks. Yes, it was the part directly along the centerline, top of the stack. And then the part underneath it. And the one under that!

Yeah, might want to put a nose cone in front, the one that has some shielding in it. (even 10% reflective is enough). Or fly a flight plan that's a few degrees off from prograde. Kind of an ugly solution but even a little bit will throw the ray off-center.

One of these days I'd like to code up a replacement for both FAR and DRE's shielding checks. Something that checks once when the vessel is loaded in and sets payload parts to be shielded by recursing from the attachment node of the fairing base. No laggy raycasts or bounding boxes. Bind to the vessel modified event so if any parts detach, break, blow up, jettison, etc etc then check again. But it's a bit of a hassle to write up and I just haven't gotten around to it.

[NathanKell]

FAR has a serious bug with Proc Fairings. It's corrected in git, but ferram hasn't released a new official release.

[ModZero]

So, um, I have an issue in Linux x86_64 with DR and KAS, that goes away without DR: if I try to take something out from a container, this happens:

[LOG 18:20:28.477] [KAS] WaitAndGrab(Container) - Waiting rigidbody to initialize...

[EXC 18:20:28.487] NullReferenceException: Object reference not set to an instance of an object

DeadlyReentry.ModuleAeroReentry.OnStart (StartState state)

Part.ModulesOnStart ()

Part+ ^F.MoveNext ()

[LOG 18:20:28.489] [Progress Node Reached]: Landing

[LOG 18:20:28.489] [Progress Node Complete]: Landing

[LOG 18:20:28.499] [KAS] WaitAndGrab(Container) - Waiting rigidbody to initialize...

[LOG 18:20:28.500] [KAS] WaitAndGrab(Container) - Waiting rigidbody to initialize...

[LOG 18:20:28.532] [KAS] WaitAndGrab(Container) - Waiting rigidbody to initialize...

...and the object pops up about 100m away from me. And jumps 15km away as soon as I try to warp, despite not moving anywhere that fast.

Another issue (but with no serious gameplay effect) is that Kerbal RCS effects are gone - also back if I remove DR.

The only mods in this install are DR, KAS, MM and HyperEdit. The last one is not included in my main install, and the issues are present there as well.

Finally, full log file. Sorry if this is a known issue and/or actually a KAS thing that's just triggered by DR.

EDIT: oh, now I went to the KAS thread and noticed mentions of the issue.

Edited November 16, 2014 by ModZero

[Starwaster]

So, um, I have an issue in Linux x86_64 with DR and KAS, that goes away without DR: if I try to take something out from a container, this happens:

...and the object pops up about 100m away from me. And jumps 15km away as soon as I try to warp, despite not moving anywhere that fast.

Another issue (but with no serious gameplay effect) is that Kerbal RCS effects are gone - also back if I remove DR.

The only mods in this install are DR, KAS, MM and HyperEdit. The last one is not included in my main install, and the issues are present there as well.

Finally, full log file. Sorry if this is a known issue and/or actually a KAS thing that's just triggered by DR.

EDIT: oh, now I went to the KAS thread and noticed mentions of the issue.

Ok, more or less in order, the jumping away during warping itself I think you can safely ignore. I've been noticing that a long time now but didn't connect it with DRE and since the object returns to its proper distance when I come off rails it seems a nuisance but one I've ignored. I'll see if I can repro it and try to figure out what causes it though. However, that's WITHOUT KAS that I've seen that. And I take it the object shouldn't be spawning 100m away. (it should be attached to the Kerbal right?) So something else might be happening to you and maybe it's not safe. I'll look into it.

When you say Kerbal RCS, you mean actual Kerbals on EVA right? And they otherwise behave normally?

Can you point me at some post links for KAS discussing this or reporting it? And did they have DRE as well? (preferably NON-Linux; if this is isolated to Linux it's really going to be a PITA for me to troubleshoot since I'm not able to test in that environment right now)

What I think is happening is this: DRE is trying to initialize certain things when parts load in for the first time. (during Awake and during Start). KSP / Unity can easily have that process halted if errors occur in any plugin at that time so other plugins that need to initialize after that might not be able to. Cascade failure basically. And if I can't replicate it in Windows I'm not sure what I can do about it

(any other KAS users that can confirm that this problem does or does not exist in Windows?)

[ModZero]

And I take it the object shouldn't be spawning 100m away. (it should be attached to the Kerbal right?)

Yup.

When you say Kerbal RCS, you mean actual Kerbals on EVA right?

Yes.

And they otherwise behave normally?

They seem fine - I feel like the thrusters are slightly too powerful, but that's probably just me seeing things after I went specifically bug hunting.

Can you point me at some post links for KAS discussing this or reporting it?

You seem to have already found them, for example:

Oh really? More and more curiouser. I'll try the non-beta DRE and report back.

EDIT: Yep, went back to DRE 6.2.x and can use KAS containers again. Unfortunately the EL survey stakes I had in the KAS containers don't seem to want to function now. *facepalm*

I haven't noticed mentions of OS, and only as much of logs as I already pasted.

And did they have DRE as well? (preferably NON-Linux; if this is isolated to Linux it's really going to be a PITA for me to troubleshoot since I'm not able to test in that environment right now)

I can reboot to Windows (I used to play on Windows until just a few days ago, got sick of mod juggling, but Linux brings its own share of issues) and test, unless someone answers this one right away.

[ModZero]

I reproduced this on Windows (both the no-RCS-effects thing and the KAS container thing), here's the log.

EDIT: Windows 32 bit, can't see a reference in the log file to the version of KSP I'm running...

Edited November 16, 2014 by ModZero

[Drew Kerman]

FAR has a serious bug with Proc Fairings. It's corrected in git, but ferram hasn't released a new official release.

is there an earlier FAR version that can be used in the meantime to get around this issue? Or does this issue exist in previous builds as well? Or are you saying don't bother using PF until the next release? Was just about to get back to playing with all the latest versions of things installed...

[Starwaster]

I reproduced this on Windows (both the no-RCS-effects thing and the KAS container thing), here's the log.

EDIT: Windows 32 bit, can't see a reference in the log file to the version of KSP I'm running...

Did you see the PM I sent you? Is that log with or without the DLL I linked to?

[ModZero]

I totally missed it, sorry. I sent you a new DM.

[NathanKell]

Gaiiden, just download the dev version. Grab GameData from this link to the dev version (zipped) on github.

[Lukaszenko]

Since installing the last release, I can't fly my rocket with an MK1 command pod because it keeps burning up on takeoff. The temperatures climb really fast, to >1500 degrees at around 800 m/s, 25000 m, and it blows up, before even the probe core or the parachute that are in front of it. This was on the normal setting but it blows up on the easy, too. Is this right? It doesn't seem so...

A poor Kerbal had to die the first time this happened, but I forgot his name.

[Starman4308]

Since installing the last release, I can't fly my rocket with an MK1 command pod because it keeps burning up on takeoff. The temperatures climb really fast, to >1500 degrees at around 800 m/s, 25000 m, and it blows up, before even the probe core or the parachute that are in front of it. This was on the normal setting but it blows up on the easy, too. Is this right? It doesn't seem so...

A poor Kerbal had to die the first time this happened, but I forgot his name.

How fast are you ascending? There's little reason to ever be using more than 2G of acceleration until you punch through lower atmosphere, in either stock or FAR aero.

[Milkshakefiend]

Starwaster - I see you saw the problems with KAS/DRE. I was planning on filing a bug report tonight, but you're too quick! I also see you're trialling another DLL, so I assume you've narrowed down the cause of the bug. If you need another log/tester, let me know and I'll re-upload my logs. I'm using 32-bit on OS X, if that makes a difference for you.