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

[Cynthum]

Oh, my mistake then. I thought the MK1 pod had albative shielding already. Well would the info on parts tell you anything about their heat deflection and such? Thank you for your replies in advance!

[lincourtl]

Press Alt+X. You accidentally turned on trim control which is why your pod is rotating. (DREC itself imparts no force at all to anything)

Ah! I bet you're right. As soon as I read that I remembered I had been flying a plane the previous night.

I didn't think DREC itself imparted any force. I was already of the opinion that it was my own fault. I was just flummoxed why my capsules were acting like whirling dervishes on reentry.

Thanks much!

[lajoswinkler]

So much this, but I think the capsule should have RE. Nobody thinks of this mod as DR; they think of it as DRE.

Too bad D's aren't backwards, you could leave it the way it is, have an R on the capsule, and the E could be 3 lines streaking out from the back (well, top) of the capsule implying fast speed.

I know, right? Last night I was spinning and mirroring it, thinking the same thing. Our Ds are wrong. (ok, that came out wrong, lol)

Here's what I've got so far (and I like it).

(again, download them first, they're got an alpha transparent layer so you can't see much like this)

Off mode is basically a white layout of the whole thing, and on mode is plasma shell with the heat shield (D), R (KeRbal inside) and an E (turbulent flow).

I tried to go with a pictogram representation of Schlieren photography of reentry effects.

Tell me if you want more modifications. Yellow would be more appropriate for the plasma, but then the contrast between the letters and the cone is poor.

Edited October 10, 2014 by lajoswinkler

[Starwaster]

Yup, that's *exactly* the issue Ferram had, and he capped it too. Wish I'd remembered.

That said, I wrote it so density would match FAR density; what would be best is just pulling density from FAR via reflection if FAR is detected, else just pulling from stock code so density matches stock aero density on stock.

The main point is DRE's density should match the density used by the aero model.

I'll probably have to do a of quick fixes until I can take the time to sit down and do it properly and until FAR is actually exposing density. (did I read your second post right; it's not right now?)

