Starwaster

In addition to the other issues raised, your configs have syntactical errors in them and other issues Avoid spaces in names. i.e. name = AVCOAT 5026-39. Change the spaces to . (preferred) or _ (technically, _ is also not allowed but there are workarounds in place that convert underscores to dots) But spaces require workarounds such as wildcards if other configs need to refer to that node by name. Multiple FOR usage. FOR specifies the phase in which Module Manager applies the patch. Use ONLY one FOR. Do not use ! in a FOR. FOR[!RealFuels] means nothing to Module Manager. (why would it even need to be scheduled in RealFuels phase anyway...? see below) You should NOT use any mod name in FOR unless it is your mod. Either change it to FOR[RealisticHeatManagement] or if you really need that patch to execute in a specific order relative to that mod then use BEFORE or AFTER Line 159 - there's no patch for the designated part. depletedMaxTemp does nothing for ModuleAblator. It is a Deadly Reentry setting only. lines 209 and 227: Why are you copying Deadly Reentry configs that do nothing without Deadly Reentry installed? And if Deadly Reentry IS installed... then it's not necessary for those sections to exist elsewhere. Do you know what those patches are for and when they are needed? leaveTemp is also a Deadly Reentry thing. Does nothing for stock

Well, not entirely correct because drogues are made of kevlar which has a higher temperature tolerance. If your rate of deceleration is great enough then it might seem simultaneous but it's not. The nylon chutes are just reaching safe state right after the kevlar ones. Additionally, if you open them in an unsafe state, the kevlar chutes will last longer and are more likely to survive if opened when risky.

Lynx Rover + stock jet engines + KF antigrav units... I just thought I'd leave it here.

I decided to try out Kerbal Foundry's antigrav parts recently. (I've avoided those parts because they were too sci-fi for me and likely won't use them in a 'real play through') The end result was this Lynx Mobile Lab with jet engines and antigrav...

What sort of configurability is the SDHI service module lacking that your other tank has?

IRL there's also 'snatch force' and 'opening shock' to worry about, which I don't think is really represented in the current system which focuses primarily on thermal effects. If that got thrown into the mix I think you would find that large main chutes would suffer more at the speeds that drogue chutes can open at.

https://github.com/KSP-RO/RealismOverhaul/tree/master/GameData/RealismOverhaul/RO_SuggestedMods/RealScaleBoosters

Realism Overhaul has configs for them.

What's an RSB?

I like #3 best. 1 and 2 are right out, IMO, due to not being two discrete engines. That would be problematic because I rely on MechJeb's differential throttling which in turn requires separate engines to throttle. (see my lander above; it has four independently placed engines and MJ can throttle them independently to make up for center of mass issues and for steering purposes. If your engines can also be independently mounted then it makes it easy to deal with off balance CoM) So, selfishly, I prefer 3. 4 looks like it could work too.

Try using fewer struts, not more. More struts means more joints and too many joints cause the physics simulation problems. For a booster, just go with one or two struts. One on the top and optionally, one on the bottom. At the point closest to whatever you're connecting to. Also, if you aren't using autostrutting, consider trying that. It has to be enabled in one of the main menus and after it's enabled, you will find an option to turn on a part's autostrutting in its right click menu. Also also, I notice you are using KWR and someone in the KWR thread mentioned having wobbling with the medium and heavy KWR struts. If those are the struts you are using try replacing them with stock struts. (but also still use fewer struts)

Not sure how I feel about that new cab but I guess it could grow on me... btw, here's a rover with a 15 foot HIAD and a Curiosity style lander:

Then you need to reinstall DRE because you either don't have the latest version or don't have it installed properly. There's no way your Kerbals will be on fire and you don't hear them screaming.

@Nils277 I see a new cab... and uh some sort of cylinder behind the fore and aft wheels... what are those, jacks? Not sure I recognize the module(s) in the rear with the shutters.

Antenna can be placed anywhere and flow doesn't matter because science isn't a resource.

Do they scream?

Configurable Container is interfering with Procedural Parts functionality. Its MM patches deliberately remove the part of the mod where mass changes occur and the modder responsible is aware that removing that section has the consequences of removing mass calculations. https://github.com/allista/ConfigurableContainers/blob/master/GameData/ConfigurableContainers/Parts/ProceduralParts.cfg#L5

He did.

Well, have you tried NOT being a very impatient person? That would probably help you in properly isolating your problem and seeking out help from others.

Well then it's time for logs and ModuleManager.ConfigCache files then

Sorry, that was a... uhm... typo. Right. As everyone knows, the 2 key is right next to the 7 key.... totally natural mistake to make... BTW, this was in reference to KSP 1.5.0, right?

Using only stock KSP 1.3.0 and Procedural Parts I can confirm that mass does change as the size is changed.

I'm sure it would be possible, but it's not something I see myself tackling in the foreseeable future. My hands are full as it is and I don't even get to play the game very much right now which is something I'd like to spend some time doing.

Once more: The DRE build that I provided for KSP 1.3.0 is as is and unsupported. I provided that build as a courtesy to players who chose to upgrade to 1.3.0. I can say that the dll performs its core functions in 1.3.0 but until I get to work on the official update for 1.3.0 I won't be able to support it or address bugs in it. I will say it is expected that AVC would complain because all it can really do is look at the version numbers in the .version file present in the DeadlyReentry folder which identifies what versions of KSP are supported by me. And since that doesn't yet include KSP 1.3.0 then you're going to get a warning about it. (that's all you can really glean from those AVC messages anyway)