blowfish

Actually just to eliminate this, can you try deleting your part database? I've seen a lot of weird caching issues around that and there's no proper invalidation for it.

my guess is that ModulePartVariants is messing with it somehow, would it be acceptable to have drag cubes not affected by B9PartSwitch switching?

So wait, you searched specifically for "engine" and expected to find fuel tanks?

Thanks @JadeOfMaararen't these two patches conflicting in the absence of ClassicStock? https://github.com/JPLRepo/Endurance/blob/master/Distribution/GameData/Endurance/Patches/B9PS.cfg#L251 https://github.com/JadeOfMaar/EnduranceReconfig/blob/master/GameData/EnduranceReconfig/B9PS.cfg#L195 This is already working PART { // ... MODULE { name = ModuleB9PartSwitch // ... SUBTYPE { // ... TRANSFORM { name = whatever scaleOffset = 2 // multiplies that object's sca

Okay I figured out what's happening - MM is delaying replacing physics until the space center, which means that when the part loader reads those values it gets the stock ones. If you reload the game database it might get the values from the first load. I can't see any reason why MM shoudln't be able to do the physics thing immediately, so the solution is probably just to do that.

Not really possible in general, I've seen some half baked attempts at this but they all mess up under some circumstances, the fundamental problem is that there may be instances of objects from the old DLL still present, and there's no way to guarantee that they can be converted to new objects. I recommend creating a minimal test install so that the reloads are less time consuming. You might even consider removing some parts of GameData/Squad if you want really fast startup.

need to see the log to know which parts are misconfigured

Ugh, I'll look, if KSP is accessing this before MM has a chance to do its thing then there might not be anything to be done, but maybe it can be set later too. E: hmm, not seeing anything obviously different here, can you provide more info about what about it doesn't seem to be getting picked up?

Kopernicus keeps changing how solar panels are configured and it's hard to support them all at once. What it's telling you is broken is the functionality that changes how much power solar panels output based on the subtype.

Are those values uses as-is in update calculations, or is there some initialization that happens based on them (I'm guessing finding the celestial body). What methods does that initialization happen in (load, start, ...). Is this intended to be switched in flight or just in the editor? Currently no, I've heard some requests for this but the drag cube code is so painful to work with I just haven't found the motivation to do it yet.

Huh, does the part in question have nonzero cost to begin with?

This all looks correct to me, what in particular isn't working about it? p.s. code blocks make it a lot easier to read

What would the user do with that information though? If you're already in flight then it's locked in and there's nothing you can do aboiut it. Just trying to understand the full extent of the user interaction you're trying to support here. As the message says I will need the full log to debug. Most likely some mod depending on B9PartSwitch is installed incorrectly or is missing a dependency.

I guess I was more wondering how the user might use that information.

It's hit or miss how particular modules are going to react to being disabled. ModuleCommand and ModuleDataTransmitter in particular have interactions with other parts of KSP that might not respect that. You're welcome to try of course. What information needs to be presented to the user in flight here?