Starwaster

Last item first: Should fire effects exist in a vacuum? Maybe, maybe not. But they're there to provide visual feedback that something is wrong and and that the part is taking damage. Which brings us to the first item: Stock KSP has no concept of part damage. The part has maxTemp and skinMaxTemp properties. If the part's temperature or skin temperature exceeds those values then the part is instantly destroyed. That's one of the things that DRE changes by introducing the concept of gradual damage. Part failure is soft(er) and gradual. If you see flames, your part is being damaged which is tracked by DRE. The way it works is that DRE adds 'operational' temps. which are lower than the stock maxTemp. My rule of thumb (YMMV) is that maxTemp should be the part's vapor temperature and operational temps should be either the part's melting temperature or the temperature at which its material would weaken or soften. The amount of damage dealt, IIRC, depends on the ratio between operational temp and maxTemp. If the operational temp wasn't explicitly configured then it is 85% of the maxTemp. (97.5% for engines) Setting it to the same value as the part's maxTemp would effectively disable the damage system. So, TL;DR, DRE has a soft damage system that KSPIE is bumping into because its parts aren't configured to reflect whatever material the radiators are supposed to be made out of. I don't use those radiators myself nor do I use whatever engine or reactors are driving those temperatures up so high so I'm not sure what an appropriate configuration would look like. I'm not even sure what kinds of temperatures they're actually experiencing.

Although it says it supports Deadly Reentry, it references the stock ModuleAblator and not ModuleHeatShield, which is DRE's extension of ModuleAblator. That's probably not too much of a problem since DRE will patch any references to ModuleAblator it finds. The main difference between the two being that DRE's version has handling for what happens when ablator resources are exhausted. It also establishes soft limits with gradual failure for max temperatures of parts, which you may or may not want to do anything with in the heat shield config. Also, I see that you are thinking about doing a heat shield with a door for engines. If you're interested in suggestions, might I suggest an inflatable shield with a hard cap? (this could be a single part or two parts; a hard heat shield with openings for engines + inflatable attachable shield extending the diameter). What I have in mind is based on a concept they are considering for manned Mars missions. (see below)(note landing gear. The shield would not be jettisoned, rather would be retained and inflatable retracted after landing)

I just have to post this....

If you put the engines back, see if you can duplicate the issue then check the log file and you may well find 'whatever reason' it happens.

Found it. I commented out the entire section referenced below. I probably commented rather than outright remove because I wasn't sure I wasn't totally screwing something up, but the impact was such that I stopped ever thinking about it for four years until you reminded me. So the effect apparently wasn't exactly catastrophic. https://github.com/MuMech/MechJeb2/blob/34a8654ccba60d46f745c8fd4e8bf46f0800daa7/MechJeb2/MechJebModuleThrustController.cs#L825-L841

So I started up KSP and loaded up a craft because it's been long enough that I really don't remember what SmartRCS does (other than the post of mine you quoted) Apparently I don't have that problem anymore and I don't remember what I did to eliminate it. I'm using a custom MJ2 branch because I didn't like certain changes that were made and also to test out certain ideas that I had been thinking of submitting but never did. Anyway, I suspect that I hacked on SmartRCS to prevent it from making changes to my RCS at all (I probably just literally am not allowing it to touch my RCS at all) I'm still looking to see where in the code I did that.

This is the way.

I think the solution was not to use smart rotation.... Honestly I don't remember what I do about it for myself. I'll look into it

It's not simulating reality. It's broken. It's a bug. It's defective.

Depends on if you're running with Real Fuels or not. If you were then you would probably already have the ability to load methane in your tanks and be in need of configs for the engines. Are you? If so then I can probably help.

This is wrong. The lifetime of spacecraft docked at the ISS has nothing to do with 'dock drift'. That's just a KSP thing resulting from math errors with the craft as it is continously serialized/deserialized over time. The reason why real world spacecraft have to be undocked and de-orbited is due to deterioration of the craft and its propellants and other consumables.

Is this an across the board permanent change you want? You can make a patch that sets sunTracking to false in all ModuleDeployableSolarPanel.

Oh god.... that bot.... that's horrible.... He has to stay locked up in that tiny little cabinet? No wonder he looks unhappy. And I bet he's got a pain in all the diodes on his left side that he's asked to have replaced...

24 hours between launches is much more likely than a week. No point in leaving a tank full of hydrogen up there for an entire week if you don't have to.

@FinetalPies that was pointed out several posts above yours and a patch was provided to correct the problem

Probably? Most of the required component launches fall inside of what SLS can launch though there might be some downsizing required. What you refer to as Copernicus consisted of a number of different proposals which has evolved over time. But yes, it's possible. Here's some documents that might interest you. Some of them are quite detailed http://large.stanford.edu/courses/2014/ph241/wendorff1/docs/aiaa-2009-5308.pdf https://ntrs.nasa.gov/api/citations/20150004421/downloads/20150004421.pdf https://www.nasa.gov/sites/default/files/atoms/files/sls_core_stage_fact_sheet_01072016.pdf

That's used to determine how much heat is removed along with the heatshield material that got ablated away. It's ablated amount * density * specificHeatCapacity * pyrolysisLossFactor

No, that does not happen to me. What other mods are installed? If this is easily reproducible then let a ship explode and then get the logs and upload them somewhere like Dropbox where they can be accessed by others. Post the links here where they can be downloaded

As you've figured out, this is from stock (Squad) code. Specifically it comes from ModuleAblator from which ModuleHeatshield derives. The formula for loss is: lossConst * Math.Exp(lossExp / infoTemp) * ablator maxAmount * ablator density * 1000 where infoTemp is 2000 by default. (you can add this in as a custom temperature to check against in ModuleHeatshield / ModuleAblator) My advice to you is to save yourself some pain and touch none of the fields you referenced above except for lossConst Or if you absolutely must change the others then plug that formula into your spreadsheet.

<DELETED>

<DELETED>

Make sure your mouse cursor is not over any MJ window when you press that slash key. That means you have to conscienciously clear the warp setting in the MJ menu and then move the cursor out of the window.

The landing GUI and associated code is a separate issue and there is a definite long standing bug in there in that the landing code isn't checking for conditions (that should result in disabling warp) while currently in warp. The main two conditions being whether or not the option is enabled for warp and whether the landing guidance is still in effect. Either of those should cause warp to be cancelled. Furthermore, once warp has been enabled, it is still treated as enabled even if the warp option is disabled IFF landing guidance is still enabled. The end result being that warp must be disabled (in the Landing Guidance window) AND auto landing must be cancelled before manually stopping warp (and you must manually stop warp). Otherwise, the landing guidance will re-enable warp.

Disable warp in MJ before pressing slash.

It's better to experience painful things. Pain is an excellent teacher. Without pain, learning is impossible. You have now learned that there are things in the game that will cause you pain necessitating a choice between reload or loss of Kerbal or ship.