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

[Starwaster]

My specific complaint would be that the temperature from my tests seems to be calculated as the maximum of the ambient and your airspeed in m/s. Meaning if the ambient is about 300K and you're going 310 m/s it will be 310K, and if you're going 298 m/s it will be 300K. Rather than taking into account any kind of friction effects, or shock compression. The ambient temperature itself seems to be reasonable, it drops off nicely with altitude and varies at sea level with latitude.

Also, is the pressure not exposed directly as a value? I can't be sure but isn't there a science part that gives this value? And also, by setting the aerodynamicheatproductionfactor to 0, you should be able to get the "raw" ambient temperature, and use that as basis for calculations instead.

Shock compression temperature in Kelvin = your velocity in meters per second, yes. That is how you find the temperature of the shockwave.

Strange but true.

Ambient air temperature is mainly relevant in determining atmospheric density which is used in determining how much of the heat generated actually makes it through.

Air temperature doesn't really play a part in determining reentry heating. If you slam into a mass of air at 11 km/s, the result is largely going to be the same regardless of whether it's cold air or hot air: You're compressing the air and that heats it up. It's that compression that causes the heating and at 11,000 meters per second a few tens or even hundreds of degrees air temperature won't make a difference.

Additional: Okay I forgot that DR comes with it's own heatshield but there's the next problem. I can attach the heatshield and the decouplers, but I can't attach anything to them :/

Edit: Module Manager says: 13 errors related to Gamedata/DeadlyReentry/DeadlyReentry.cfg

Crap, that sounds like I missed the stack nodes if you can't attach. I'll get that fixed ASAP.

Module Manager errors: You can probably ignore them. The most likely cause is that some conditional clauses in the config file couldn't be met. Submit an output_log.txt or player.log (if on Mac or Linux) and I'll take a look at them.

[hahawin]

Additional: Okay I forgot that DR comes with it's own heatshield but there's the next problem. I can attach the heatshield and the decouplers, but I can't attach anything to them :/

Edit: Module Manager says: 13 errors related to Gamedata/DeadlyReentry/DeadlyReentry.cfg

I'm having the same problem with the heatshields and the decouplers: I cant attach anything to them.

EDIT: nvm, looks like StarWaster is already aware (must remember to refresh before posting)

Edited May 12, 2015 by hahawin

[Snafu225]

...snip...

Crap, that sounds like I missed the stack nodes if you can't attach. I'll get that fixed ASAP.

Module Manager errors: You can probably ignore them. The most likely cause is that some conditional clauses in the config file couldn't be met. Submit an output_log.txt or player.log (if on Mac or Linux) and I'll take a look at them.

"good" to know it's not another fault on my side... had a lot of them recently

Already posted this one earlier but here you go

https://www.dropbox.com/s/rjaumwwm2lw4nzv/output_log.txt?dl=0

[Starwaster]

Ok, I pushed a patch release and updated the version number to 7.0.1

Also corrected links in OP and my 7.0 post.

This fixes the problems with the stack nodes.

the nullref error I'm not sure about why that's still happening as I put code in place to prevent that. (pretty sure it's the cached FlightIntegrator as nothing else in there should even be capable of causing that error and I haven't seen it myself since I put that code in place)

[diomedea]

Starwaster, can you please state exactly the purpose of ModularFlightIntegrator?

Can't see much in the OP or with the package, my take is it allows FAR and DRE to go together, but can't say if it is required even in case FAR isn't installed.

[taniwha]

diomedea: It is required. It is a replacement for the stock FlightIntegrator and it is designed to allow multiple mods to hook in.

[diomedea]

diomedea: It is required. It is a replacement for the stock FlightIntegrator and it is designed to allow multiple mods to hook in.

Thanks. Clear and spot on.

[DuxDucisHodiernus]

Whats the difference between the current vanilla reentry mechanics and this?

[Starwaster]

Whats the difference between the current vanilla reentry mechanics and this?

Mainly that only a portion of a part's mass is used when applying heat. That's the skin. (or hull if you prefer that term)

If one thing has more mass than another (and all other factors are equal) then the more massive thing will heat up more slowly. This is a large part of why stock reentries feel weak.

The other reasons are

• Slower reentry speed over Kerbin than over Earth.
  
• Less time spent in reentry
  

To correct these two problems, convectiveFactor was increased to 50. This means things are subject to convective heating 50x faster. (you could also think of it as 50x the heat, but in practice, part temperature and skin temperature act to limit this so that things will heat up only until they reach equilibrium or explode)

