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

[Jovus]

So does this have proper interop with RealChute? Specifically, parachutes now rip off from overheating ~300m/s. However, RealChute allows you to set different materials - silk, nylon, or kevlar. Is there any chance that setting different materials affects when and how the parachutes overheat?

[Starman4308]

So does this have proper interop with RealChute? Specifically, parachutes now rip off from overheating ~300m/s. However, RealChute allows you to set different materials - silk, nylon, or kevlar. Is there any chance that setting different materials affects when and how the parachutes overheat?

I think different melting temperatures for the different parachute materials are planned for the future, but...

Stop deploying your parachutes so close to Mach 1, that's your main problem. Try closer to 200-250 m/s.

[Starwaster]

Starwaster - I see you saw the problems with KAS/DRE. I was planning on filing a bug report tonight, but you're too quick! I also see you're trialling another DLL, so I assume you've narrowed down the cause of the bug. If you need another log/tester, let me know and I'll re-upload my logs. I'm using 32-bit on OS X, if that makes a difference for you.

Thanks, bug is confirmed fixed. I'll push a new version out later but I want to finish up some nose con heat shield configs first

[Lukaszenko]

How fast are you ascending? There's little reason to ever be using more than 2G of acceleration until you punch through lower atmosphere, in either stock or FAR aero.

I re-tested it with a ship not exceeding 1.7 g. Still blew up at like 1500 degrees. The parachute on the front of the same pod was around 350 degrees. It survived and kept flying along with the rocket, even though the pod it was originally attached to was no longer there.

I rebuilt a similar ship, and it didn't blow up. I'm guessing there's bug on this particular ship

Edited November 17, 2014 by Lukaszenko

[Drew Kerman]

Gaiiden, just download the dev version. Grab GameData from this link to the dev version (zipped) on github.

ah, thanks will do. I knew about the dev release, but when you said "corrected in git" I thought you were referring to an uncompiled source commit.

[Starwaster]

ah, thanks will do. I knew about the dev release, but when you said "corrected in git" I thought you were referring to an uncompiled source commit.

I thought it was an insult, like "you mangy Scot git"....

(just kidding)

[ModZero]

Thanks for fixing the KAS bug!

[Maars]

Ok, I can't do it any more, I have to ask. Starwaster, and this is with all due respect, any chance you could stop punishing the people that do love 64bit and enable this mod for it? I can't play KSP without it, I mean, what's the point? Couldn't you make a big disclaimer in capital letters stating that you'll ignore all punks that try and waste your time with 64bit bug reports but actually allow the happiness to be retained for quite a few people who can't stand 32bit and want to build stuff with more than bloody 3 parts and not suffer lag? My 0.25 64bit works almost flawlessly with 65 mods installed and I'm sure there are others out there like me who need DRE. Yes, I said it, NEED your mod. How can you play KSP without it?

peace

[ModZero]

Yes, I said it, NEED your mod

Y'know, claiming to need things you actually just want is kinda creepy...

peace

I'm pretty sure you're looking for the kind of peace delivered in the BDArmory mod. I have no idea why, it's totally not related to using words like "bloody", claiming to have a "need" and beating a dead horse.

[Maars]

relax dude, just because I use some superlatives doesn't mean there's hostility or trolling involved

[Lukaszenko]

