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

[NathanKell]

https://github.com/NathanKell/DeadlyReentry/releases

And yes DREC v5 is for RC 1.2+

[Dr. Corporal Klinger]

Woops, I feel silly now. Thanks!

[krenshala]

NathanKell, Just wanted to pass on that I upgraded from 4.8 to 5.0 today (both running in 0.24) and I started getting the bug where decouplers didn't provide any force. I launched two separate kerbal rescue missions today. Both used the same vessel (three Mk1 capsules each with their own engine and parachute). The first, when I was still using 4.8, worked as expected: popped the decoupler and the reentry vehicle drifted away from the ship at about 0.7 m/s.

With the second, after seeing you had updated DRE and my installing v5.0, behaved much differently. The decoupler made the appropriate noises and visuals, but the reentry vehicle did not move at all. After switching to the now separate vehicle, I had it roll in place and that caused it to move away from the mothership as expected.

I saw in another thread something about decouplers not behaving correctly in x64, but I was not having this problem until I did the DRE v5 update (from v4.8). I made no other changes to KSP today so I know for sure its something that changed in the 4.8 to 5.0 changes.

[kalor]

Standard deorbit from 100km Kerbin orbit. But still overheating at 20km periapsis...

That may be a bit steep for a first pass. I recommend 2 passes, maybe more if needed... set the first PE to 40-ish, it may or may not be enough to bring you all the way in on the first pass, but it will reduce your AP (thereby reducing your speed when you come back in for the next pass) and also lower your PE for the second pass. With enough patience and multiple passes you can sometimes pull a re-entry with no heat shields, so long as you keep engines on your last stage, though its not recommended... I discovered it myself out of necessity

Basically the principle I use is that the more time I spend in the thinner upper atmosphere where the parts don't heat up as much, the lower my velocity when I hit that thicker air lower down. It takes longer to de-orbit, so running TACLS and using this method can get iffy if you are low on resources, but it will bring you down eventually.

Also note that, at higher altitudes, if you are perpendicular to your direction of travel, you are increasing your drag, and slowing yourself more than if you are facing retrograde. I generally stay perpendicular until ~38KM, with some variance depending on the speed of my entry, before turning retrograde.

Hope this helps some!

[Oinker]

DR Tweaks to adjust decouplers to same cost as stock .24 for career mode.

I delete the 2m and 3m decoupler cfg's (no stock tanks fit them) and 4m (duplicates TR-38-D)

@PART[0625_Heatshield]
{
	@TechRequired = survivability
}

@PART[1.25_Heatshield]
{
	@TechRequired = survivability
}

@PART[2.5_Heatshield]
{
	@TechRequired = specializedControl
}

@PART[decoupler_ftr_small]
{
	@cost = 400
	@mass = 0.05
	@maxTemp = 1700
	@description = This deoupler will fit nicely and meet flush with the Mk1 pod.
}

@PART[decoupler_ftr]
{
	@TechRequired = specializedControl
	@cost = 550
	@mass = 0.4
	@maxTemp = 1700
	@description = This deoupler will fit nicely and meet flush with the Mk1-2 pod.
}

Edited July 21, 2014 by Oinker

[NathanKell]

krenshala: no, you don't know for sure that DRE caused it, since it is a stock x64 bug that appears somewhat randomly. DRE does nothing to decouplers. Please don't go accusing me of breaking things when a 30 second search will prove it's a stock bug, mentioned on the official x64 bugs thread.

Oinker: those costs make sense. I will try to remember to move the 2m and 3m over to Realism Overhaul. Although I hasten to point out that many, many people use Procedural Parts (and used StretchyTanks) on non-RO installs, and therefore those parts have a use for them too.

[Maxwell Fern]

Thank you for this awesome mod without which I wouldn't even imagine to play.

However, something bothers me: debris rarely desintegrate upon reentry. I'm talking about this last stage that I decouple just before entering atmo, and that fly by me, unharmed to the ground.

