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

[Yemo]

I could maybe treat them as having mass for thermal purposes... Can override thermalMass to have a minimum value

[...]

I guess all the parts with mass = 0 are intended to be physicsless anyway. The intention with is, to make them more of an "invisible" modification to the host part, instead of parts in their own right.

Thus they should imho be "nearly indistructible" by physics/heat/pressure, and thus simply share the fate of the host part.

[damerell]

When there's a stock resource don't think part mods will choose your special resource over that one

because ModuleManager exists and they won't have to choose at all.

[Svm420]

Hey, I just did a test. I came in at Kerbin, almost straight down, at almost 4 km/s and nothing exploded! All the craft was was a Mk 1-2 pod and a decupler, no crew, and it hit 15+ Gs, and there was a huge fireball, but none of the parts exploded. if you need a mods list or my output log, please tell me and I will get them.

I think that is expected. You probably would have killed the crew from g force not heat as you Passed through the atmosphere so fast.

[Cerebrate]

Gentles all, pray rest your sphincters, recall the wise words of Nick Fury, and apply or not such single_ablative_resource.cfg ModuleManager files as you might find appropriate:

// Kill the unwanted resource


!RESOURCE_DEFINITION[AblativeShielding]
{
}


// Patch all the resources


@PART
[*]:FINAL
{
    @RESOURCE[AblativeShielding]
    {
        @name = Ablator
    }
}


// Patch all the modules


@PART
[*]:HAS[@MODULE[ModuleHeatShield]]:FINAL
{
    @MODULE[ModuleHeatShield]:HAS[#ablativeResource[AblativeShielding]]
    {
        %ablativeResource = Ablator
    }
}

Feel free to swap "Ablator" and "AblativeShielding" over, if you prefer the other name. Either way, consider yourself freed from the terrifying scourge of redundant resources, able once again to see the status of all your mixture of heat shields on a single nanogauge/resource panel line, and in general, peace and prosperity unexampled returned once more.

...I go now to bring joy to the rest of Kerbin.

-c

(P.S. Otherwise, great update, @Starwaster!)

Edited May 13, 2015 by Cerebrate

[Starwaster]

Hey, I just did a test. I came in at Kerbin, almost straight down, at almost 4 km/s and nothing exploded! All the craft was was a Mk 1-2 pod and a decupler, no crew, and it hit 15+ Gs, and there was a huge fireball, but none of the parts exploded. if you need a mods list or my output log, please tell me and I will get them.

No surprise whatsoever. You had a higher than usual peak heating rate but it was short lived. Not enough time to burn anything. Physics are safe.

[BmB]

The matter is decided and the discussion is over, especially if trolls are going to come in issuing ad hominem attacks. Deal with it.

Legit criticism is not trolling. You are being very defensive about this, I called you out on it. It's not an attack. Ad hominem is a logical fallacy, I didn't make any claims to go with it, therefore fallacy does not apply. That kind of attitude will get you nowhere.

[Synthesis]

So, is anyone getting hang-ups on loading, amid module manager patching? I used the error correction patch, but now I can't complete loading (with or without DDS files supplied by Insane Plumber). Not sure what could be causing it, I know removing DR fixes the issue though.

Guess I'll look for incompatibilities.

EDIT: I'll be damned, it was ol' K&W Rocketry. Guess something about it and DR at the same time upsets Module Manager--it happens either with 0.90-compatible KW Rocketry and the up-patched version. Naturally, this isn't your problem Starwaster, but I want to share it in case anyone else runs these two mods together (especially if they've got it working somehow).

Edited May 13, 2015 by Synthesis

[jrandom]

Loaded fine here (using the new .cfg file provided by Starwaster a few posts up).

[somnambulist]

// Kill the unwanted resource

!RESOURCE_DEFINITION[AblativeShielding]

{

}

DO NOT DO THAT. There's absolutely no need to delete the resource unless you want to potentially break people's games. You're already patching the resource in every part and ModuleHeatShield to use the new resource. LEAVE THE ORIGINAL RESOURCE DEFINITION ALONE.

[Starwaster]

I'm getting .cfg errors from Module Manager on startup...am I doing something wrong?

Gentles all, pray rest your sphincters, recall the wise words of Nick Fury, and apply or not such single_ablative_resource.cfg ModuleManager files as you might find appropriate:

// Kill the unwanted resource


