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

[futrtrubl]

Heh, I've had the exact opposite problem, with DR as long as I was de-orbiting sensibly, I never had a problem. With stock half the time the capsule flips around and explodes, regardless of my entry profile.

I honestly can't wait to drop it in favour of DR.

For those with spacecraft with stock heatshields flipping on reentry check out the stock bug fix thread that's stickied in this forum. It has a fix for that, which is caused by the heatshields being physicsless parts.

[Prototype516]

Maybe "Deadly Ferrem Entry Aerodynamics Research" bit of a mouth full but making the acronym "Deadly F.E.A.R." or "D-FEAR" is worth it. Kind of like Strategic Homeland Intervention, Enforcement and Logistics Division.

but no having modular... mods... is better because you can create the game you want because someone might not... Oh wait the default heating sucks and its there now so I suppose you might as well combined the two.

Although the stock aerodynamics are not terrible now in some respects and are a lot more forgiving so someone might want to just use Deadly Re-entry.

This sounds awesome. I'm all for it.

[Citizen247]

For those with spacecraft with stock heatshields flipping on reentry check out the stock bug fix thread that's stickied in this forum. It has a fix for that, which is caused by the heatshields being physicsless parts.

Ah, I must have missed that, thanks.

[sumghai]

Starwaster, got a couple of questions for you:

The heat shield from my SDHI Service Module System add-on currently supports DRE via ModuleHeatShield and the AblativeShielding resource. However, KSP 1.0 introduced ModuleAblator and the corresponding Ablator resource.

How would I go about configuring my parts to support DRE, while using the stock ModuleAblator as a fallback in case the user doesn't have DRE? I'm asking because I'm not sure how DRE will interact with the stock reentry heating system, or whether it would completely replace it hook, line and sinker (in which case my patch will basically have to dynamically strip out the ModuleAblator stuff).

[Starwaster]

Starwaster, got a couple of questions for you:

The heat shield from my SDHI Service Module System add-on currently supports DRE via ModuleHeatShield and the AblativeShielding resource. However, KSP 1.0 introduced ModuleAblator and the corresponding Ablator resource.

How would I go about configuring my parts to support DRE, while using the stock ModuleAblator as a fallback in case the user doesn't have DRE? I'm asking because I'm not sure how DRE will interact with the stock reentry heating system, or whether it would completely replace it hook, line and sinker (in which case my patch will basically have to dynamically strip out the ModuleAblator stuff).

Look at the stock ModuleAblator for an example. The new DRE ModuleHeatShield will use the same parameters in the same way

The resource AblativeShielding will be retained. It may or may not keep the same properties as Ablator resource. (it will initially with an eye to changing it if deemed necessary). So you can use either one. (that way you should be covered seamlessly)

One caveat to the above is that DRE (as mentioned previously) will add a new temperature category: skinTemperature which will use only a portion of the part's thermal mass. (that lets me heat the outer surface up faster than usual). For some reason that I havent identified, doing things that way results in slower ablation resource consumption so heat shields will need to have lossConst = 10 added to them. (the number can be tweaked to produce faster or slower ablation consumption)

That's all that affects SDHI.

As a side note, ModuleHeatShield will no longer be used for space plane style heat shields. Instead, thermalMassModifier and emissiveConstant can achieve the same result as the reflection property in older versions of ModuleHeatShield

Starwaster, I slapped together something that works with the stock heating last night and released it, but I am not sure about a couple of things.

CoLOffset and CoPOffset. These seem to be to be tied to the geometry of the shields, and last night I just set them to the same values as the stock shields. What are they?

Also, other than the ablator resource itself, I have no idea how the new stock part modules for heating work or what I should set these to.

Center of Lift / Center of Pressure (I think; I saw some mention of this in testing and they're probably pretty self explanatory but you might want to ask Nathan if you're unsure)

Just out of curiosity, but what does the new version of this mod brings to the table? The new stock thermo dynamics seem pretty impressive and unforgiving.

I already had some problems with unprotected re-entry, and even things blowing up during launch due to heat =O

During re-entry I had a pretty nervous time trying to keep my engine pointed front to absorb the heat, while if almost turning the vessel would quickly blow.

If you find stock reentry heating adequate then that's good, but as others have said, personally I found it underwhelming and there are definite issues in it that need correcting and so DRE needed updating.

