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

[Starwaster]

9 minutes ago, chrisl said:

I'm trying to create a heat shield but I'm having trouble and I believe it's because I don't really understand the parameters in ModuleHeatShield.  I'm pretty sure that the three I'm concerned with are lossExp, lossConst & pyrolysisLossFactor.  I'm just not sure what each actually does.  I've tried using existing parts as reference, but after trying numerous combinations, I'm still not really understanding how this all works.  My heatshield either burns through Ablator like it's nothing (1250 units in about two minutes while decelerating from 7600 to 7000m/s at 50km-75km altitude) or I use almost no ablator.  That's one problem.  THe other is that the "Exposed Skin" temp seems to climb very high (2700+) which seems to greatly increase the Internal Temp of the part (1000+).  Any assistance in understanding these parameters would be greatly appreciated.

Some thoughts:

• It sounds like you're using a scaled up star system so you are probably looking at the wrong configs. There are a set just for scaled up systems: https://github.com/Starwaster/DeadlyReentry/blob/master/DeadlyReentry/DeadlyReentry_AlternateStarSystems.cfg (these almost universally assume a Real Solar System or Kerbol x10 sized system)
• pyrolysis loss = pyrolysisLossFactor * ablator resource hsp value. It is the amount of flux removed from the shield per ton of shield ablated. (the amount actually ablated is on the order of kilograms/second)
• The amount of material lost per second is lossConst * EXP(lossExp / skinTemperature) * resource maxAmount * resourceDensity 
• lossExp should be negative because of the way it gets applied. If it's positive then your shield will probably use up ablator at a faster rate than you want.
• ModuleHeatShield is an extension of the stock ModuleAblator. It allows for the heat shield to have different (lower) max temperature ratings when the shield is depleted.

The first point is probably most important, if you want to skip figuring out the formula (though it is simple and lends itself to being used in a spreadsheet easily) just look at how the scaled up system shields are configured. They do work (though I also do feel that more intuitive settings are possible)

Be sure that your shield's conductivity is low enough to prevent heat from bleeding through and I set up ModuleHeatShield to allow normal conductivity to be applied when it is depleted.

[chrisl]

14 hours ago, Starwaster said:

Some thoughts:

• It sounds like you're using a scaled up star system so you are probably looking at the wrong configs. There are a set just for scaled up systems: https://github.com/Starwaster/DeadlyReentry/blob/master/DeadlyReentry/DeadlyReentry_AlternateStarSystems.cfg (these almost universally assume a Real Solar System or Kerbol x10 sized system)
• pyrolysis loss = pyrolysisLossFactor * ablator resource hsp value. It is the amount of flux removed from the shield per ton of shield ablated. (the amount actually ablated is on the order of kilograms/second)
• The amount of material lost per second is lossConst * EXP(lossExp / skinTemperature) * resource maxAmount * resourceDensity 
• lossExp should be negative because of the way it gets applied. If it's positive then your shield will probably use up ablator at a faster rate than you want.
• ModuleHeatShield is an extension of the stock ModuleAblator. It allows for the heat shield to have different (lower) max temperature ratings when the shield is depleted.

The first point is probably most important, if you want to skip figuring out the formula (though it is simple and lends itself to being used in a spreadsheet easily) just look at how the scaled up system shields are configured. They do work (though I also do feel that more intuitive settings are possible)

Be sure that your shield's conductivity is low enough to prevent heat from bleeding through and I set up ModuleHeatShield to allow normal conductivity to be applied when it is depleted.

I'm actually playing RO.  Still on KSP1.2.2 so presumably a little behind the latest Deadly Reentry build.  I'm also looking at the parts via the ModuleManager.ConfigCache file so I'm guessing I'm looking at the parts as they actually exist in the game.

So pyrolysis loss determines how much heat is dissipated by the ablator I'm using up.  So if it looks like my Exposed Skin temp is too high, I need to increase this value.
lossConst and lossExp determine how much material I'm burning per second so if it seems like I'm burning through it way too fast, I need to lower these values.

I'm assuming it's reentryConductivity that determines how much heat is passing through the part during reentry.  At least while the heat shield has Ablator left.  And then, presumably, the part goes back to using heatConductivity when the Ablator is gone.  Not that it matters too much in my case since if the Ablator goes, my shield blows up about half a second later.  Thank you for this info.  I believe it'll help me finish setting up my part.

[eightiesboi]

Hey @Starwaster!

I have been having a problem, which I detail here: 

