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

[Armchair Rocket Scientist]

I'm having a little trouble with reentry on my prototype reusable 1st stage.

I'm playing with RSS + FAR. The vehicle basically consists of a cluster of engines at the bottom, a short stretchy tank (containing reserve fuel for landing and braking after stage separation), a tall stretchy tank (containing the main fuel), and other miscellaneous hardware. There is also a dummy 2nd stage and payload, but this is jettisoned before reentry.

My launch profile gives me an apogee of 170-200 km, and a reentry speed of 3-3.5 km/s if no braking burn is performed.

I have tried two methods of braking. Method A is to to fire the engines at the beginning of reentry (using aerodynamic drag to provide ullage). Method B is to turn around and fire retrograde immediately after stage separation (in practice, turning and other preparation takes a minute). In both cases, the vehicle reaches peak decelerations of 10-15 Gs. The only parts destroyed by heat are the landing legs - this will be fixed later.

The problem is, the main fuel tank always explodes due to exceeding G-force tolerance. This happens well after peak heating or G-loading, in one case occurring at only 3 Gs and below mach 2. Note that this does not happen to the lower fuel tank or any other part of the rocket.

What do I do to prevent this?

[Starwaster]

I'm having a little trouble with reentry on my prototype reusable 1st stage.

I'm playing with RSS + FAR. The vehicle basically consists of a cluster of engines at the bottom, a short stretchy tank (containing reserve fuel for landing and braking after stage separation), a tall stretchy tank (containing the main fuel), and other miscellaneous hardware. There is also a dummy 2nd stage and payload, but this is jettisoned before reentry.

My launch profile gives me an apogee of 170-200 km, and a reentry speed of 3-3.5 km/s if no braking burn is performed.

I have tried two methods of braking. Method A is to to fire the engines at the beginning of reentry (using aerodynamic drag to provide ullage). Method B is to turn around and fire retrograde immediately after stage separation (in practice, turning and other preparation takes a minute). In both cases, the vehicle reaches peak decelerations of 10-15 Gs. The only parts destroyed by heat are the landing legs - this will be fixed later.

The problem is, the main fuel tank always explodes due to exceeding G-force tolerance. This happens well after peak heating or G-loading, in one case occurring at only 3 Gs and below mach 2. Note that this does not happen to the lower fuel tank or any other part of the rocket.

What do I do to prevent this?

sounds like you're too steep. This is a suborbital flight I take it?

You might try a radial burn to make your reentry more shallow.... Or if its not suborbital then dont lower your periapsis so low....

[NathanKell]

15nelsoc: no problem!

Armchair Rocket Scientist: craft file? Pics? That sounds weird that the tank would overstress that late. Is there jiggling going on? DRE cares about Gs from rapid back-and-forth see-sawing, as well as linear acceleration/deceleration.

[Armchair Rocket Scientist]

sounds like you're too steep. This is a suborbital flight I take it?

You might try a radial burn to make your reentry more shallow.... Or if its not suborbital then dont lower your periapsis so low....

Yep, it's suborbital. I have made the burn partially radial, but I'm concerned that a fully radial burn won't lower the rocket's velocity enough, and it will be destroyed by heating.

15nelsoc: no problem!

Armchair Rocket Scientist: craft file? Pics? That sounds weird that the tank would overstress that late. Is there jiggling going on? DRE cares about Gs from rapid back-and-forth see-sawing, as well as linear acceleration/deceleration.

A craft file wouldn't work too well, since I have a custom RealFuels engine config, but I'll send pics and see if I can identify any oscillations (can't make promises about when since this is my Finals week).

Jiggling back and forth does sound plausible, since my framerates are fairly bad when reentry or mach effects are being rendered.

[15nelsoc]

I finally figured out the issue with overheating too quickly. The most recent module manager update created a lot of issues within my existing craft files and ended up bugging some modules. After I identified that issue, I was able to perform a succesful reentry without any odd behavior. So no issue with DR. Thanks again for looking into it NathanKell and Starwaster!

[NathanKell]

Ah, I see--yeah, MM is finally fixing a bug, but it's brought front and center a serious bug/issue with the Module loading code. The usual smart folks are working on it though!

[lajoswinkler]

Reentry effects in KSP aren't even near any realism and that was pointed out several times on the forum, but so far no change has been observed.

Things to consider:

- ablative trail should start at much higher altitudes and look different, not just being weak or being intensive

- effects should not look like fire because they aren't fire, but rammed air glow, extending from the actual surface, glowing differently from the ablated surface ("Gravity" actually did that in few scenes, although the reentry effects weren't realistic because the glow was too weak and wrong color)