Also, the amount of heat produced in reentry has been increased so that it is comparable to an Earth reentry

radiationFactor was also increased to 50 so that it's still possible to reach thermal equilibrium after convectiveFactor was increased.

Also: OP was updated to remove any confusion as to what to do with ModularFlightIntegrator.

[Snafu225]

Okay Starwaster, there seems to be another Issue. The stock toolbar icon seems to duplicate on scence change, just like IRs and PlanetShines did.

[Starwaster]

Okay Starwaster, there seems to be another Issue. The stock toolbar icon seems to duplicate on scence change, just like IRs and PlanetShines did.

I can't reproduce that. Does it only do it sometimes?

Are you using Windows, Mac or Linux?

Log files too and repro directions as to what you're doing when it happens

[linuxgurugamer]

Great! Couldn't wait for it.

As I remember, settings for crew kill by over-G were there in previous version but by default they were close to the infinity. Where are they now, I can't find them? Are they realistic now?

Have some suggestions:

1. Could you make burn effects and explosions on reentry proportional to a part's mass? Because every time I see a fire and explosion on reentry that is bigger than the vessel itself I am close to a heart strike shouting out: "Oh my, Kouston, we have lost a whole god damn bunch of a ... never mind, it was just a tiny piece of a solar panel that exploded like a barrel of kerosene." The most exciting it gets when happens in cascade

2. May be someday breaking and exploding parts would inflict damage on their neighbors, at least the parts they are attached to? Because now you can place an antennae on a crew pod and say: "I don't care if it burns on reentry". But it should at least kill the ablation to make it realistic so noone wanted parts to get ripped off the vessel just like IRL. If you remember Columbia accident, a piece of foam that hit the ablation was enough to turn the reentry into a total disaster.

Also big explosions could cause unwanted momentum changes.

All that should really make us decouple everything we don't need before reentry.

The Columbia disaster occurred because a piece of foam punched through the ablation to the wing surface below, so that the wing surface was directly exposed to the heating. It quickly burned/melted through into the interior of the wing, and kept building and enlarging until the ship was uncontrollable.

They saw that during the initial part of the reentry, the rudder was compensating for the excess drag on the wing, and kept doing so until the excess drag was too much to compensate for.

[Snafu225]

I can't reproduce that. Does it only do it sometimes?

Are you using Windows, Mac or Linux?

Log files too and repro directions as to what you're doing when it happens

Sorry about the false alarm.

Seemed to be a one time bug, as I can't reproduce it anymore.

Using Windows btw.

[Starwaster]

Sorry about the false alarm.

Seemed to be a one time bug, as I can't reproduce it anymore.

Using Windows btw.

Well I messaged Planetshine's developer to ask him about it since he had that problem.

[Enceos]

ModuleManager found something:

output_log.txt

[Jovus]

Something that's unclear from the OP: does Deadly Reentry make use of the stock heat shields? Does it have its own instead? Do we need to pick up a 3rd-party heat shield pack?

[Snafu225]

It comes with it's own heatshields, but looking at the mm.cfg that comes with it, it looks like the stock ones should work aswell.

Edited May 12, 2015 by Snafu225

[A_Burnt_Rodent]

Are ProceduralParts heat shields supported now?

[Starwaster]

ModuleManager found something:

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

output_log.txt

Ah I see where that's coming from. That will affect stock shields. Not sure what the exact effect is; probably they won't burn as much shielding as they should

Replace your DeadlyReentry.cfg file if you use them. (link: DeadlyReentry.cfg)

Something that's unclear from the OP: does Deadly Reentry make use of the stock heat shields? Does it have its own instead? Do we need to pick up a 3rd-party heat shield pack?

It patches the stock shields so that they work properly with DRE. Grab the latest version from the link in my reply to Enceos

Are ProceduralParts heat shields supported now?

No idea, I'll leave it to them to do.

[rhoark]

Thanks Starwaster (et al). What would you think about supporting multiple skins on a part (eg, dorsal/ventral)?

I figure this could be done with multiple instances of ModuleAeroReentry on a part. It would just need each instance to carry a vector and maximum deflection to check against in _GetBodyArea and _GetSunArea and a new _GetAirstreamArea in similar fashion. Also scale part.exposedArea and part.radiativeArea by maxDeflection/360.

[Jovus]

It comes with it's own heatshields, but looking at the mm.cfg that comes with it, it looks like the stock ones should work aswell.

...so...so...so I can delete the stock heat shields? Please?