Until then, I think what I'm going to do is cap it, and quite a bit above absolute zero or it'll really screw over non-FAR and non-RSS users. (you realize this wouldn't be a problem if Flower Child had been over RSS Jool right? Hurray for temperature curves!)

Ah! I bet you're right. As soon as I read that I remembered I had been flying a plane the previous night.

I didn't think DREC itself imparted any force. I was already of the opinion that it was my own fault. I was just flummoxed why my capsules were acting like whirling dervishes on reentry.

Thanks much!

You might also have done it if you opened up the DREC debug menu (alt+D)

In fact I've got in the habit of always pressing alt+X every time I open that menu up just in case I turned on trim. Eventually the debug menu will also be accessible through the toolbar too.

Here's what I've got so far (and I like it).

http://s17.postimg.org/3pi22c96j/DRE_off2.png

http://s1.postimg.org/ovodkoz8r/DRE_on4_2.png

(again, download them first, they're got an alpha transparent layer so you can't see much like this)

Off mode is basically a white layout of the whole thing, and on mode is plasma shell with the heat shield (D), R (KeRbal inside) and an E (turbulent flow).

I tried to go with a pictogram representation of Schlieren photography of reentry effects.

Tell me if you want more modifications. Yellow would be more appropriate for the plasma, but then the contrast between the letters and the cone is poor.

Those are looking good, I still have to get it into the game to see how it actually looks on the toolbar but that code was temporarily disabled for the 6.1 release and I've been too busy looking into the weird issue with extreme negative temperatures.

[Athlonic]

...

Here's what I've got so far (and I like it).

http://s17.postimg.org/3pi22c96j/DRE_off2.png

http://s1.postimg.org/ovodkoz8r/DRE_on4_2.png

(again, download them first, they're got an alpha transparent layer so you can't see much like this)

...

Like it a lot as well.

Here, to save everyone some time, with a "game alike" background :

And here is the background layer if you want you can put it as background layer in your PSD file (usefull for preview), just don't forget to hide it when saving your final .png (happen a lot to me ^^ )

[Starwaster]

Status update on the Jool issue.

Uhm the problem doesn't seem to be where Nathan and I were thinking it was, at least I don't see how it could be after I put as many sanity checks on it as I have and still get that error.

So I'm still rooting around.

I'm 90% probably going to push a quick and dirty hack without changing the version name shortly.

EDIT:

And, holy CRAP Athlonic, if I haven't asked you before, what the HELL is that in your avatar? Is there a full sized version somewhere? Wait have I asked you this before?

Oh and thanks for the simulated in-game icon appearance

[lajoswinkler]

Like it a lot as well.

Here, to save everyone some time, with a "game alike" background :

http://i.imgur.com/8TrhWX3.png

And here is the background layer if you want you can put it as background layer in your PSD file (usefull for preview), just don't forget to hide it when saving your final .png (happen a lot to me ^^ )

http://i.imgur.com/w4Bv4rt.png

Thanks. Here's the total preview as it would appear in the game.

Your avatar made me poop a little.

Looks like a blend of a Kerbal and 3D version of FFFUUUU.

Edited October 10, 2014 by lajoswinkler

[Athlonic]

You are welcome guys

In fact my avatar came from this :

Here is my usual avatar :

I just realized I kept my "Christmass 2013" version on this forum

[Starwaster]

You are welcome guys

In fact my avatar came from this :

http://i.imgur.com/87IEIXB.png

Here is my usual avatar :

http://i.imgur.com/Ddk9PaN.jpg

I just realized I kept my "Christmass 2013" version on this forum

Wow so that was your christmas present to us all; nightmares to guarantee none of us ever sleep ever AGAIN.

Whutta guy!

BTW, updated version. No new version, just updated the download file for 6.1. That prevents stuff like the Jool NaN bug. It safeguards the part temperature field so that it can NEVER be set to NaN. Unfortunately that only prevents it from being corrupted, it also stops the part from gaining temperature in that situation instead of correctly calculating the temperature. I just don't get what's happening though. It has to be the density/temperature issue like we were talking about before but I put in so many checks and it still happens. So, back to debugging.

[NathanKell]

I'll do the PR for density when ferram releases the next FAR (which won't be long now, there's a big cargo bay bug that needs fixing).

[Jacke]

BTW, updated version. No new version, just updated the download file for 6.1.

Starwaster, don't you think you should have changed the version number?

Anyhoo, finally getting the hang of Kerbin reentry with DR 6.1. Had to change the pressure my parachutes semi-deploy at so it's a lower altitude and thus airspeed else they get burned away. Cool!

[FlowerChild]

I'll do the PR for density when ferram releases the next FAR (which won't be long now, there's a big cargo bay bug that needs fixing).

Is the idea with this to use vessel.atmDensity when FAR isn't installed Nathan, similar to how it used to function?

Just wanting to compile a version locally so I can continue testing BTSM in the meantime.

BTW: I also wanted to put out a specific thanks for the following:

				if(hit.rigidbody != null && hit.collider != part.collider && hit.collider.attachedRigidbody != part.Rigidbody) 

Was funny, as I just went into the game to test heat on welded parts as I was going to propose a similar change to the above so that heat would be applied to them, and much to my confusion found out they were already working right

Edited October 10, 2014 by FlowerChild

[Starwaster]

Starwaster, don't you think you should have changed the version number?

Maybe. It's just a short term fix for Flowerchild's bug. I'll probably do another tonight that does update the version #

Is the idea with this to use vessel.atmDensity when FAR isn't installed Nathan, similar to how it used to function?

Just wanting to compile a version locally so I can continue testing BTSM in the meantime.

like I said above I didn't update the version but if you redownload, it's temporarily fixed and that's what it does. Just uses vessel.atmDensity

[NathanKell]

Also, just a note in case it wasn't clear.

The way DRE handles burning up a parachute is by cutting it.

You will not see a heatmeter, and (because I forgot) you will not get a log message. It will just happen when the parachute is deployed in a shockwave where shockwave temperature * density > parachute part max temperature * multiplier.

[FlowerChild]

like I said above I didn't update the version but if you redownload, it's temporarily fixed and that's what it does. Just uses vessel.atmDensity

Ah, ok, I misunderstood your post then as I thought you were saying that you were just bounds checking on absolute zero in order to prevent the NaN's but this was causing no reentry heat to occur in those situations.

From the current code on GitHub, I'm also seeing this

density = (float)(part.vessel.staticPressure * 101325 / (287.058 * (part.vessel.flightIntegrator.getExternalTemperature() + CTOK)));

Whereas locally I have replaced it with this:

density = (float)vessel.atmDensity;

for testing purposes, which as far as I can tell reproduces the old behavior.

Edited October 10, 2014 by FlowerChild

[Starwaster]

Ah, ok, I misunderstood your post then as I thought you were saying that you were just bounds checking on absolute zero in order to prevent the NaN's but this was causing no reentry heat to occur in those situations.

From the current code on GitHub, I'm also seeing this

density = (float)(part.vessel.staticPressure * 101325 / (287.058 * (part.vessel.flightIntegrator.getExternalTemperature() + CTOK)));

Whereas locally I have replaced it with this:

density = (float)vessel.atmDensity;

for testing purposes, which as far as I can tell reproduces the old behavior.

Crap, I didn't push the code changes to GitHub.

My bad.

Basically I did this:

            density = (float)FlightGlobals.ActiveVessel.atmDensity;

So heating is currently working the way it was previously.

and this

            if (part.temperature < -CTOK || float.IsNaN (part.temperature)) // clamp to Absolute Zero
                part.temperature = -CTOK;

So if anything else EVER writes NaN to .temperature, it'll keep it from being corrupted (because at that point you're reloading that ship. Temperature is broken until you do). If the problem resolves itself then the ship will start experiencing heating again.

