Starwaster

He knows; it's coming.

You could use Procedural Parts and spec out a PP heat shield to a custom size. The last time I checked though, PP was not supporting DRE with its procedural heat shields and I don't know if that has changed yet. (I would expect it to as several of the developers of PP use DRE)

I can't think of any compatibility issues that I experience with the FLAT in 1.0.4 ... There's certainly nothing in the pack that would cause the staging issues you described and in your own words it stopped happening when MechJeb's autostaging was disabled. It would help to know more about the craft, some pictures or a craft file. But something about that craft makes MJ think that it needed to keep staging, either its design or a decoupler from another mod that MJ doesn't recognize as a decoupler. Those are the only two reasons I know of behind unwanted staging in MJ. As to lack of electric charge, an omission at worst; a choice by Porkjet at best. You're certainly entitled to the opinion that it should have electric charge but I point out to you that there are quite a few crewed modules do not have resources at all. (keep in mind that unless it's a command pod and/or has reaction wheels that most crewed parts don't have ElectricCharge resource)

That's not a bug. Heat shield ablation starts at 500K. If it gets that hot it will ablate. Staging is irrelevant.

Look under Structural.

Not familiar with Behemoth, but if you say it's not the lightbulbs then I guess it's that. Has it properly been updated for 1.0? Engines scale their heat output by mass. (or by thermalMass ... I think) I guess to actually guarantee that they overheat when they 'need' to. If someone has an engine with high output before 1.0 then it might be giving the engine a LOT of heat ...

Jettison the shields after they're no longer needed.

Wow, think it checks for NaN but maybe not Infinity... You might try quick saving then reloading, that might let it start radiating ... otherwise you're editing your save file to fix the temperatures. Long term, what you need is to add more radiators or less engines.

And I don't see z fighting either.

I don't get it. I looked at those parts and I'm not seeing any framerate loss that can be pinned on those parts and certainly not based on what animation state they're in. I do notice my framerate does fluctuate quite a bit, jumping from 60 down to 20-30, but it does that with me just sitting there even with the simplest of parts. If someone notices framerate loss, they're going to go looking for it, and it's human nature to try to pin it on the first thing you happen to be checking out when the problem hits. In the absence of a better description of the problem with solid repro steps that's what I'm going with.

Porkjet, I suggest reducing heatConductivity so that it is no higher than 0.001, or maybe even lower. Given that you're using the actives, the end result of high conductivity is that they are going to end up leaking most of that heat back into the vehicle through adjacent parts. Maybe also set skinSkinConductionMult to match.

Ooooh looks good

Well I just did a run through of Mun -> Kerbin reentry and it did just fine. I did panic a little when the heat shield didn't ablate as fast as I thought it should... until I remembered it was the SDHI shield which isn't supposed to ablate as much. So, at the very least it's not interfering that I can see.

To weigh in on this too, the next version of Deadly Reentry - due to changes in stock thermodynamics which meet the needs that I had for DRE - will limit its handling of heating to configuration tweaks to the stock system. The next update after that would likely have any Real Heat specific tweaks, IF I think they're necessary for either compatibility or to take advantage of Real Heat, but I haven't yet had a chance to play with RH so I'm not sure if I'll need or want to. Now, that said, Deadly Reentry isn't just about heat. Don't forget, there's G forces! Things catching fire! (insert Beavis voice screaming FIRE! FIRE!). Maybe room for other things like cabin heating or something... but that's probably going out of scope so maybe not. But yeah, as far as implementing the heating side of things, I'm pretty happy with where things are at. (currently, DRE isn't even making use of Modular Flight Integrator and I'm not sure it will need to)

