Starwaster

Yes look for the clamshell mod. And don't worry about space junk. The fairing pieces are non-persistent.

I bet it doesn't happen with larger parts; both larger fairing base and larger payload. I'm calling it a stock problem. It's known to happen with very low mass parts. Low mass = low thermal mass = rapid temperature changes when heated. Default conduction factor of 20 is also a necessary component here. Change any one of these (more mass or lower conduction factor) and this won't happen. BTW, for giggles, press alt-F12 and under Cheats, check Ignore Max Temperature. Press F11 to enable Temperature Overlay. Watch how quickly it goes to white hot.

I think they look fine as is.

Another possibility would be to make aeroshells with either the stock procedural fairings or e-dog's procedural fairings. I've been thinking about cloning fairing parts with ablative shielding for Deadly Reentry.

When DRE releases, it will include patches for Oblivion

Edit: Your temperature is fine; nothing wrong with it.

What Tellion said but let me expand just a bit. Updates happen. Sooner or later you're going to have to do a complete reinstall of one thing or another. (or all of them). If you have to reinstall RealFuels and Stockalike RF configs and let's say that Stockalike added some things and fixed broken configs, then you have to update. Maybe after the time that's passed you remember what you changed or maybe you don't. I have a folder called MyTweaks full of MM patches. Everything I've ever decided to change about my installation over the years and it's usually the first thing that gets installed after Module Manager. I don't have to bother about re-editing this config or that. Easily added. Easily removed.

Let me just be sure I have this straight: You want useRealisticMass = false (for RealFuels) but you don't want the mass multiplier to affect the LVN or you want a different mass multiplier for it, correct? When useRealisticMass is set to false, engineMassMultiplier (= 4) is applied to all engines So either change the global to suit what you want for all engines OR (I think this is what you actually want) EDIT: Removed advice where I had you editing original Stockalike_Squad.cfg file - don't do that. Use a Module Manager patch instead @PART[nuclearEngine]:FINAL { @MODULE[ModuleEngineConfigs] { @CONFIG[NTRLqdHydrogen] { massMult = 0.25 } @CONFIG[NTRLqdAmmonia] { massMult = 0.25 } @CONFIG[NTRLqdMethane] { massMult = 0.25 } } } That completely counteracts the x4 multiplier being applied to the engines. I did each config separately instead of blanketing with a wildcard. You can change massMult to suit yourself for each engine config.

You're missing the Animated Decouplers plugin. Link on first post

What did you set for the following settings: Orbit Altitude Turn End Altitude (those two are really important) Turn Start Altitude Turn Start velocity

Unable to repro problem. I've tried several different sizes of bases and let them sit on the pad at varying levels of warp. And with all three bases (2 fairing bases + 1 interstage) None of them exploded nor did they heat up to unexpected or unusual levels. I suggest you post craft files that you've experienced this with and your output_log.txt file (or your player.log file if Mac/Linux)

MFI has no coded functionality other than to wrap FI methods and allow other mods to register overriding methods. If no overrides are registered then stock methods execute instead. Worse case scenario is that it may need recompiling. I'll ping Sarbian and check if that happened but even if it didn't it's probably ok

I invented this word. Have you tried checking options? I think that behavior is configurable isn't it?

Squad historically has long made use of the modder community to add talented developers to its ranks.

I hate hate.

I looked at some of the output_log.txt files that people posted and in one case SETI was involved. SETI overrides the mass of certain parts (such as sensor parts) and sets them to abnormally low values. That causes problems because low/no mass means low/no thermal mass which means the part heats up very very quickly or results in math errors or both. In Deadly Reentry (for KSP 1.0.2) I tried to work around the problem by enforcing a minimum thermal mass. Stock KSP lacks such protection. In another case (probably not SETI related) I noticed errors in FlightIntegrator.FixedUpdate(), which is where thermal updates occur. If the error occurred for one part AFTER another part had conducted heat to it, that would mean that the part receiving the heat has no chance to get rid of it. That error occurred 5132 times for the person posting that log. (I forget who it was) So the exploding parts bit that people were discussing in that thread had multiple causes apparently. One involving abnormally low thermal masses and another involving ill-timed errors in FlightIntegrator