After conducting a number of tests with various permutations, I found that when I used the DRE 1.25m heat shield, tweakscaled up to 2.75m, my vessel would flip. When I used the Squad heat shield (either 2.5m tweaked to 2.75, or 1.25 tweaked to 2.75 and some ablator removed), the vessel did not flip. I noted in the VAB that the Squad shields have listed a component of Lift (not saying that's what it is). Are the shields (yours and Squad's) supposed to perform roughly identically? If so, do you have any suggestions? I have .craft files and videos available. I was running in a test environment with only DRE, SSPX(r), RCS build aid, SETI Probe Parts and the associated dependencies. 

This folder has the videos and the .craft file, as well as my output logs: https://1drv.ms/f/s!AoyHZiRU1jT-yfUB-64QbAPkq90q-w

[Starwaster]

13 hours ago, eightiesboi said:

Hey @Starwaster!

I have been having a problem, which I detail here: 

After conducting a number of tests with various permutations, I found that when I used the DRE 1.25m heat shield, tweakscaled up to 2.75m, my vessel would flip. When I used the Squad heat shield (either 2.5m tweaked to 2.75, or 1.25 tweaked to 2.75 and some ablator removed), the vessel did not flip. I noted in the VAB that the Squad shields have listed a component of Lift (not saying that's what it is). Are the shields (yours and Squad's) supposed to perform roughly identically? If so, do you have any suggestions? I have .craft files and videos available. I was running in a test environment with only DRE, SSPX(r), RCS build aid, SETI Probe Parts and the associated dependencies. 

This folder has the videos and the .craft file, as well as my output logs: https://1drv.ms/f/s!AoyHZiRU1jT-yfUB-64QbAPkq90q-w

Sorry but I'm not going to install parts from mods I don't have just to investigate your situation, especially when it's coming down to 'DRE parts vs stock Squad parts'. 

Unfortunately that also means no Tweakscale. Tweakscale's past has been too troubled and problematic and I need to be able to reproduce problems without the use of Tweakscale. And if it's really a  DRE vs stock issue then I shouldn't need Tweakscale anyway.

And while I will definitely consider making changes that bring DRE parts in line with stock parts, I won't guarantee that they will always do so except when it's required for sensibly constructed reentry vehicles. 

[eightiesboi]

6 minutes ago, Starwaster said:

Sorry but I'm not going to install parts from mods I don't have just to investigate your situation, especially when it's coming down to 'DRE parts vs stock Squad parts'. 

Unfortunately that also means no Tweakscale. Tweakscale's past has been too troubled and problematic and I need to be able to reproduce problems without the use of Tweakscale. And if it's really a  DRE vs stock issue then I shouldn't need Tweakscale anyway.

And while I will definitely consider making changes that bring DRE parts in line with stock parts, I won't guarantee that they will always do so except when it's required for sensibly constructed reentry vehicles. 

No worries. I'm out of town for a few days and then, if you'd like, I'll try to replicate this with stock parts and DRE only. 

[dlrk]

What's a good way to work out a reasonable temperature cap for an engine? I'm writing an MM patch for the KRE SuperDracos (they should be able to survive reentry at a high speed, since the real one can). I'm thinking 1623 , since the real ones are Inconel and it looks like that's the melting point. Is that about right?

[ASCIInerd73]

I tried installing this mod via ckan and it kept crashing ckan when I tried to install it that way. Is this a known issue? I'm running ksp v1.3.0 and v1.24, in case it matters.

[Starwaster]

3 hours ago, ASCIInerd73 said:

I tried installing this mod via ckan and it kept crashing ckan when I tried to install it that way. Is this a known issue? I'm running ksp v1.3.0 and v1.24, in case it matters.

Wrong! The mod cannot 'crash CKAN' because it doesn't execute any code during a CKAN installation. Bring any and all CKAN errors and crashes to CKAN.

And / or download Deadly Reentry manually from its official Github releases page: https://github.com/Starwaster/DeadlyReentry/releases

 

[FrancoisH]

CKAN can crash when an archive isn't correctly formatted, experienced this quite a few time. It's a CKAN issue anyway as it should prevent and just say it rather than crash

I'm just waiting to know if Deadly Reentry is compatible with 1.4.1 as I haven't got any report of it yet

Edited March 18, 2018 by FrancoisH

[Starwaster]

5 hours ago, FrancoisH said:

CKAN can crash when an archive isn't correctly formatted, experienced this quite a few time. It's a CKAN issue anyway as it should prevent and just say it rather than crash

