Starwaster

Hi Simog, if you provide a list of the part names I'll make sure they are added to the other space plane type parts that DRE supports.

Ok nothing wrong with that file.... try deleting both ModuleManager.ConfigCache and ModuleManager.Physics If that doesn't work then delete and do manual install of RO

@Lmoy Ok, seen this once before. Your installation is messed up and you have two sets of PhysicsGlobals. The one actually being used is probably the stock one which multiplies stock Mach convection by about 7x Not only that but one of the PhysicsGlobals nodes has values matching that of an older version of RO. Look in your GameData folder for ModuleManager.Physics And then delete it and run KSP again. THEN - If you're comfortable poking around in the ModuleManager.ConfigCache file, inspect it and do a count for PHYSICSGLOBALS. It should appear exactly four (4) times. If it appears EIGHT times then the problem hasn't gone away. If it HASN'T gone away, look in the root KSP folder for your Physics file and send me that too. And then delete it and run KSP again. (this is the third time it's happened now that *I* know of; so it's somewhat of an edge case but something specific is causing it, maybe CKAN if you use that. I dunno)

AblativeShielding is the resource that Deadly Reentry has always used, long before reentry heating became part of the stock game. Stock KSP named their resource Ablator. DRE retained AblativeShielding for compatibility purposes so that pre-KSP 1.0 craft files and save games would continue to work. (craft in saved games are especially vulnerable to resources being removed from the game)

I need to see your ModuleManager.ConfigCache file. It's in the GameData folder, just put it up for download somewhere such as Dropbox. And output_log.txt file

Not all chute parts do it. There's only one that I know of that does it. It's the one that is stack mounted and has two chutes in it and has an attach node on top.

I'm reminded of...

Edit: oops no never mind, LESS THAN.... but now you're lowering it... hmmmmm

It's working for me. Looking at a simple craft in orbit right now, Hohmann transfer to Mun, autowarp. Auto RCS. Craft pointed to node and then autowarp. Boom bang done. I'm not sure what changes you think happened in KSP that MJ has to match but they aren't there. We can actually look for these changes ourselves you know.

It's because it will only autowarp when angular velocity has dropped below a certain threshold. (0.001 IIRC) Manually engaging timewarp works because it effectively cancels any remaining angular velocity. Complex craft or imbalanced RCS make it hard for MJ to do that on its own so the solution is (as is often the case) to improve one's craft design or live with workarounds such as manually engaging timewarp. Enabling auto-RCS under attitude control can help because it turns off RCS when coarse adjustment is no longer necessary, at which point reaction wheels can take over for fine adjustments. Assuming of course that your craft has sufficient reaction wheels. Again it's all about craft design.

Like this?

I'd tell you to check your anisotropic settings but KSP doesn't have that option. Have any other graphics settings changed recently, if not KSP than in your GPU main settings?

@Catatau_27 ModularFlightIntegrator is not a dependency @Tidal Stream @flart @KerBlitz Kerman Guys I know you're anxious for an update and if someone wants to re-branch and release their own as I did, there's nothing wrong with that but can you make a new thread to do it please? Other than that, I will get the next update out when I can.