There are %flowMode = STAGE_PRIORITY_FLOW entries in the PROPELLANT nodes inside the ModuleEngineConfigs. These need to be %ResourceFlowMode = STAGE_PRIORITY_FLOW (flowMode doesn't work, or doesn't work anymore....)

It should actually be easier (a little easier anyway) to aerobrake/aerocapture over Jool/Jupiter in RSS than in stock 1.0.4 because the atmospheric density is lower, just like Jupiter.

If :FOR[foo] exists anywhere, then all :NEEDS[foo] requirements will be satisfied. (which kinda sucks if you are using :NEEDS to be sure that a mod exists as the mod could be absent but :FOR[foo] will make it seem as though it is present) More than that though, patch nodes can be ordered, if you need them to occur in a specific order. The order is :FIRST :LEGACY :BEFORE[Foo] :FOR[Foo] :AFTER[Foo] :FINAL where Foo equals any mod (including Module Manager) Legacy doesn't actually need to be defined; any patch that you DONT specify the order in will occur during the :LEGACY pass. - - - Updated - - - No, you didn't actually specify the Item to patch after checking for its existence @Settings:FOR[AlternateResourcePanel] { @ResourceStorage:HAS[@Item[someResourceName]] { @Item[someResourceName] { @DisplayValueAs = Kilograms } } } Uhm question, does that mod actually use config nodes loaded from cfg files? (that are not in PluginData) I can't tell from looking at it really and it has to be like that

I'm currently testing a heat shield configuration what I have high hopes will withstand an RSS reentry. If it works ok I'll post it here. It should work until Realism Overhaul or Deadly Reentry come out. (where I'll do a similar patch for games that don't have RO installed) attempt #1 failed.... back to the drawing board

Wenking intensifies!

If you have DeadlyReentry installed, first delete the DeadlyReentry.dll file (DeadlyReentry/plugins) Copy the following into a .cfg file into your DeadlyReentry folder (suggesting you do it this way because when you install the update, you're going to want to delete the existing folder anyway which will take care of removing this file) @PART [*]:HAS[@MODULE[ModuleHeatShield]]:FINAL { !MODULE[ModuleHeatShield]{} MODULE { name = ModuleAblator ablativeResource = AblativeShield lossExp = -6000 lossConst = 5 pyrolysisLossFactor = 120 reentryConductivity = 0.01 ablationTempThresh = 500 } } Deleting the dll will stop the exceptions and the patch will force the DRE shields to use the stock heat shield module (except that it will use the DRE resource so that your save game will still load smoothly when you update DRE) This is totally untested by me but should work. The shield performance will be at DRE standards meaning that shields will ablate away quickly, lasting for about 1 reentry so make it count. Yes, I just tried a sub orbital with the small lander can just to see, and quite a bit of it is exposed and it was taking convective heating.. Edit: To all: On the subject of WHEN the update will be ready, very soonâ„¢. I've finally got heat shield performance mostly where I want it and I just need to finish going over DRE's configs to make sure everything is ready. So probably another day or two.

That's to keep you on your toes! Hmmmm... not sure why. I actually decreased conductivity even further down from what you had, by one place. There's also skin-skin conductivity which I set to 0.001... it's probably coming from that one but I didn't experience that kind of heating on my payload

Please be informed that Deadly Reentry has not yet been updated for 1.0.4 and in fact is doing nothing at all for you except throwing exceptions Uninstall Deadly Reentry and await the update. I apologize for the delay and inconvenience.

Holy crap, there's a Jebediah constant??? What else can I multiply by cJeb to learn the way sof the universe????