I'm currently trying to figure why v6.0's density code is messed up. By my reckoning, that code should only cause NaN if temperature were -273.15 (which would result in divide by zero) or if temp were lower than that, causing density to be negative, which to my understanding would also cause Math.Pow to throw NaN...

Previously I'd tried this, and unless staticPressure is also doing something screwy in stock, it should have worked.

            density = (float)((part.vessel.staticPressure * 101325.0) / (287.058 * (Math.Max(-160.0, (double)(part.vessel.flightIntegrator.getExternalTemperature() + CTOK)))));

-160 is a bit arbitrary and was chosen on the grounds that it was the lowest temperature that could reasonably be expected in any of the stock planets with atmospheres. (IRL, Titan and I think Mars might go lower but I thought this would do for now)

[FlowerChild]

            density = (float)FlightGlobals.ActiveVessel.atmDensity;

Cool cool. Thanks for that. I'm currently testing my Jool aerobrake with your latest version and everything seems to be working as intended.

Just as a small note about the above though: you might want to consider changing it to the part's vessel rather than the active one, as it's possible to have multiple vessels within physics range (particularly shortly after separation), with some in the atmosphere or not, or at varying altitudes. Might generate some weird effects to have them all drawing pressure from the active vessel then

[Starwaster]

Cool cool. Thanks for that. I'm currently testing my Jool aerobrake with your latest version and everything seems to be working as intended.

Just as a small note about the above though: you might want to consider changing it to the part's vessel rather than the active one, as it's possible to have multiple vessels within physics range (particularly shortly after separation), with some in the atmosphere or not, or at varying altitudes. Might generate some weird effects to have them all drawing pressure from the active vessel then

Moops good point.

Edit: Why the hell does Siri think that 'moops' is a word??? DYAC.

Edited October 10, 2014 by Starwaster

[Beale]

Also, just a note in case it wasn't clear.

The way DRE handles burning up a parachute is by cutting it.

You will not see a heatmeter, and (because I forgot) you will not get a log message. It will just happen when the parachute is deployed in a shockwave where shockwave temperature * density > parachute part max temperature * multiplier.

I'm experiencing a few bugs in this latest release:

1. On the parachutes, can they be damaged on ascent? (Even a gentle one).

I've returned from orbit twice, deployed the parachutes and... nope, it's already in the "cut" state, despite no way the parachute was exposed on descent (behind capsule heatshield). This never happened before.

Edit: It deploys right under about 150m/s, but that's really quite delicate, when terminal velocity gets that low, I could already be slamming into a mountain

2. G-limits, despite sticking to the default settings, my crew members keep getting killed by G-forces (I know it's accurate, but I've always just avoided that corner of realism).

	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)

Really great mod, essential to me. But especially the parachute issue is putting a dampener on things.

Edited October 10, 2014 by Beale

[Gaugeforever]

On number 1, upgrading from 6.0 to 6.1 solved that issue for me. I didn't notice he snuck in a quick bug fix release and was still using the 6.0 .25 release.

[lajoswinkler]

Stock parachutes (no RealChute installed) don't behave correctly for me, and I think DRE might be the problem. They don't deploy upon staging, and when I manually deploy them using a right click, they become empty. No cord, no fabric. Not even deploying sound.

I've noticed the whole reentry plasma phase is a lot longer now. Whether it's because of DRE or simply v0.25 KSP, I don't know, but I like it. If only the parachutes would work.

[Starwaster]

I'm experiencing a few bugs in this latest release:

1. On the parachutes, can they be damaged on ascent? (Even a gentle one).

I've returned from orbit twice, deployed the parachutes and... nope, it's already in the "cut" state, despite no way the parachute was exposed on descent (behind capsule heatshield). This never happened before.

Edit: It deploys right under about 150m/s, but that's really quite delicate, when terminal velocity gets that low, I could already be slamming into a mountain

If you're having to wait that long then you missed an update. That said however, deploying into the plasma outside the ship will burn them no matter if the chute part is shielded or not. The canopy is too far back to be protected. If your naked canopy is flapping in a fiery breeze then it will not be happy.

Stock parachutes (no RealChute installed) don't behave correctly for me, and I think DRE might be the problem. They don't deploy upon staging, and when I manually deploy them using a right click, they become empty. No cord, no fabric. Not even deploying sound.

I've noticed the whole reentry plasma phase is a lot longer now. Whether it's because of DRE or simply v0.25 KSP, I don't know, but I like it. If only the parachutes would work.

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?

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)

On number 1, upgrading from 6.0 to 6.1 solved that issue for me. I didn't notice he snuck in a quick bug fix release and was still using the 6.0 .25 release.

This.

Also, hope to put 6.2 out tonight. It will reintroduce the realistic densities that 6.0 had only different planets will have different densities, even without FAR. (Nathan, I'll be pushing the current code for that to Github soon so we can plan around that)

[Jacke]

Stock parachutes (no RealChute installed) don't behave correctly for me, and I think DRE might be the problem. They don't deploy upon staging, and when I manually deploy them using a right click, they become empty. No cord, no fabric. Not even deploying sound.

I've noticed the whole reentry plasma phase is a lot longer now. Whether it's because of DRE or simply v0.25 KSP, I don't know, but I like it. If only the parachutes would work.

I've been playing with Deadly Reentry 6.1 for a while with Kerbin reentries. It's working for me, but it's much deadlier than in version 5.2 and wonderfully so.

You have to reenter much more shallowly, with a higher periapsis--or pack a whole lot of delta-V to slow down to well under orbital speeds before getting too deep, or your spacecraft will be destroyed by reentry heating. And you can't deploy your parachutes when the airstream is too hot or they will be destroyed, which will show up as them being cut (parachute icon in staging goes red). With a bit of testing I figured it out.

[FlowerChild]

Also, hope to put 6.2 out tonight. It will reintroduce the realistic densities that 6.0 had only different planets will have different densities, even without FAR. (Nathan, I'll be pushing the current code for that to Github soon so we can plan around that)

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.

[Gaugeforever]

Seriously, people in this thread need to simply read ONE PAGE of replies to see multiple explanations about updating to 6.1 for the stock parachutes. I can see why modders get angry.