!RESOURCE_DEFINITION[AblativeShielding]
{
}


// Patch all the resources


@PART
[*]:FINAL
{
    @RESOURCE[AblativeShielding]
    {
        @name = Ablator
    }
}


// Patch all the modules


@PART
[*]:HAS[@MODULE[ModuleHeatShield]]:FINAL
{
    @MODULE[ModuleHeatShield]:HAS[#ablativeResource[AblativeShielding]]
    {
        %ablativeResource = Ablator
    }
}

Feel free to swap "Ablator" and "AblativeShielding" over, if you prefer the other name. Either way, consider yourself freed from the terrifying scourge of redundant resources, able once again to see the status of all your mixture of heat shields on a single nanogauge/resource panel line, and in general, peace and prosperity unexampled returned once more.

...I go now to bring joy to the rest of Kerbin.

-c

(P.S. Otherwise, great update, @Starwaster!)

Best case scenario is that this is a solution looking for a problem

Worst case scenario, is that it causes problems.

Fair warning: I won't give support to anyone using this if it looks like the problem stemmed from this until they return to a supported configuration.

[Synthesis]

Loaded fine here (using the new .cfg file provided by Starwaster a few posts up).

No, it's definitely something from KW Rocketry (both old and new versions). No idea what though, the pre-1.00 version didn't cause incompatibility (but that was just there for the parts).

[Cerebrate]

DO NOT DO THAT. There's absolutely no need to delete the resource unless you want to potentially break people's games. You're already patching the resource in every part and ModuleHeatShield to use the new resource. LEAVE THE ORIGINAL RESOURCE DEFINITION ALONE.

Sure there's a need (or at least a non-technical reason). It cleans up the resource list.

Now, maybe I'm a little conditioned by some of my time spend making pre-Community-Resource-Pack many-mod installs work nicely, but for myself, I found it kind of a pain in the ass to remember which of the four kinds of hydrogen and the three kinds of water (some identical and some not) I was using today, and so prefer to cull the ones no longer relevant right out of the list such that I'll never see 'em, scroll past 'em, or inadvertently define or install something elsewhere using 'em without an error showing up.

But, sure, this may break your game if you install the .cfg file and already have craft in your save using AblativeShielding. Thing is, though, it'll also break your game if you remove the removal of the resource definition - it's just that instead of getting an error when you try to load your save, you'll find out about it when your re-entering vessel plunges to a fiery and unpleasant death because its heat shields aren't working right. This, to me, is not a net improvement.

-c

[Cerebrate]

Best case scenario is that this is a solution looking for a problem

Worst case scenario, is that it causes problems.

Y'know, it's not like no-one's mentioned the problem it's supposed to solve. Having/using both resources means that people using mods that display heat shield remaining, or things like kOS scripts that monitor heat shield resource remaining, or indeed mods that provide more heat shields which might be compatible with either standard, find themselves having to track two places instead of one place. Or, y'know, carefully ensure that every rocket they built, .craft they have built, or subassembly they have saved is using the right combination of heat shields and settings to all be using the same one. This is, not to put too fine a point on it, irritatingly inconvenient. (And not a theoretical problem, either. This would be a noticed-it-on-literally-my-first-run-with-7.0.1.-installed problem.)

Sure, that may not be a problem for you, but permit me to suggest that that by no means implies that it's a problem for no-one.

Fair warning: I won't give support to anyone using this if it looks like the problem stemmed from this until they return to a supported configuration.

As is right and proper.

Speaking of support - and, yes, I did remove that MM config first - before I suggest this is a bug, is there another reason why, with a Mk. 1 pod with 1.5 m stock heatshield attached below reentering tail-first, the AblativeShielding on the pod should deplete much faster and more completely than the Ablator on the heat shield (12.6/100 versus 178/200, coming back from a 100 km circular orbit with a 30 km periapsis)? The former shows pyrolysis flux and ablation an order of magnitude higher, even though intuitively it should be protected by the shield.

-c

Edited May 13, 2015 by Cerebrate

[Svm420]

I wanted to report I get the same issue I had earlier with the NREs with Pfairings fairing rings. They are 0 mass in the cfg, but gan mass upon creation procedurally, so I don't ge why they have an issue, but the fairing sides themselves don't. I checked with just a fairing side with no ring and had no issues, nor any issues with Pparts srbs or tanks. So it maybe bets to implement that lower limit to avoid any future issues.

[Starwaster]

Y'know, it's not like no-one's mentioned the problem it's supposed to solve. Having/using both resources means that people using mods that display heat shield remaining, or things like kOS scripts that monitor heat shield resource remaining, or indeed mods that provide more heat shields which might be compatible with either standard, find themselves having to track two places instead of one place. Or, y'know, carefully ensure that every rocket they built, .craft they have built, or subassembly they have saved is using the right combination of heat shields and settings to all be using the same one. This is, not to put too fine a point on it, irritatingly inconvenient. (And not a theoretical problem, either. This would be a noticed-it-on-literally-my-first-run-with-7.0.1.-installed problem.)

If you have a mod that displays heatshield remaining, they should first be checking the heat shield module to see what it's been configured to use instead of hard coding it to only look for one.

Same for KOS, reflect into the class and grab the ablativeResource value. It's a public readable field

If you think these things are problems now, what happens if someone decides to make a custom heat shield resource? People need to code more flexibly to allow for those contingencies.

Speaking of support - and, yes, I did remove that MM config first - before I suggest this is a bug, is there another reason why, with a Mk. 1 pod with 1.5 m stock heatshield attached below reentering tail-first, the AblativeShielding on the pod should deplete much faster and more completely than the Ablator on the heat shield (12.6/100 versus 178/200, coming back from a 100 km circular orbit with a 30 km periapsis)? The former shows pyrolysis flux and ablation an order of magnitude higher, even though intuitively it should be protected by the shield.

-c

insufficient information. Are you saying you're running a reentry with both shields attached? It should certainly be protected from convective heating.

Did you install that set of configs that someone put out to fix stock reentry before DRE came out? Or any other mod that alters conductivity? If so, then heat could conduct into the Mk1 pod and the shield doesn't care where the heat came from. If you get it up hot enough it will ablate.

Enable thermal debugging (Alt-F12->Physics->Thermal then enable Display Thermal Data in Action Menus) Then right click the Mk1 pod. Every positive flux value is heat coming in. Every negative value is heat going out.

l

Once you have established the source of the heat: The Mk1 pod is configured to deplete faster.

[GrimerX]

I just wanted to say "Thank you" for this wonderful mod, Starwaster. I know it takes a lot of hard work to put out something like this.

Re: the ongoing debate -- I hope it doesn't drown out useful discussion. I was disappointed when ferram felt he needed to close his dev thread.

FWIW, I think you chose the right of the two - neither is ideal or there wouldn't be such a debate :-) But better to choose the one with less complexity. If you're writing kOS scripts then you're an expert and can decide whether to deal with two resources, mod them together or whatnot. And/or suffer the consequences. For everyone else, no big deal. :-)

Anyway, thanks again! I've been looking forward to this to complete my 1.0 mod collection :-)

[mobiusune]

very nice job starwaster !

Ok, and now the question: can anyone tell my why i have to but all the heatshields the wrong way around to attack them ?

wrong:

right, but why ?

Edited May 13, 2015 by mobiusune

[NathanKell]

For the record, RO will totally be using SLA and PICA and various other resources.

[ss8913]

Are there any current known incompatibilities between this version of DRE and any other mods? I ask because I just installed DRE and it dropped my frame rate to about 3. Going to restart with the new .cfg and see if that helps. I suppose I'm most concerned with compatibility with the current FAR release. Anything known?

Getting a lot of:

[ERR 18:53:36.377] Serialization depth limit exceeded at 'ThermalLink'. There may be an object composition cycle in one or more of your serialized classes.

In my logs, as well, which I *think* is related.

[Cerebrate]

For the record, RO will totally be using SLA and PICA and various other resources.

@NathanKell, which will all have appropriately different properties, right?

...anyway, look, t'be clear, in all this I am not trying t'say that it's Starwaster's job to solve this problem for me, or anyone else's for that matter, whatever I may personally think of the virtues of havin' multiple identical resources hanging around or suggest as a possible improvement, emphasis on not demandin'.

(And for that matter, you should see the pull requests I have in the works to make various mods, like my fuel/oxidiser gauges, play nicely and sensibly with Real Fuels 10 once I get my hands on it.)

'Cause much as I'd like a world where everything is coded with perfection, consistency, and universal agreement such that I can drop 80 mods into my GameData and have 'em all sing in perfect harmony, sight unseen, we don't live there, no-one's being paid to take us there, and it's the multi-mod user's job to glue 'em together with as much ModuleManager code and other assorted hackery as it takes, no support expected. I'm fine with all of that.

I might, though, take it a little amiss to be told that my problem ain't a problem, 'cause I'm the one who's got it, and it's a damn problem. (Well, it was. Works fine now.)

-c

[Starwaster]

very nice job starwaster !

Ok, and now the question: can anyone tell my why i have to but all the heatshields the wrong way around to attack them ?

wrong:

http://www.pic-upload.de/view-27014264/pic_1.jpg.html

right, but why ?

http://www.pic-upload.de/view-27014268/pic_2.jpg.html

I can't see your pictures at all but you're saying you have to turn them upside down? Re-download the mod. Sounds like you don't have the latest version.

Are there any current known incompatibilities between this version of DRE and any other mods? I ask because I just installed DRE and it dropped my frame rate to about 3. Going to restart with the new .cfg and see if that helps. I suppose I'm most concerned with compatibility with the current FAR release. Anything known?

Getting a lot of:

[ERR 18:53:36.377] Serialization depth limit exceeded at 'ThermalLink'. There may be an object composition cycle in one or more of your serialized classes.

In my logs, as well, which I *think* is related.

I see those thermallink errors in pure stock. I don't think they're related to your issue.

I need to see an entire log file, output_log.txt or player.log (if Mac or Linux)

Edited May 13, 2015 by Starwaster

[mobiusune]

I added the pictures in my post. I tried to reeinstall the mod but its still the same problem, and i have your newest version (7.0.1) installed.

[ss8913]

I can't see your pictures at all but you're saying you have to turn them upside down? Re-download the mod. Sounds like you don't have the latest version.

I see those thermallink errors in pure stock. I don't think they're related to your issue.

I need to see an entire log file, output_log.txt or player.log (if Mac or Linux)

What's the best way to upload one, I'm assuming NOT to just paste it as text here? I have one ready to share with you, though. Never attached a file on these forums before, though.

[DianonForce]

So, is anyone getting hang-ups on loading, amid module manager patching? I used the error correction patch, but now I can't complete loading (with or without DDS files supplied by Insane Plumber). Not sure what could be causing it, I know removing DR fixes the issue though.

Guess I'll look for incompatibilities.

EDIT: I'll be damned, it was ol' K&W Rocketry. Guess something about it and DR at the same time upsets Module Manager--it happens either with 0.90-compatible KW Rocketry and the up-patched version. Naturally, this isn't your problem Starwaster, but I want to share it in case anyone else runs these two mods together (especially if they've got it working somehow).