(The shields themselves are decently pretty, but the way they attach to the rocket looks like crap.)

[Enceos]

@Starwaster Your shields use AblativeShielding and stock shields still use Ablator. Maybe unifying the resources would a sleeker approach? Stock heatshields still have their maxTemp = 3400, which lets people use them with zero ablator and be fine.

Stock shields use the new shader by RoverDude, which makes them darker with the level of ablation. It's pretty cool.

Edited May 12, 2015 by Enceos

[Adamantium9001]

Thanks Starwaster (et al). What would you think about supporting multiple skins on a part (eg, dorsal/ventral)?

I figure this could be done with multiple instances of ModuleAeroReentry on a part. It would just need each instance to carry a vector and maximum deflection to check against in _GetBodyArea and _GetSunArea and a new _GetAirstreamArea in similar fashion. Also scale part.exposedArea and part.radiativeArea by maxDeflection/360.

It's not quite the same thing, but I'm pretty sure I saw some discussion several pages back about using MM to add ablative shielding to the underside of wings (or something like that). Don't know if it's planned, though, and I could be thinking of the wrong thread entirely. What I'm completely sure about is that I'm strongly in favour of it!

[Cerebrate]

@Starwaster Your shields use AblativeShielding and stock shields still use Ablator. Maybe unifying the resources would a sleeker approach?

I second that thought; even if you only plan on using one set of shields, it'd make life easier for mods, scripts, etc., that want to monitor/display shield-remaining.

-c

[Starwaster]

Thanks Starwaster (et al). What would you think about supporting multiple skins on a part (eg, dorsal/ventral)?

I figure this could be done with multiple instances of ModuleAeroReentry on a part. It would just need each instance to carry a vector and maximum deflection to check against in _GetBodyArea and _GetSunArea and a new _GetAirstreamArea in similar fashion. Also scale part.exposedArea and part.radiativeArea by maxDeflection/360.

...so...so...so I can delete the stock heat shields? Please?

http://s2.favim.com/orig/37/aaawwh-adorable-big-eyes-cat-cute-Favim.com-301185.jpg

(The shields themselves are decently pretty, but the way they attach to the rocket looks like crap.)

You can probably get away with deleting them if you want. DRE certainly has no dependency on them. Any ill effects are on you though!

@Starwaster Your shields use AblativeShielding and stock shields still use Ablator. Maybe unifying the resources would a sleeker approach?

I have no idea what 'unifying' them entails. I'm inclined to leave the stock resource alone however unless there's some compelling reason otherwise. (deleting a resource that could potentially exist in someone's save file is a very BAD thing. We're talking 'cross the streams' bad)

Stock heatshields still have their maxTemp = 3400, which lets people use them with zero ablator and be fine.

Yes, that does sound like a problem. I'd looked briefly at the maxTemp value but doing anything about it slipped under the radar. FYI, it's only 400 degrees hotter than Apollo heatshields got so the value itself isn't a problem. What is a problem is whether it's possible in a stock environment to reach that temperature. Even with Deadly Reentry. So I will be looking into that.

Stock shields use the new shader by RoverDude, which makes them darker with the level of ablation. It's pretty cool.

Yes, I might try to do something like that but it's not a priority ATM.

It's not quite the same thing, but I'm pretty sure I saw some discussion several pages back about using MM to add ablative shielding to the underside of wings (or something like that). Don't know if it's planned, though, and I could be thinking of the wrong thread entirely. What I'm completely sure about is that I'm strongly in favour of it!

What you're probably thinking of was a proposal by B9 to assign differing levels of protection to a part depending on what side of it was oriented into the airflow. It was an interesting proposal and I had intended to do something about working it in, but basically ended up freezing the beta development where I left it and there wasn't time to implement his suggestion. If it turns out that there are still a significant number of hangers on to KSP 0.90 / DRE 6.5 then I'll probably go back and put the last beta into an official 0.90 release and possibly look into implementing B9's suggestion for that version. But that assumes a lot more free time than I have right now.

(though it wouldn't be a huge stretch to do so after having implemented it for DRE 7.0 as the code would be universal)

EDIT: Those concerned about having two ablative resources: On the subject of heat shield resources, that's not hard coded you know. Anyone could put out a parts pack with heat shields configured for their own custom resource. You could conceivably use ElectricCharge as a resource, though that's probably harder now than it was pre DRE 7.0 (because the new heat shield looks at resource density, which EC doesn't have so you'd basically end up with zero pyrolysis)

Edited May 12, 2015 by Starwaster