- surfaces being ablated by the radiative heating should have extreme, piercing, blinding white-greenish glow, not orange; when in sight, no stars should be visible, with everything else dimmed

Exact values on when, how bright, what color, how big, etc., should be checked out more thoroughly. Even though reentry hasn't been observed up close in detail, it's something we know a lot about. Not even "Gravity" did them correctly,

[NathanKell]

That's nice.

Ask Squad to fix their shader then?

[lajoswinkler]

That's nice.

Ask Squad to fix their shader then?

I'm not commenting Deadly Reentry, but KSP. Can you tweak those shaders and include that in your mod?

[Deadpangod3]

Does deadly reentry work on planet factory planets?

[Starwaster]

I'm not commenting Deadly Reentry, but KSP. Can you tweak those shaders and include that in your mod?

Unlikely. A lot of the necessary functions seem to be private.

Some minor tweaking might be possible, like it already tweaks when the glow appears and when it disappears. And KSP is sitting there in the background the whole time trying to change it back.

But outright modification of the shader responsible requires access to the FXCamera and the necessary functions are private.

[ialdabaoth]

There are so many things... SO MANY THINGS... that I would gladly fix for free for Squad, if they would be slightly less paranoid about people 'stealing' their code.

I understand the desire to protect your Intellectual Property; I really do. But there are so many things mod authors could do if some of Squad's classes were more permissive.

[Starstrider42]

There are so many things... SO MANY THINGS... that I would gladly fix for free for Squad, if they would be slightly less paranoid about people 'stealing' their code.

I understand the desire to protect your Intellectual Property; I really do. But there are so many things mod authors could do if some of Squad's classes were more permissive.

Huh? Class access permissions have absolutely nothing to do with IP -- if you really want to decompile and/or hack some software, you'll be able to reconstruct what the program does regardless of the permissions. What permissions are good for -- and what they're intended for -- is making sure different program components interact in a predictable way. And in that context, the narrowest permissions that meet your goals are usually the right ones.

What you should be asking for is for more of the KSP engine to be designed with modders in mind -- but that would likely manifest as a new set of public methods, not suddenly making existing private methods public.

Edited May 7, 2014 by Starstrider42

[ialdabaoth]

Well, most of these problem could be solved by callbacks, but I think that making a lot of methods public and overridable is the best way to go.

DeadlyReentry-relevant example: If the FixedUpdate() method on Part() was overridable, it would be trivially easy to replace KSP's heat model and its aerodynamics model.

[NathanKell]

Well, Mu made RequestResource virtual for us, so it's not impossible we could get them to make that virtual too.

[philly_idle]

While looking at the DR configs i found something odd (bug?) with the 3.75m heat shield: The 1.25m and the 2.5m shield both have 203.72 units of AblativeShielding (AS) per m², however the 3.75m has 362 AS/m² (a total of 4000 AS). 4000 would be a perfect match for 5m (again 203.72 AS/m²); for 3.75m the total amount of AS should be 2250.

I'm not sure if this is intentional, but i thought i report it anyway

[NathanKell]

The 3.75 is intended to be quite a bit thicker than the others; but maybe that's a bit too thick, yeah.

[Deadpangod3]

Does deadly reentry work on planet factory planets?

[AndreyATGB]

Does deadly reentry work on planet factory planets?

Yeah why wouldn't it?

[Deadpangod3]

Yeah why wouldn't it?

Just making sure.

[undercoveryankee]

Yeah why wouldn't it?

There are some Creators Edition planets out there that have non-unique FlightGlobals indexes and break FAR. Could that affect DRE at all?

[AndreyATGB]

There are some Creators Edition planets out there that have non-unique FlightGlobals indexes and break FAR. Could that affect DRE at all?

I don't know but I think DRE just uses density and velocity to get heat, FAR has at some point added gasses to atmosphere. I'd rather wait for Nathan to answer rather than spread false promises.

[NathanKell]

Yes, it could affect DRE. Tell those planet makers to actually set a unique index per planet.

[Starwaster]

Any plans to have DREC access FAR (if present) to grab atmospheric density to use for shockwave calculation? Or would you like me to code it up and submit it? (not sure when I can get to that but it's been on my mind lately to do if you aren't already planning on it but would like to)

[Taki117]

Any plans to have DREC access FAR (if present) to grab atmospheric density to use for shockwave calculation? Or would you like me to code it up and submit it? (not sure when I can get to that but it's been on my mind lately to do if you aren't already planning on it but would like to)

That would be an awesome feature for us FAR + DRE users. (Like myself)