No, it's definitely something from KW Rocketry (both old and new versions). No idea what though, the pre-1.00 version didn't cause incompatibility (but that was just there for the parts).

I run in the same problem, but i managed to fix it, but i dont know if it is the right way. I posted it a few minitus ago in the KWRoketryThread -> link

very nice job starwaster !

Ok, and now the question: can anyone tell my why i have to but all the heatshields the wrong way around to attack them ?

wrong:

http://www.bilder-upload.eu/thumb/9d7755-1431502988.jpg

right, but why ?

http://www.bilder-upload.eu/thumb/2c2ea8-1431503020.jpg

This is because the bottom node isn't in the corrct angle for this part. If i remember right there is an patched .cfg a few pages befor this. Or you chanage the value by you own, you must change it for every part in DRE from somwhat like this

node_stack_bottom = 0.0, -0.01, 0.0, 0.0, [COLOR=#ff0000][B]1.0[/B][/COLOR], 0.0, 1

to this

node_stack_bottom = 0.0, -0.01, 0.0, 0.0, [COLOR=#ff0000][B]-1.0[/B][/COLOR], 0.0, 1

Edited May 13, 2015 by DianonForce

[Ser]

The Columbia disaster occurred because a piece of foam punched through the ablation to the wing surface below, so that the wing surface was directly exposed to the heating.

Exactly what I've said. Every little fraction floating around is an armor piercing shell at that speeds and pressures. So it would be nice if it was implemented some day, that should make reentry really deadly, not just a little dangerous. But seems like Starwaster haven't read my post...

Starwaster, do you mind if I put my dirty hands in your code if I ever find the time?

Edited May 13, 2015 by Ser