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

[Prasiatko]

Confirm what you are getting appears to be between FAR and procedural parts.

Further testing involving sending a tank through the atmosphere using hyper edit indicates a FAR bug possibly.

I used hyperedit to put a tank in orbit with AP 1Mm PE 22km and it flew through that atmosphere barely altering its orbit.

[dlrk]

What thermal settings should I use for 64k? I'm trying to set it up, and I'm not getting much heating.

- - - Updated - - -

(also not getting visual effects)

[Starwaster]

What thermal settings should I use for 64k? I'm trying to set it up, and I'm not getting much heating.

- - - Updated - - -

(also not getting visual effects)

64k would be hotter, not cooler. Unless you have something else running altering physics. Are you using FAR? If so, see the answer I gave about FAR above.

[dlrk]

Indeed I'm using FAR. I'll try downgrading to a previous version, thanks

[Tellion]

What thermal settings should I use for 64k? I'm trying to set it up, and I'm not getting much heating.

- - - Updated - - -

(also not getting visual effects)

There is also a patch for 64K that gives reasonable results with capsules (don't try spaceplanes though), it should be in the last pages of the 64K thread. It is applied to stock settings however, so throwing DRE into the mix might cause weird results depending on what is applied last.

[kingoftheinternet]

Is it possible to remove the currently-useless stock toolbar button? Most mods have a way to choose between using the stock toolbar or the common mod toolbar (where it can be hidden completely, if you want).

[Starwaster]

Is it possible to remove the currently-useless stock toolbar button? Most mods have a way to choose between using the stock toolbar or the common mod toolbar (where it can be hidden completely, if you want).

No. (ten characters)

[steve_v]

No.

Err, any particular reason for that?

I know the stock toolbar is getting a revamp for 1.1, but right now space there is a scarce commodity and, IMO, far too many mods are adding "mostly useless" buttons that would be better served by blizzys toolbar - where they can be hidden or moved to a more convenient spot on the screen.

[Temeter]

I'm just fine with the stock toolbar. It's not like there is anything else up there to make better use of said space.

[Starwaster]

Err, any particular reason for that?

I know the stock toolbar is getting a revamp for 1.1, but right now space there is a scarce commodity and, IMO, far too many mods are adding "mostly useless" buttons that would be better served by blizzys toolbar - where they can be hidden or moved to a more convenient spot on the screen.

No reason. I didn't implement a means by which it could be hidden so the answer to the question is 'no'.

I don't have anything against blizzy's toolbar but implementing it just hasn't ranked high enough in priority for me to devote the time to it.

If anyone wants to code Blizzy support, feel free to write it up and do a pull request.

[kingoftheinternet]

I'm just fine with the stock toolbar. It's not like there is anything else up there to make better use of said space.

I have 14 mods that don't let me remove buttons from the stock toolbar. It's a little crowded. Some of them actually do something, at least.

[Starwaster]

I have 14 mods that don't let me remove buttons from the stock toolbar. It's a little crowded. Some of them actually do something, at least.

This one will too, but since 90% of its previous functions are now done by stock, it all got gutted until I can get new menu functionality going.

Either the next update or the one after that will have a real menu. (depending on if I want the next update out sooner or later)

[NathanKell]

Starwaster, couple issues with current DRE:

1. You added shielding to the Proc Fairing sides but didn't change their cost to account for it. That means fairing cost is negative.

2. You seem to have some legacy ModuleHeatShields being added, and that causes ModuleHeatShield to throw on fixed update. Verify that every ModuleHeatShield you add has the correct fields.

[Starwaster]

Starwaster, couple issues with current DRE:

1. You added shielding to the Proc Fairing sides but didn't change their cost to account for it. That means fairing cost is negative.

2. You seem to have some legacy ModuleHeatShields being added, and that causes ModuleHeatShield to throw on fixed update. Verify that every ModuleHeatShield you add has the correct fields.

1. That's very interesting; I didn't realize there was a bug with PF where adding resource to the fairing side could break cost. And that's what it is; it has nothing to do with me not changing cost and that probably won't help because the cost is determined procedurally. Seems like adding a resource where amount = 0 is what triggers it. Increasing amount results in a positive cost value. Picking the fairing up by the base and setting it down again also fixes it. So yeah, that's a bug there. I'll see if I can work around it, if not then I'll remove the shield.
   
2. Ok, specifics? What part? What error? Logs? MM cache file? Throw me a bone here? (need the info...)
   

[NathanKell]

On 1, try adding a cost and see what happens. AFAIK PF only uses GetModuleCost, which increases cost beyond the base, so setting base cost to 801 should be fixing it (1 + resource maxAmount * resource cost). I find it very hard to believe that there's a bug in proc fairings regarding resources, since it doesn't deal with resources. That's simply stock behavior: stock sums up part.partinfo.cost + foreach module, module.GetModuleCost - foreach resource, (resource.maxAmount - resource.amount) * resource.unitCost.

On 2, apparently I'm going nuts. Ignore me.

(It must be some addon--perhaps B9 Pwings--applying an old-style DRE heatshield. I could have sworn I saw something in the DRE cfgs last night or the night before, but...it's not there now. >.>)

[Prasiatko]

For anyone else with problem bug i had on last page is with SETi tech tree.

[Starwaster]

On 1, try adding a cost and see what happens. AFAIK PF only uses GetModuleCost, which increases cost beyond the base, so setting base cost to 801 should be fixing it (1 + resource maxAmount * resource cost). I find it very hard to believe that there's a bug in proc fairings regarding resources, since it doesn't deal with resources. That's simply stock behavior: stock sums up part.partinfo.cost + foreach module, module.GetModuleCost - foreach resource, (resource.maxAmount - resource.amount) * resource.unitCost.

Stock behavior doesn't result in abnormal costs when a resource's amount is set to 0. I'm giving the stock procedural fairings the same treatment and I'm not having to do anything odd like increasing the cost of the part. It's not sensible to think that adding a resource necessitates altering the base cost to avoid buggy part costs. Either way there's a definite bug at work here

For anyone else with problem bug i had on last page is with SETi tech tree.

The problem was that parts weren't heating up on reentry, correct?

Well this wouldn't be the first time we've had problems with that mod

Is the problem confirmed in the SETI thread? Is there a solution? Or is it being worked on or is it considered to be someone else's problem?

Edited July 19, 2015 by Starwaster
merging posts

[Prasiatko]

Yeah should be fixed in next patch. It only occurs when combined with FAR as seti overwrites some of the modules FAR included apparently.

[dlrk]

I had that same bug without using SETI, and it got fixed by replacing my physics.cfg with one from a fresh install

[NathanKell]

Answered on github.

[ss8913]

Not sure if this is specifically a DRE problem, but it definitely started when I installed/updated DRE a few days ago (ie it could be an inter-module conflict): Shielded docking ports. Closed, they're fine. Open one and the heat spikes to 200% of maximum and it instantly explodes. Can replicate with just a command pod and a shielded docking port. Open docking port and *boom*

Should be noted that I'm also using FAR (latest), if that makes a difference. Also noticed that it's MUCH MUCH harder now for space-planes to re-enter. I've used FAR+DRE since 0.24 and my normal re-entry method is causing the cockpits and other critical parts to explode from overheating at like 55km up. I'm starting from a 100km circular orbit, burning retrograde 1300km downrange (as per MJ2), setting my landing point near KSC.. then pointing due east, 0 degrees pitch, locking speedbrakes on, and riding it in. That's always worked before, and now it doesn't - is this potentially due to some kind of bug (the cockpit seems to get super hot super fast, and I thought these were shielded? Mk2 and Mk3 cockpits) - or is this now more realistic, and I need to change my procedure?

[Starwaster]

Not sure if this is specifically a DRE problem, but it definitely started when I installed/updated DRE a few days ago (ie it could be an inter-module conflict): Shielded docking ports. Closed, they're fine. Open one and the heat spikes to 200% of maximum and it instantly explodes. Can replicate with just a command pod and a shielded docking port. Open docking port and *boom*

Ok, FAR could be an issue.... in the past it has affected the radiative area. I'm not able to make it explode.

HOWEVER.

Ooops.

        MODULE
        {
            name = ModuleAnimation2Value
            animationName = dockingring
            valueName = maxTemp
            valueCurve
            {
                key = 0 2700 0 0
                key = 0.1 1250 0 0
                key = 1 1 0 0
            }
        }

Major OOPS on my part. Actually I'm not sure WHY it doesn't explode for me, FAR or no FAR. But its overheating gauge is right on the edge. Probably wouldn't take too much to push it over the edge. I'll have a fix out in the next day or two. In the meantime, edit your DeadlyReentry.cfg file and see that second 1 on the last key? Change that to key = 1 1250 0 0. That will stop it.

Should be noted that I'm also using FAR (latest), if that makes a difference. Also noticed that it's MUCH MUCH harder now for space-planes to re-enter. I've used FAR+DRE since 0.24 and my normal re-entry method is causing the cockpits and other critical parts to explode from overheating at like 55km up. I'm starting from a 100km circular orbit, burning retrograde 1300km downrange (as per MJ2), setting my landing point near KSC.. then pointing due east, 0 degrees pitch, locking speedbrakes on, and riding it in. That's always worked before, and now it doesn't - is this potentially due to some kind of bug (the cockpit seems to get super hot super fast, and I thought these were shielded? Mk2 and Mk3 cockpits) - or is this now more realistic, and I need to change my procedure?

Make your reentry angle a lot shallower. That sounds way too steep. You're going to want to be halfway around the planet, roughly. I can't say for sure exactly if it's more or less with FAR. Probably more than halfway?

And make your pitch about 35 degrees. You have some leeway but you want to increase your cross section. Increase drag and lift and do as much braking as you can high up.

One final warning: If you have the overheat gauges on, they WILL light up, even following my advice. That's the skin temperature. However, as long as you're not coming in too steep then it'll be in thermal equilibrium and not explode. (though again; I haven't done a reentry with FAR very recently so you might not be able to do enough braking high up. I may need to bump up the skinMaxTemp value on those parts. But it works in stock aerothermo)

Edited July 21, 2015 by Starwaster

[ss8913]

35 degrees huh? That's new. I'll try it. Glad I helped find a bug.. I'll go edit the .cfg

[ss8913]

Starwaster - the update to the .cfg fixed the docking port problem, and using a 35-degrees-of-pitch re-entry fixed that problem as well. Well, for my spaceplanes with standard re-entry. My Pelican-class can engine brake all the way down so it wasn't affected by this but my more conventional designs thank you very much

Is it just me or is heating a mess on modded installs right now? Seems like if I combine stock radiators with Interstellar radiators in any way (including Mk2 cargo bays which you have to toggle the internal radiator off in-flight, can't do from SPH/VAB), things like to randomly explode.. especially when docking with another craft. I don't think this is a DRE issue specifically, but more a general thing esp. with the modlist I have, since 1.0.3+ ... 1.0.2 didn't have this problem.

[rumham]

Ok...first I really like using DR and have never had a problem...until now. But this version ain't behaving for me. During reentry parts don't experience FLUX changes so nothing heats up. And sometimes the flux values visually stutter , like its looking for the right numbers. I've played with the games debug thermal settings with no results. The games stock reentry heating is set to 120%. I'm running very few other mods. Everything worked before all the updates. Not 64bit. 1500+ hours played.