The specific issues I have with it is that for any given amount of flux, you're having to apply that to the entire thermal mass of a part, which makes no sense. There's no concept of failure for burn through, you have to raise the temperature for the entire part to its destruction limit and overcoming thermal mass also means RESOURCE mass as well. The system as designed is pretty realistic but for that problem. The source of its convection heating BTW is the same source as I used for the latest DRE betas for KSP 0.90 which is an FAA document that contains an emperical formula for determining heat. (though the formula also includes radiant flux contribution so it wasn't pure convection). Though, my implementation was more simplistic due to the lack of heat flux in KSP 0.90. (i.e. 'temperaturing' rather than heating, as I like to put it)

Edited April 30, 2015 by sumghai
Merged on request :)

[jofwu]

The specific issues I have with it is that for any given amount of flux, you're having to apply that to the entire thermal mass of a part, which makes no sense.

For anybody who doesn't understand what he's talking about: all objects have a "specific heat" value, which tells how much energy you need to increase the object's temperature one degree per unit mass of the object.

So maybe, for example, it takes 100 Joules of energy to increase a 1kg object's temperature by 2 Kelvin. It has a specific heat of 100/2= 50 J/K/kg. It takes 50 J to warm up 1kg by 1 degree. But what if we have a part made of this material which is 10kg? It will take ten times more energy (500 J) to heat the object by 1 degree. This should be fairly intuitive.

When KSP calculates part temperatures it uses the FULL mass of the part. The problem is that damage from reentry heating doesn't work this way. You don't have to heat up the entire pod to a high temperature for it to blow up. You just have to heat up one little corner on the outside, and when it fails it will take more out with it. Reentry failure is generally an issue of local (small area) damage. Consider how Space Shuttle Columbia completely disintegrated because of a tiny bit of damage on one wing. The shuttle didn't fail because the entire shuttle got super hot. It didn't fail because the entire wing got super hot. It failed because one little exposed corner got too hot. In that case, you aren't interested in the mass of the full "part." Just the mass of this one little area on the surface.

Edited April 30, 2015 by sumghai
Fixed quote reference :)

[Clythoris]

For anybody who doesn't understand what he's talking about: all objects have a "specific heat" value, which tells how much energy you need to increase the object's temperature one degree per unit mass of the object.

So maybe, for example, it takes 100 Joules of energy to increase a 1kg object's temperature by 2 Kelvin. It has a specific heat of 100/2= 50 J/K/kg. It takes 50 J to warm up 1kg by 1 degree. But what if we have a part made of this material which is 10kg? It will take ten times more energy (500 J) to heat the object by 1 degree. This should be fairly intuitive.

When KSP calculates part temperatures it uses the FULL mass of the part. The problem is that damage from reentry heating doesn't work this way. You don't have to heat up the entire pod to a high temperature for it to blow up. You just have to heat up one little corner on the outside, and when it fails it will take more out with it. Reentry failure is generally an issue of local (small area) damage. Consider how Space Shuttle Columbia completely disintegrated because of a tiny bit of damage on one wing. The shuttle didn't fail because the entire shuttle got super hot. It didn't fail because the entire wing got super hot. It failed because one little exposed corner got too hot. In that case, you aren't interested in the mass of the full "part." Just the mass of this one little area on the surface.

Thank you, I was completely lost with what Starwaster "said.

[sumghai]

Look at the stock ModuleAblator for an example. The new DRE ModuleHeatShield will use the same parameters in the same way

The resource AblativeShielding will be retained. It may or may not keep the same properties as Ablator resource. (it will initially with an eye to changing it if deemed necessary). So you can use either one. (that way you should be covered seamlessly)

One caveat to the above is that DRE (as mentioned previously) will add a new temperature category: skinTemperature which will use only a portion of the part's thermal mass. (that lets me heat the outer surface up faster than usual). For some reason that I havent identified, doing things that way results in slower ablation resource consumption so heat shields will need to have lossConst = 10 added to them. (the number can be tweaked to produce faster or slower ablation consumption)

That's all that affects SDHI.

Ah, excellent - thanks for the clarification. My strategy for SDHI will be as follows:

- The SDHI heatshield CFG will by default use the stock ModuleAblator PartModule and Ablator resource.