I've been having some problems with the new iteration of this mod and I agree...I couldn't play the game. I was messing around trying to isolate the problem, but I just couldn't play the game without Deadly Reentry. This possibility simply wasn't (and still isn't) in the cards.

[John FX]

So does this have proper interop with RealChute? Specifically, parachutes now rip off from overheating ~300m/s. However, RealChute allows you to set different materials - silk, nylon, or kevlar. Is there any chance that setting different materials affects when and how the parachutes overheat?

It would make things more logical, I always imagine silk would rip before nylon which would rip before kevlar.

I don`t think it should be huge but there should be some benefit to using kevlar over silk, maybe 100m/s?

I currently deploy under 300m/s on kerbin and have no problems at all but I`d like to see a range of max speeds for the range of materials.

Also, does anyone have a clue what sort of speed the chutes might rip off on Duna? I set a few at various settings to try to nail it down but they all held, even at ludicrous speed.

Eve on the other hand just explodes my craft whatever I do. Burns up my fairings (behind heatshields) and makes my Remotetech omni 32 antenna explode even when they are inside other parts, even from a 100km orbit.

Gonna try Eve again with bigger heatshields to see just how rough it is.

[Darkblade48]

Another issue (but with no serious gameplay effect) is that Kerbal RCS effects are gone - also back if I remove DR.

Glad that this is at least documented. I was having a hell of a time trying to narrow down what was causing my EVA effects to disappear.

[Starwaster]

It would make things more logical, I always imagine silk would rip before nylon which would rip before kevlar.

I don`t think it should be huge but there should be some benefit to using kevlar over silk, maybe 100m/s?

I currently deploy under 300m/s on kerbin and have no problems at all but I`d like to see a range of max speeds for the range of materials.

Also, does anyone have a clue what sort of speed the chutes might rip off on Duna? I set a few at various settings to try to nail it down but they all held, even at ludicrous speed.

Eve on the other hand just explodes my craft whatever I do. Burns up my fairings (behind heatshields) and makes my Remotetech omni 32 antenna explode even when they are inside other parts, even from a 100km orbit.

Gonna try Eve again with bigger heatshields to see just how rough it is.

You know, I used to think Kevlar would be better too, but Kevlar gets weaker at high temperatures whereas Nylon 6-6 (according to a variety of technical sheets that I've looked at) has good characteristics at high temps and high strength.

It has been the fabric of choice in high speed braking chutes over Mars. On that subject, because of Duna's thin atmosphere, yes you can get away with very high speed (supersonic) deployment, just as Curiosity's chute was deployed at Mach 2.0 (it was rated as high as Mach 2.2). Altitude about 10km.

If you're using the beta version, a warning will be present on the top of your screen (just under the altimeter) telling you if it is not safe to deploy. That's tied into the same system that destroys the chutes so as to ensure that you can deploy safely when the warning has gone away. (it actually has a 3 second delay, so by the time the warning vanishes, it will have been safe to deploy for 3 seconds)

As far as an Eve reentry, all factors being equal, an Eve reentry should be a little safer than a Kerbin reentry, but one of the more important factors, speed, is not equal as you'll be coming in pretty fast, especially if Eve is actually Venus because you're using RSS. (and if you're using FAR, that will probably make things a little tougher). But if you can get past the upper atmosphere then you're pretty safe and can probably even land without chutes. (I read recently that the Venera probes freefell without their chutes the last 50 km) <-- EDIT: Oops that can't be right.... that must be a typo. Can anyone with actual knowledge on those probes confirm or refute that number?

I've been having some problems with the new iteration of this mod and I agree...I couldn't play the game. I was messing around trying to isolate the problem, but I just couldn't play the game without Deadly Reentry. This possibility simply wasn't (and still isn't) in the cards.

I have no idea what I'm supposed to do with this. Are you referring to the beta version? Couldn't play why? What problem couldn't you isolate? As feedback goes, you've given me nothing to work with here. I need a concise description of the problem and log files (not ksp.log either; output_log.txt or player.log if on Linux or OS-X)

To all: The bug that was causing problems with KAS (and potentially other mods) has been fixed but I have not pushed that version to release yet since I'm working on some other things. You can download a fixed DLL here: https://www.dropbox.com/s/moge45bumutdcwj/DeadlyReentry.dll?dl=1

Edited November 18, 2014 by Starwaster

[J.Random]

Does it depend on chute settings if it will be ripped off? I mean, all right, normal chutes are too dangerous for M1+, but drogues should be OK, right?

[Starwaster]

Does it depend on chute settings if it will be ripped off? I mean, all right, normal chutes are too dangerous for M1+, but drogues should be OK, right?

IRL, to some extent, yes, primarily because drogue chutes are smaller and have less drag and therefore are subject to less stress.

However, in the game, the check is made by comparing only the the chute's maxTemp against the shockwave temperature. It's more or less coincidence that it happens around Mach 1. (IRL these things are intertwined, but in the game from a pure programming logic standpoint we're just looking at the temperature values and atmospheric density values)

Since drogue chute parts have the same maxTemp as main chute parts, they have identical failure points. (we take 25% of the chute part's maxTemp to be the canopy's maxTemp and use 10x density)

For RealChute, someday we might go so far as to actually calculate aerodynamic stress using chute size and material and look at material thermal properties to more accurately determine when they fail, but that's not something that I'll be tackling anytime soon.

Edit: btw, the version currently in beta has different difficulty settings for chutes. On Easy, chutes have about double their survivability . (in the debug menu it's Parachute Temp Multiplier if you want to adjust it)

Edited November 18, 2014 by Starwaster

[Lukaszenko]

I have no idea what I'm supposed to do with this. Are you referring to the beta version? Couldn't play why? What problem couldn't you isolate? As feedback goes, you've given me nothing to work with here. I need a concise description of the problem and log files (not ksp.log either; output_log.txt or player.log if on Linux or OS-X)

I did describe the problem starting in post 2824. Perhaps you didn't see it, or perhaps I didn't give enough info. Anyway, it *might* have been resolved by me simply re-making an identical rocket, but I'm still testing. I'll let you know if I find anything. Either way, no complaints. Even if it's unfixable and makes the game unplayable for me, I already squeezed more enjoyment out of the game and your mod than I could ask for!

Edit: Oh, and yes...I just realized that I've been playing the beta version.

Edited November 19, 2014 by Lukaszenko

[Starwaster]

[kendoka15]

Thanks very much for the info

[Pirsig]

Hi, I was curious if I'm missing something or are there no configs for the NASAMission parts? I've been using Deadly Reentry for awhile but hadn't really noticed until I went to do DR compatibility for some part rescales.

[Starwaster]

Hi, I was curious if I'm missing something or are there no configs for the NASAMission parts? I've been using Deadly Reentry for awhile but hadn't really noticed until I went to do DR compatibility for some part rescales.

No, there's not, but it's not really an issue for most of those parts. The reasons for having configs on any of them are:

• to add a heat shield
  
• Adjust the maxTemp to something sane (since most parts have maxTemp values that are way too high)
  

There are no parts that require a heat shield in the NASAMission parts (with the possible exception that maybe the LES part could use a weak 0.05 - 0.10 passive reflective shield) and there's code in the plugin that will check for insanely high maxTemp values and set them to the lower of half of maxTemp or ridiculousMaxTemp which is defined in the DeadlyReentry.cfg file (which, I think I didn't document this but I cut that in half from 2500 to 1250)

In fact most parts out there for most mods have no DRE configs either but will do just fine without them.

[Pirsig]

No, there's not, but it's not really an issue for most of those parts. The reasons for having configs on any of them are:

• to add a heat shield
  
• Adjust the maxTemp to something sane (since most parts have maxTemp values that are way too high)
  

There are no parts that require a heat shield in the NASAMission parts (with the possible exception that maybe the LES part could use a weak 0.05 - 0.10 passive reflective shield) and there's code in the plugin that will check for insanely high maxTemp values and set them to the lower of half of maxTemp or ridiculousMaxTemp which is defined in the DeadlyReentry.cfg file (which, I think I didn't document this but I cut that in half from 2500 to 1250)

In fact most parts out there for most mods have no DRE configs either but will do just fine without them.

Ah, I didn't realize there was any sort of auto-detection for modifying maxTemp. Just to make sure I understand correctly then, any part with a temperature above ridiculousMaxTemp is having its maxTemp multiplied by .5, that's then being checked against ridiculousMaxTemp and whichever number is lower is applied to the part's maxTemp, correct? And this is being done by DeadlyReentry.dll? I'm confused about when exactly this is happening. As I continue to look at this now knowing that there's this auto checking for MaxTemp I'm finding inconsistencies. The Mk2 Series cockpits and parts all seem to be using the values provided by SPP.cfg, which are higher than 1250. However, my own configs for my part rescales which are above the threshold are hit with the .5 multiplier. In another example, the Mk1 series cockpits have maxTemp values above the threshold corresponding to those in DeadlyReentry.cfg. However, the maxTemp of the Mk1-2 Command pod, which is modified just a few lines earlier in the same config file, is hit by the multiplier. Is there some wonky, unintended behavior going on here that needs to be fixed or am I not understanding correctly? Should all the @maxTemp changes be removed and all of that handled by the auto checking for more consistency, possibly with a different value for ridiculousMaxTemp if the current temps above the threshold are intentional?

[Starwaster]

Ah, I didn't realize there was any sort of auto-detection for modifying maxTemp. Just to make sure I understand correctly then, any part with a temperature above ridiculousMaxTemp is having its maxTemp multiplied by .5, that's then being checked against ridiculousMaxTemp and whichever number is lower is applied to the part's maxTemp, correct? And this is being done by DeadlyReentry.dll? I'm confused about when exactly this is happening.

It happens at the main menu. All parts are iterated through by the plugin and adjusted exactly as you say. The value for ridiculousMaxTemp can be adjustedin DeadlyReentry.cfg if you're using the latest official release or in DefaultSettings.cfg in the beta (and in future releases)

I had planned on making that configurable by difficulty setting but that requires a good deal more coding and I ultimately decided against it. (because the current implementation happens at the main menu and because difficulty settings are per save game, there is no concept of difficulty until after a game is loaded up)

As I continue to look at this now knowing that there's this auto checking for MaxTemp I'm finding inconsistencies. The Mk2 Series cockpits and parts all seem to be using the values provided by SPP.cfg, which are higher than 1250. However, my own configs for my part rescales which are above the threshold are hit with the .5 multiplier. In another example, the Mk1 series cockpits have maxTemp values above the threshold corresponding to those in DeadlyReentry.cfg. However, the maxTemp of the Mk1-2 Command pod, which is modified just a few lines earlier in the same config file, is hit by the multiplier. Is there some wonky, unintended behavior going on here that needs to be fixed or am I not understanding correctly? Should all the @maxTemp changes be removed and all of that handled by the auto checking for more consistency, possibly with a different value for ridiculousMaxTemp if the current temps above the threshold are intentional?

Actually, 1250 is from the beta. I cut the value for ridiculousMaxTemp in half. The latest official is 2500 so 1700 (for the Mk1-2 and others) is well below the cap. So, if you're looking at the latest official then those numbers are ok. The beta numbers are still subject to change so the maxTemp adjustments will come down to something suitable. Unless I raise the cap back up.

In addition to that however is that (oops sorry, I left this out of my explanation) heat shield parts are exempt and that includes the SPP parts and most other plane related parts. In fact, those have to be fairly high because their heat shield configurations are reflective only and lack ablative shielding. Typically those parts will reflect 10% to 25% of all incoming heat which is sufficient for stock Kerbin. (RSS... not so much)

Edited November 24, 2014 by Starwaster

[Pirsig]

...Actually, 1250 is from the beta. I cut the value for ridiculousMaxTemp in half. The latest official is 2500 so 1700 (for the Mk1-2 and others) is well below the cap. So, if you're looking at the latest official then those numbers are ok. The beta numbers are still subject to change so the maxTemp adjustments will come down to something suitable. Unless I raise the cap back up.

In addition to that however is that (oops sorry, I left this out of my explanation) heat shield parts are exempt and that includes the SPP parts and most other plane related parts. In fact, those have to be fairly high because their heat shield configurations are reflective only and lack ablative shielding. Typically those parts will reflect 10% to 25% of all incoming heat which is sufficient for stock Kerbin. (RSS... not so much)

This is all with the 6.3.1 Beta build, but yeah, the part about ignoring parts with the heathshield module for the auto maxTemp reduction makes everything make sense now. That said I think the last part of my previous post still stands, would it be better to remove all the @maxTemp stuff from the configs, minus those relating to heatshielded parts? I would think, though I could certainly be wrong, most people have created parts with maxTemp values comparable to those in stock. With that in mind shouldn't the values for maxTempScale and ridiculousMaxTemp be designed to produce desired reduction results when applied to stock value ranges instead of being designed with values that have already been reduced once?

[Shad0wCatcher]

@Starwaster having tested the beta thoroughly I went back to the stable version due to the heat transfer mechanic in place along with the lowered max temperatures for everything. The maximum temps I can understand to a point (melting point of aluminum @ 660C being the primary structural component of hull bodies) however the heat transfer is really really off. I was getting fuselages and couplers overheating and exploding long before the engine began to overheat. Nothing showing in output_log error-wise. As well any and all AJE engines from 1.6.6 (Haven't tested 1.6.7 with 6.3.1 beta) generate far too much heat at any throttle setting causing near instant connected part failures due to overheating at any altitude.

I can understand some of the aggressive heat transfer however without having that heat propagate to other parts there will always be a weak link at the connection point at the engine itself. As well having rocket engines overheat at 1000 celcius makes no sense (tested with multiple KW Rocketry engines primarily the 2.5 through 5 meter lifters; lower and upper stage). Other relevant mods are FAR, RealFuels, Stockalike config and 6.4x Kerbin w/ RSS class heatshields and NathanKell's MM patch specific to 6.4x Kerbin for the heatshields.

My only issues are:

1) Rocket motors transferring heat to other parts as quickly as they are (as my interpretation of the heat generation was always that the heat was at the bell not at the thrust plate)

2) Having AJE engines not being able to run at military thrust let alone afterburner at any altitude

3) Not having heat propagate to other parts apart from the connection between the engine and whatever it first connects .

If the last issue can be resolved the first two will fix themselves as heat will transfer properly instead of soaking in one part and causing catastrophic failures on every launch.

Edited November 24, 2014 by Shad0wCatcher