I'm just waiting to know if Deadly Reentry is compatible with 1.4.1 as I haven't got any report of it yet

The current build will spam exceptions and particle / sound FX will not work because they finally did away with the old particle system. (it's been marked as deprecated for awhile now) 

Also some functionality is disabled due to the version checker.

They're easy problems to deal with but there are other minor code changes that I'm contemplating and I may push another update for the older versions of KSP containing those changes.

[FrancoisH]

23 hours ago, Starwaster said:

The current build will spam exceptions and particle / sound FX will not work because they finally did away with the old particle system. (it's been marked as deprecated for awhile now) 

Also some functionality is disabled due to the version checker.

They're easy problems to deal with but there are other minor code changes that I'm contemplating and I may push another update for the older versions of KSP containing those changes.

Thank you for answering  I'll wait for the update.

 

[Daniel Prates]

Indeed my loading screen warns me that this mod is not compatible,  though I use many other 1.3 mods and the game does not seem to care. Whatever the incompatibility is, it must be relevant!

Good to know an update is in the works. This is a great mod.

[Starwaster]

3 hours ago, Daniel Prates said:

Indeed my loading screen warns me that this mod is not compatible,  though I use many other 1.3 mods and the game does not seem to care. Whatever the incompatibility is, it must be relevant!

Good to know an update is in the works. This is a great mod.

You wanna know the truth about the incompatibility warning? There's a common compatibility checker that lots of mods use and it consults every mod running as to whether it is compatible or not. And the code in the mod then compares the KSP version number and (optionally) the Unity version and if they don't match then it reports false.

When I update DRE I could (and have) forgotten to update the listed version numbers so it reports incompability even though I know better. The Unity checker in DRE always reports true because I don't give a used fig about that . And I usually disregard the minor update number on the KSP side as well.

By the same token I could just recompile the thing doing nothing but updating the version numbers in the checker and it will happily report compatibility even though some hidden incompatibility is lurking in the shadows waiting for its hour to come round at last...

Edited March 22, 2018 by Starwaster

[Daniel Prates]

17 minutes ago, Starwaster said:

You wanna know the truth about the incompatibility warning? There's a common compatibility checker that lots of mods use and it consults every mod running as to whether it is compatible or not. And the code in the mod then compares the KSP version number and (optionally) the Unity version and if they don't match then it reports false.

When I update DRE I could (and have) forgotten to update the listed version numbers so it reports incompability even though I know better. The Unity checker in DRE always reports true because I don't give a used fig about that . And I usually disregard the minor update number on the KSP side as well.

By the same token I could just recompile the thing doing nothing but updating the version numbers in the checker and it will happily report compatibility even though some hidden incompatibility is lurking in the shadows waiting for its hour to come round at last...

Oh wait, so the warning is just a mcguffin? I can safely ignore it (in this case anyway)? 

[Jacke]

2 hours ago, Daniel Prates said:

Oh wait, so the warning is just a mcguffin? I can safely ignore it (in this case anyway)? 

The warning isn't a McGuffin but a warning of a possible issue.  It's saying the version of the current KSP lies outside the allowed KSP versions in the mod's .version file.  That version of the mod could still operate correctly with the current KSP.  The values in the .version file can be wrong, as Starwaster indicated.  So the warning can happen when there'll be no problem.  And problems can sometimes arise when there's no warnings.

So it's a warning to be a bit more cautious.  And warning or not, be sure to save, take care not to overwrite crucial saves, as well as backing saves up.  Because game-crashing bugs can hit anytime.

[Starwaster]

13 hours ago, Daniel Prates said:

Oh wait, so the warning is just a mcguffin? I can safely ignore it (in this case anyway)? 

Depends on what your definition of safe is; DRE for 1.3.1 will spam exceptions to the log in 1.4.1 because the deprecated particle system has finally been removed, and that stream to the log will hurt performance. ModuleAeroReentry will likely not function. Heat shield probably would since it doesn't hook into the checker. Configs would still be good for balancing of temps. 

But it's best to wait. Won't be too long.

Interestingly enough, the menu DID work when I initially tested it in 1.4.1 but then stopped after recompiling because I had forgot the version number update... again.

Anyway, whether or not you can or cannot ignore a particular version mismatch warning really depends on the mod and how familiar you are with it. I do occasionally ignore the warnings but only IF I know for a fact that the mod will function as is and if I'm actually familiar enough with the code to say so.

Edited March 22, 2018 by Starwaster

[Daniel Prates]

1 minute ago, Starwaster said:

But it's best to wait. Won't be too long.

 

And well worth the wait too. Current stock heat caused to reentry is way too low, even in the toughest setting.

Edited March 22, 2018 by Daniel Prates

[Starwaster]

So what do you people think? Should I also try to do something about the FX? I think most people I've talked to don't like the new reentry FX but I've seen some people on the forums who think they're better now and I'm like lolwhut? 

How about it? Do you think the current FX look better than THIS?

That's an OPT based shuttle btw hence the broad blunt front. And part of it is on fire because I didn't make a set of DRE configs for some part on it...

Edited March 22, 2018 by Starwaster

[UnanimousCoward]

Personally, I much preferred the old effects. If you have some way to improve on the new effects, I'm all for it.

There are people who prefer the new effects? Really? Well, I suppose there's always some contrarians... 

[Starwaster]

wow I just put the same spaceplane through reentry in 1.4.1... I'll post both pics here for comparison.

KSP 1.3.1

KSP 1.4.1

Edited March 22, 2018 by Starwaster

[Starwaster]

BTW, in both cases, portions of the craft are on fire. The implementation of the flame effects is in Deadly Reentry but the particles are stock particles... so it looks like the particle itself changed... maybe there's some settings I can play with there to get it looking better but I don't know.

The shockwave on the other hand is not a particle effect, that's a geometry shader and it works by creating multiple 'shells' which are progressively enlarged duplicates of the part's mesh, and in 1.4.1 maybe stretched too, not sure exactly what they're doing there but but it lacks the texturing of the older effect.

[Gordon Dry]

From my subjective opinion on first sight the 1.3.1 variant looks better.

But wait, how can I know what is looking more realistic (or authentic)?

Did ever, ever do a camera drone fly next to a reentering vessel at >2000 m/s (or way more if the planet is called Earth), holding perfect relative position and do a steady video recording or at least steady and sharp photographs?

Did any famous high sophisticated professional photographer ever, ever do a perfect high zoom shot of such a scenario from the ground?

So, how can we know how it looks like?

Edited March 22, 2018 by Gordon Dry

[dafidge9898]

Could anyone provide some tips on reentry in Realism Overhaul? I can't seem to do it without exploding. I explode even when using the lunar rated heat shield from a low earth orbit. My reentry vehicles are shaped like any standard reentry vehicle: the sort of conical shape. I go so far as putting payload fairings around the avionics, but everything still blows up in the end. This hasn't happened to me in previous versions of this mod and RO, so I'm totally lost. Any insight? Thanks!

[kcs123]

11 hours ago, dafidge9898 said:

Could anyone provide some tips on reentry in Realism Overhaul? I can't seem to do it without exploding. I explode even when using the lunar rated heat shield from a low earth orbit. My reentry vehicles are shaped like any standard reentry vehicle: the sort of conical shape. I go so far as putting payload fairings around the avionics, but everything still blows up in the end. This hasn't happened to me in previous versions of this mod and RO, so I'm totally lost. Any insight? Thanks!

Two pages back, I think it is still valid:

Proper angle on re-entry is first one to try changing until you find one that fits for your craft. Heating shields helps too and creating a re-entry module to be areodinamicaly stable, so it points shield always in forward position to protect ship from overheating. Depending of dV left, you may also want to reduce Ap altitude before you start re-entry.

Other than that, it is always possible that some bug is involved too. In that case, you know the drill: logs, screenshots, videos, savegame ... whatever can help finding and solving bug. Might be a case that you using some moded part that is not configured properly for RO too.

[dafidge9898]

6 hours ago, kcs123 said:

Two pages back, I think it is still valid:

Proper angle on re-entry is first one to try changing until you find one that fits for your craft. Heating shields helps too and creating a re-entry module to be areodinamicaly stable, so it points shield always in forward position to protect ship from overheating. Depending of dV left, you may also want to reduce Ap altitude before you start re-entry.

Other than that, it is always possible that some bug is involved too. In that case, you know the drill: logs, screenshots, videos, savegame ... whatever can help finding and solving bug. Might be a case that you using some moded part that is not configured properly for RO too.

I know my reentry profile is fine, and my craft is stable. I tested reentry with the Mk 1 pod, which is definitely RO compatible, and it still blew up, so I think it just comes down to tweaking some settings. Do you happen to know which settings to turn down? Thanks

EDIT: I noticed there is a config file higher up, but I dropped that in the deadly reentry folder to no avail. 

Edited March 27, 2018 by dafidge9898