- If DRE is installed, the MM patch will first strip out ModuleAblator and Ablator, before replacing them with DRE's ModuleHeatShield and AblativeShielding resource.

This will allow me to fine the performance of the part for both re-entry heating models separately

[Temeter]

For anybody who doesn't understand what he's talking about: all objects have a "specific heat" value, which tells how much energy you need to increase the object's temperature one degree per unit mass of the object.

So maybe, for example, it takes 100 Joules of energy to increase a 1kg object's temperature by 2 Kelvin. It has a specific heat of 100/2= 50 J/K/kg. It takes 50 J to warm up 1kg by 1 degree. But what if we have a part made of this material which is 10kg? It will take ten times more energy (500 J) to heat the object by 1 degree. This should be fairly intuitive.

When KSP calculates part temperatures it uses the FULL mass of the part. The problem is that damage from reentry heating doesn't work this way. You don't have to heat up the entire pod to a high temperature for it to blow up. You just have to heat up one little corner on the outside, and when it fails it will take more out with it. Reentry failure is generally an issue of local (small area) damage. Consider how Space Shuttle Columbia completely disintegrated because of a tiny bit of damage on one wing. The shuttle didn't fail because the entire shuttle got super hot. It didn't fail because the entire wing got super hot. It failed because one little exposed corner got too hot. In that case, you aren't interested in the mass of the full "part." Just the mass of this one little area on the surface.

Sounds like it's one of the attempts of squad to keep the game-mechanics, while derived from a realistic base, easy to understand and simple. The heating of a full part is much easier to keep track of and more static than some system of a certain spots/angle heating differently.

[Starwaster]

Sounds like it's one of the attempts of squad to keep the game-mechanics, while derived from a realistic base, easy to understand and simple. The heating of a full part is much easier to keep track of and more static than some system of a certain spots/angle heating differently.

No, it was just oversight. I don't think it really occurred to anyone.

[etheoma]

For those with spacecraft with stock heatshields flipping on reentry check out the stock bug fix thread that's stickied in this forum. It has a fix for that, which is caused by the heatshields being physicsless parts.

Oh yeah the heat shields are basically massless lulz so stupid...

[Starwaster]

Update:

Ok so progress; I'm working on getting my existing code functioning with the Modular FlightIntegrator that Sarbian set up for ferram4 and I. It's a little slow going but I'm getting there.

[LostOblivion]

No rush, Starwaster. :-)

[Friend Bear]

Posting this here and in real chute cause it concerns both.

Deadly Reentry forces you to wait until you are at a speed of 350m/s to deploy. Have people found this realistic or should I change the value?

I am using realchute but am wondering if they have a chute or if the stock red high altitude chute does not follow the same rules so I can first slow down the vehicle.

---

If you wanna add to a discussion (brief) of what you do to reenter, add to my post over there:

http://forum.kerbalspaceprogram.com/threads/57988-1-0-x-Wenkel-Corporation-RealChute-Parachute-Systems-v1-3-2-2-1-05-15?p=1894291&posted=1#post1894291

Edited May 2, 2015 by Friend Bear

[Shaman]

First...props to all the modders. I've never seen modders so dedicated to getting their work updated so quickly for the rest of the player community like myself who just don't have the programming skillz. I rely heavily on you guys to make my gaming experience even more awesome!

I love KSP and I understand why they are trying to find the balance between realism and ease of play to reach a broader player base. I just fall on the realism side of it. I'm just glad Starwaster has provided us with a more realistic version of the game and extremely glad KSP made the game so easy to mod.

Keep up the great work! I eagerly await the release of DR, but no good mod before its time!

[lincourtl]

Deadly Reentry forces you to wait until you are at a speed of 350m/s to deploy. Have people found this realistic or should I change the value?

Considering that supersonic parachutes are a highly specialized thing, I think it's a fairly realistic bordering on science fictional (which is not necessarily bad). Also, due to the scale height of the stock KSP atmos, the interval between shock heating and subsonic is pretty brief. I don't particularly find deploying any sort of slow-me-down device while heating is still occurring particularly realistic.

BTW -- Good powerpoint about supersonic parachute design: https://solarsystem.nasa.gov/docs/11%20-%20Supersonic%20parachutes%20Lingard.pdf