See his post here: http://forum.kerbalspaceprogram.com/threads/81239-Stockalike-RF-Engine-Configs-v2-1-7-6-21-15?p=2059484&viewfull=1#post2059484 In summary, instead of MODULE { name = ModuleEngineIgnitor ignitionsAvailable = 2 <stuff deleted for clarity> it should be like this ModuleEngineIgnitor { ignitionsAvailable = 2 <stuff deleted for clarity> Aaaaaand you'll have to go through ALL of the files. Or at least the ones that that contain engines that you use. (which should hopefully shorten it quite a bit for you)

If it did, would it still be 'stockalike'?

Dammit I was on autopilot when I was hammering those out.... thanks for catching that. Too all: Apologies for the delay in getting this out but it's been a bad couple of weeks around here and I wanted to spend more time going over things before releasing. (I'm basically a full time volunteer for a feral cat shelter - by which I mean I live here and am on call 24/7 - and it's been a rough few weeks for our older cats)

Not a clue, but you just inspired me to start using those track parts again.

The hiss sound happens anytime you stage even if there are no parts to be staged, even if you make a blank stage... so it's not really controllable in anyway by Sumghai... And as far back as 0.24.2, I can confirm that the stock decoupler has inserted a staging icon regardless of whether the decoupler was capable of being staged or not. However, the decoupler that SDHI uses for the service module is an extension of the stock decoupler so it's probable that I could override that behavior if Sumghai agrees that that would be desirable. I think that requires some thought though to guard against unforeseen consequences. Now, as far as the problem you described with setting staged = true, that sounds like something that would happen if you tested with an already staged part on the launch pad. (that is, you tried staging an SDHI service module, couldn't, exited game and set staged = true, then loaded game back up and went right back to that ship. THAT would definitely cause the part to decouple as soon as it loads in)

Another option is to use my Animated Decouplers in place of stock decouplers. (It's not necessary to specify an animation; it'll default to just being a decoupler. It is necessary to point the cargo bay module at my decoupler module instead of the animator module however)

Probably coincidence. I don't use FAR and I can repro your bug just fine: The temperature of those parts was in the trillions. Basically well past the vapor point of those parts. (I had Ignore Max Temperature turned on)

A larger part of the reason why is public perception. People were starting to turn against nuclear anything, especially atmospheric use. That's also a large part of why we don't have any functioning flight ready nuclear rockets yet. (the end of the space race and the push for manned Mars missions is the other)

In actuality, global conductivity was cranked up way too high making it easy to wick away heat from exposed parts. Press alt-F12 and set conductivity to 1.0, try that with the radiators again and report back with the results.

thermalMassModifier = multiplier applied to the part's thermal mass. (the higher thermal mass is, the more energy it takes to heat it up one degree. High thermal mass is good for heat sinks. Low mass means that heat loss through radiation has more impact. This is how the shuttle's tiles worked) heatConductivity = heat transfer between parts (part.temperature <-> part.temperature) emissiveConstant = a multiplier to radiation, both incoming and outgoing. High emissive means it takes more heat from incoming thermal radiation, but it also means it is a good radiator. This is why radiators are often black. (white painted radiators such as the ISS uses are good reflectors in the visible range but good radiators in the IR range. KSP does not simulate scenarios such as this). (The basic formula for radiation is temperature^4 * surface area * Boltzmann-Stefan constant) skinInternalConductionMult = multiplier applied to conduction from a part's skin to its internal (skin.temperature <-> part.temperature) skinSkinConductionMult = multiplier applied to conduction between two attached parts from skin to skin (skin1.temperature <-> skin2.temperature) skinMaxTemp = skin temperature higher than this destroys the part. If this field is not provided then the part's maxTemp is used. skinMassPerArea = another multiplier applied to skin thermal mass. radiatorMax = This percentage of the part's maxTemp is used by active radiators to determine when they should start sucking heat out of the part radiatorHeadroom = Also used by radiator parts but I'm not clear how... I think it applies only to the radiator part to determine how close it is allowed to get to its own maxTemp Those are the ones you specified and a few extra.

Maybe up to a point, but they'll get saturated eventually and be overwhelmed.