On a recent mission, I accidently placed a tiny decoupler upside down on an ablative shield, so it stuck to it upon reentry: not only didn't it get destroyed, this ridiculous part took all the heat, leaving the shield in pristine condition.

So in short, I'd like anything that is not shielded to disintegrate during reentry, just like in real life. Is that possible ? How would I do that ?

Thanks a lot, please keep up the good work

[NathanKell]

Thanks!

You can do that by reading the OP and/or readme; both very prominently describe how to do that

[Maxwell Fern]

Thanks for the quick answer !

So I went through the readme, bascially I would need to change the shockwave exponent and install the heatshieds from RSS, correct ?

Edit: the link provided in the readme is dead (https://github.com/NathanKell/RealismOverhaul/raw/master/RealismOverhaul/DRE_ShieldsFix.cfg)

Edited July 21, 2014 by Maxwell Fern

[TheDamDog]

I'm not sure if this is entirely a bug, but here goes. Apologies if it's already been reported.

Heat from the engines appears to be transferring into fuel tanks in 64-bit KSP, resulting in the tanks heating up at the same rate as the engines, or faster in the case of small engines. The heating appears to go on even after the engines reach their 'running temperature'. Once outside the atmosphere, the problem seems to vanish as the tanks cool down. Securing the rocket to the launch pad appears to keep the destruction from occurring...but it happens instantly once the launch clams detach. Got a fuel tank up to 10,000 degrees that way.

The part I'm certain is a bug is that the fuel tanks, when destroyed, apparently retain their attachment points. Engines are not destroyed by this process and remain fixed in space below the rocket, drawing fuel from the non-existent tanks. This also creates some really weird camera bugs, as it appears to cause the camera to assume the point between the rocket's present position and the destruction of the tanks is the center of mass. If you continue flying the rocket in this state, the crew is eventually killed due to g-force damage, regardless of the meter remaining in the green.

I am running a heavily modded game, but nothing that I think would directly interfere with DE.

[technion]

Are there any shielded radial parachutes available?

I've had a number of instances of lugging a heavy heat shield the whole way to eeloo and back, only to find it fully protects the command module, but I need to be extra careful and delicate on the re-entry because two dial parachutes that look like they are protected keep exploding. I don't mind if they weigh a tonne each..

[Starwaster]

I'm not sure if this is entirely a bug, but here goes. Apologies if it's already been reported.

Heat from the engines appears to be transferring into fuel tanks in 64-bit KSP, resulting in the tanks heating up at the same rate as the engines, or faster in the case of small engines. The heating appears to go on even after the engines reach their 'running temperature'. Once outside the atmosphere, the problem seems to vanish as the tanks cool down. Securing the rocket to the launch pad appears to keep the destruction from occurring...but it happens instantly once the launch clams detach. Got a fuel tank up to 10,000 degrees that way.

The part I'm certain is a bug is that the fuel tanks, when destroyed, apparently retain their attachment points. Engines are not destroyed by this process and remain fixed in space below the rocket, drawing fuel from the non-existent tanks. This also creates some really weird camera bugs, as it appears to cause the camera to assume the point between the rocket's present position and the destruction of the tanks is the center of mass. If you continue flying the rocket in this state, the crew is eventually killed due to g-force damage, regardless of the meter remaining in the green.

I am running a heavily modded game, but nothing that I think would directly interfere with DE.

A large part of this is the bugginess of 64 bit KSP. some of it is normal though like parts transferring heat to other parts.

a tank should explode long before 10000 degrrees... and when it does explode, it's stock KSP that makees that happen

[TheDamDog]

A large part of this is the bugginess of 64 bit KSP. some of it is normal though like parts transferring heat to other parts.

a tank should explode long before 10000 degrrees... and when it does explode, it's stock KSP that makees that happen

It only gets up to that temperature if it's secured to the launch pad. As I said, it explodes instantly once the clamps are disconnected.

It doesn't seem to be a vanilla problem. No 'overheat' bar appears on the tank, and it doesn't happen if I remove DE.

[NathanKell]

Maxwell Fern: Apologies. I updated the link in the OP but forgot to do so for the readme. Yes, you are correct about what changes.

(The correct link is https://raw.githubusercontent.com/NathanKell/RealismOverhaul/master/RealismOverhaul/RO_DRE.cfg )

TheDamDog: Starwaster mostly answered this. To confirm, none of that has anything to do with DRE; DRE merely lowers part temperatures. It uses the same code SQUAD does to destroy a part when it is over max temperature (you can overheat and destroy things in stock KSP, just reentry doesn't add heat).

Can you reproduce this using only DRE?

technion: pic of the craft?

[TheDamDog]

TheDamDog: Starwaster mostly answered this. To confirm, none of that has anything to do with DRE; DRE merely lowers part temperatures. It uses the same code SQUAD does to destroy a part when it is over max temperature (you can overheat and destroy things in stock KSP, just reentry doesn't add heat).

Can you reproduce this using only DRE?

It only happens with DRE, removing the module removes the problem. Lowering the temperature exponent also removes the problem.

[NathanKell]

I'm not asking you if removing DRE fixes the problem. I'm asking you to replicate the problem on stock KSP with only DRE installed.

[krenshala]

krenshala: no, you don't know for sure that DRE caused it, since it is a stock x64 bug that appears somewhat randomly. DRE does nothing to decouplers. Please don't go accusing me of breaking things when a 30 second search will prove it's a stock bug, mentioned on the official x64 bugs thread.

Dude! Chill. I wasn't blaming you for it, I was trying to provide info on what specifically happened to me when I got the problem. The facts are that it was the only change I made and the problem appeared after the change. In my 30 years of troubleshooting experience a change that was made is, 49 times out of 50, the root cause of the problem ("No, Mr Techsupport guy, I didn't make any changes. When the problem happened I was using the software just after installing the driver update I didn't mention until now. Of course, it can't be the driver ...")

Since it clearly matters so much to you that you think I'm accusing you of breaking things, I decided to revert back to 4.8 to see what happens. I ran a mission just now using DRE 4.8 and the TT-18A between stages 4 and 5 decoupled as expected (74km up, level "flight", free-fall). I reverted back to the launch pad, shutdown the game swapped back to DRE 5.0 and launched again with the same ascent profile, and checking the same TT-18A at the same point in the flight. Once again, the problem ONLY appears when DRE 5.0 is installed.

So, while the problem may also randomly happen in all x64 games, it CONSISTENTLY happens in my game when I have DRE 5 installed and DOES NOT happen when DRE 4.8 is installed.

edit: Reading the post above mine, I decided to try the same test with DRE as the only mod installed. I closed the game again. Moved all the mods except DRE 5.0 and MM 2.2.0 (came with 5.0) to another directory (outside the KSP directory structure), started a sandbox game and build a rocket similar to what I tested above. With 5.0 the TT-18As has zero force. I then reverted the flight to the launch pad (as I did above), shut down the game and switched back to DRE 4.8 again. Interestingly enough, with both TT-18A separations, it also had the problem (zero force).

So, this tells me that the difference between DRE 4.8 and 5.0 more than likely isn't the cause, despite initial appearances.

This, of course, makes me wonder why I didn't experience the problem before I installed DRE 5.0. The mods I removed were KER 0.6.2.5, FAR 0.14, Kethane 0.8.8, Kerbal Alarm Clock 2.7.7, TAC Life Support 0.9.0.9 pre3, and RT2 1.4.0 (built for 0.23.5). I wonder if something in one of those mods removes the problem with DRE 4.8 but not with DRE 5.0?

Edited July 22, 2014 by krenshala
Adding more QA info

[Snacksquatch]

I'm not sure if this is entirely a bug, but here goes. Apologies if it's already been reported.

Heat from the engines appears to be transferring into fuel tanks in 64-bit KSP, resulting in the tanks heating up at the same rate as the engines, or faster in the case of small engines. The heating appears to go on even after the engines reach their 'running temperature'. Once outside the atmosphere, the problem seems to vanish as the tanks cool down. Securing the rocket to the launch pad appears to keep the destruction from occurring...but it happens instantly once the launch clams detach. Got a fuel tank up to 10,000 degrees that way.

The part I'm certain is a bug is that the fuel tanks, when destroyed, apparently retain their attachment points. Engines are not destroyed by this process and remain fixed in space below the rocket, drawing fuel from the non-existent tanks. This also creates some really weird camera bugs, as it appears to cause the camera to assume the point between the rocket's present position and the destruction of the tanks is the center of mass. If you continue flying the rocket in this state, the crew is eventually killed due to g-force damage, regardless of the meter remaining in the green.

I am running a heavily modded game, but nothing that I think would directly interfere with DE.

I'm getting this too on Win7x64 ksp64

Also heavily modded, and the behavior disappears once I uninstall DRE 5. I first ran into the camera bugs on a rather simple launch, then started realizing my chutes and tanks were burning off and there was no visual indicator until they were gone.

List of mods here.

https://www.dropbox.com/s/orzme89ecm13nq6/modslist.jpg

[chaos_forge]

Is there a normal 2.5m heat shield available? The one for the mk1-2 pod works, but it looks pretty wonky on any payload that isn't the mk1-2 pod.

[Godot]

Not sure if this was given via the mod or via KSP itself ...

but I somehow remember that in former versions of KSP, richtclicking on a part showed its temperature ...

this seems to be missing now

[RedAV8R]

krenshala: UM...No you quite specifically made an accusation that DRE causes the issue.

I made no other changes to KSP today so I know for sure its something that changed in the 4.8 to 5.0 changes.

Only upon further investigation AFTER you started slinging mud did you yourself realize...oh NathanKell was right and I was wrong.

Maybe instead of adding in your edit to your post you should have simply removed everything else and said just that.

"I'm sorry, you were right, I was wrong".

[Starwaster]

krenshala: UM...No you quite specifically made an accusation that DRE causes the issue.

I made no other changes to KSP today so I know for sure its something that changed in the 4.8 to 5.0 changes.

Only upon further investigation AFTER you started slinging mud did you yourself realize...oh NathanKell was right and I was wrong.

Maybe instead of adding in your edit to your post you should have simply removed everything else and said just that.

"I'm sorry, you were right, I was wrong".

No, he just made an end user mistake confusing coincidence with causality. There's no need to brow beat the guy into submission.

Let's just all drop it.

[NathanKell]

krenshala: I apologize for coming down like a ton of bricks, and rather than belabor the point I will take Starwaster's advice and merely direct you to the official "Known Issues in .24x64" thread, which has a link to a mod Sarbian created to fix this stock bug.

There is literally nothing in my code that affects decouplers, let alone decoupler force. So there is nothing for me to change.

chaos_forge: you can change the rescaling of the 2m one to be 2.5m if you want.

Godot: huh. That's been working fine for me. It is done by DRE, yes. That makes me wonder if you have an install issue and DRE isn't running right.

[chaos_forge]

chaos_forge: you can change the rescaling of the 2m one to be 2.5m if you want.

Do you mean 1.25 meter? The only heat shields i can see are a .625 meter one, a 1.25 meter one, the mk1-2 capsule heat shield, a 3 meter one, and the inflatable 6 meter one. Unless the others are in another place?

[Godot]

...

Godot: huh. That's been working fine for me. It is done by DRE, yes. That makes me wonder if you have an install issue and DRE isn't running right.

You are right, the error was on my side ... a typical US3R=1D10T error (to be more exactly ... it was unzipped into the main game folder and not into game data [to my excuse I might add that many plugins already have their mods in a game data folder within the zip file, so that it gets unpacked into game data when you choose the main folder ... guess therefore I automatically chose the main folder of KSP to unpack it in, without checking beforehand if the zip contains a Game Data Folder, or the Mod Folder on top])

Now everything is where it should be, thanks