[Friend Bear]

I like being informed. Thanks for the info!

Yeah it feels more science-fictiony but I know little about any projects in the area. Borderline realistic is alright to me. I just cant handle mods that are completely so since I like to stay in the realm of reality.

The spoilers idea still holds well.

And thanks for the link! Pretty sweet.

[lincourtl]

I like being informed. Thanks for the info!

Yeah it feels more science-fictiony but I know little about any projects in the area. Borderline realistic is alright to me. I just cant handle mods that are completely so since I like to stay in the realm of reality.

The spoilers idea still holds well.

And thanks for the link! Pretty sweet.

Because of KSP's conceits to gameplay (1/10 size Earth, entire Kerbolar system would fit almost inside Venusian orbit, super-powered jets and ion thrusters, little green guys with no obvious civilization yet an advanced space program, etc.) I think a little science fiction-y is just fine. Apart from the RSS/RO crowd, I think what most of the mo'-realism community wants is hard sf'ish versus fantasy space opera. At least that's what I'm looking for.

[Friend Bear]

And I completely agree. But I like the idea of it revolving around the kerbin system and not a replica of our own real life system. If that means a mod that just increases all variables in the kerbin system for difficulty/realism purposes...awesome.

Otherwise, I like the realism aspect because it is interesting to think of kerbin as just another system in another universe with the same physical limitations that hinder us. Thats why too much scifi is something I avoid.

[lincourtl]

And I completely agree. But I like the idea of it revolving around the kerbin system and not a replica of our own real life system. If that means a mod that just increases all variables in the kerbin system for difficulty/realism purposes...awesome.

Otherwise, I like the realism aspect because it is interesting to think of kerbin as just another system in another universe with the same physical limitations that hinder us. Thats why too much scifi is something I avoid.

Well, that's what I was trying to say. KSP is by its nature science fictional, but I like it on the hard sf side of the spectrum versus fantasy space opera like Star Trek which is why I seek out the mo' realism mods but haven't yet gone the full RSS/RO route.

[Starwaster]

Posting this here and in real chute cause it concerns both.

Deadly Reentry forces you to wait until you are at a speed of 350m/s to deploy. Have people found this realistic or should I change the value?

I am using realchute but am wondering if they have a chute or if the stock red high altitude chute does not follow the same rules so I can first slow down the vehicle.

---

If you wanna add to a discussion (brief) of what you do to reenter, add to my post over there:

http://forum.kerbalspaceprogram.com/threads/57988-1-0-x-Wenkel-Corporation-RealChute-Parachute-Systems-v1-3-2-2-1-05-15?p=1894291&posted=1#post1894291

Hypersonic chute deployment isn't particularly realistic. There are chutes that can deploy at low supersonic but they have gaps cut in them to reduce drag. Drogue can deploy while at speeds that would damage the main chutes. (which is one of the reasons for drogue chutes) *

Apollo didn't deploy its drogues until something like 7km and mains at 3km altitude.

Adding the ability to distiguish between drogues and mains was something I wanted to do in DRE but never got around to it. Future versions of DRE may not have this feature added in as both stock and Real Chutes are adding unsafe chute deployment at high speed..

*high altitude or low density environments increase the safe velocity for chutes. The Curiosity rover featured chutes that were rated for up to Mach 2.2 though they deployed at Mach 2.

But, the final answer has nothing to do with realism. It's your sandbox, play however the heck you want. Don't like what DRE does with the chutes? Change it.

[Surefoot]

We are in need of proper air brakes though.. Currently abusing drogue chutes for killing velocity on heavy re entry vehicles, i'd gladly swap them for properly designed high speed airbrakes.

[Enceos]

We are in need of proper air brakes though.. Currently abusing drogue chutes for killing velocity on heavy re entry vehicles, i'd gladly swap them for properly designed high speed airbrakes.

Airbrakes in their essence don't have enough dragging area to decelerate the vehicle as fast as chutes do. You can confirm this visually.

[Starwaster]

Airbrakes in their essence don't have enough dragging area to decelerate the vehicle as fast as chutes do. You can confirm this visually.

Here's a solution to both problems.

I gotcher airbrake right here:

(well, you still need a chute; the capsule in this image is probably screwed)

[smjjames]

Does this have 5m heatshields?