If it has enough electricity and is not in analytical time warp mode (100x) then yes it will stop boiloff completely because it intercepts all incoming heat. However, if there is any period of time in which it was not able to provide full cooling (insufficient electricity, turned off/retracted or analytic mode) then it will have to go into overdrive trying to cool the tank down, which takes time. No, it is not at all strange that it (as you say) is shown to be incompatible. More precisely it says it is not supported, which happens if the part is not tagged with RSSROConfig (https://github.com/KSP-RO/RealismOverhaul/blob/bf4413550e1a873f094d862d72feb2150c64c3e1/GameData/RealismOverhaul/RealismOverhaul_Global_Config.cfg#L256-L262) That's all that means. Realistically, about the only reason I can think of for not slapping that label on is that the electrical cost is 1000x cheaper than it should be. According to literature (numerous sources) from NASA on the subject, the electrical cost is approximately 114 watts electricity per watt of heat removed. Right now it's costing you 114 watts per kilowatt removed. Having said that... even with that cost and even with the lack of a label tagging it as compatible/supported.... my HP parts are STILL more realistic than any current configured radiator in Realism Overhaul that is currently tagged with RSSROConfig = true. The reason I say that is that they use the stock radiator code and a flat resource cost instead of a variable cost based on the amount of cooling being provided. (the stock code simply doesn't allow for a variable rate, only a flat rate) So don't worry that it says it's not supported. Instead worry about the day that it says that it IS supported. That will be the day that I increase the electrical cost to what it should be. However, that will also be the day that Real Fuels allows you to customize the amount of insulation your tanks have. On that day you'll be sending a ship off to Mars with tanks that have tens of watts of heat leakage instead of tens of kilowatts so you'll be able to afford the electrical cost. (so... I guess don't worry about it anyway)

Yes that part is used in the mod but it's unlikely that other mods would be affecting it, even mods that use that part too. Ours is inserted into the game separately as a unique part and doesn't use any modules (radiator or otherwise) that other mods might target. It works in two ways: it applies variable cooling depending on current heat leakage rates and a flat rate that kicks in if the tank is overheated. Like real world ZBO applications, it works best if it is combined with a tank with lots of insulation. Now, while I don't think radiator interference is likely, other mods might add their own boiloff to a tank and the ones that I know of apply arbitrary boiloff rates that are not based on temperature or heat leakage so Heat Pump would be useless for those, so try to ensure that you don't have other mods applying their own boiloff Edit: KSPI does do boiloff and it is at least partially temperature based though their implementation looks a bit wonky. Not really sure to what extent this mod could mitigate their boiloff but my suggestion stands that you should disable any boiloff except Real Fuels. (the time warp issue is very much on my mind with regards to RF boiloff and I'm exploring ways to correct those issues)

Ok I misread your post; I thought you were saying the shield itself was being destroyed. As I said before, parts that are the same size as the shield (not counting tapering parts like the Mk1-2 pod or other cone shaped parts) have been a known issue ever since the new physics came out and yes, FAR is probably a factor in some of those cases. The thing is that DRE doesn't even affect parts being subject to heating or not, we stopped doing that after KSP 1.0.3. All DRE does now is change how parts are affected by that heating. (max temp rebalancing, fire effects, g-force effects, Kerbal deaths, Kerbal screams, etc) I can't speak to all of the parts you mentioned (the non-stock one I'm unfamiliar with) but the Mk1 lander can is just not given full coverage by a 2.5m heat shield and that's just in stock, not FAR. It has an exposed area of 0.3 m2 with the shield attached and facing backwards for reentry with an AoA of 0o @Simog I'll look into it but it's a visual issue and you don't really need to worry. He's not really overheating.... much. Kerbal part inner max temp has been drastically reduce in KSP to to more realistic temperatures. Absolute max temp before the Kerbal explodes is 373.15 K... which is the boiling temperature of water. On the ground, a Kerbal's temperature is going to be over 296K which is 79% of the max temp and so KSP turns on the overheating gauge. If you think about it, all living beings are within a very narrow safe temperature range for their environment. I guess what I'm trying to say is ignore it and don't worry about it. By the next release I should figure out why the gauge is showing up again after I successfully got rid of it a few revisions back.

I doubt that the heat is conducting through the heat shield at a rate fast enough to destroy the part behind it. I don't even think you can crank the conductivity setting high enough for that. Most likely what is happening is a known issue where cylindrical parts are not adequately covered by heat shields that are the same diameter. That is to be expected. You need a larger diameter heat shield for those parts. It's really not the same issue. Yours I have no idea what the problem is because I lack sufficient information to troubleshoot.

Because time warping (higher than 100x) thermal physics uses a different model of physics which is not grounded in real world physics other than radiation and a single temperature is assigned to the entire vehicle. It's possible to override on a part by part basis but the bulk of that has to happen in Real Fuels (assuming RF is where your boiloff is happening. HP won't help with other mods boiloff unless they implement it based on ksp thermal physics like RF does)

So your tank walls are one meter thick?

omg an MMSEV...

Adding %leaveTemp = true to the part will signal DRE not to touch its maxtemp, so setting its max temps to sane values becomes your responsibility.

All old releases live here: https://github.com/Starwaster/DeadlyReentry/releases

Let the people you are going to for help decide if logs are enough information or not. Logs are actually a listed requirement for obtaining MJ help and even if they don't contain errors, logs allow potential troubleshooters to obtain relevant information about your game installation and its mods without having to go back and forth with the supplicant for more information. With regards to suggestions made or requests for additional information, I don't see how those could have been made more clearly to you than they already have by various other persons, myself included. You just don't seem to want to try anything else nor provide specific requested information.

@Sigma88 then it probably would have been a good idea to provide a caveat with that to the effect that your statement applied to improperly configured parts (for whatever reason). I likewise don't understand why you would have a problem with me raising concerns over it.

I patched my game to allow my rovers to shift their mass closer to the wheels using Realism Overhaul's CoM shifter. (used for descent mode to give pods lifting reentry capability) Once they are on the ground, or maybe earlier during descent I activate it and they become more stable.