blowfish

Thanks for the log, that lead me the problem quickly. It looks like you have a corrupt installation of CommunityResourcePack. Many of the mods you have installed depend on it. Try reinstalling it.

I generally don't bother paying attention to old KSP versions, so as soon as I'm compiling for a new version, that's what the version file will say and that's what CKAN will consider compatible. It may happen to still work with older KSP versions but I don't guarantee anything.

The question you should be asking is does RO support this. I don't know the exact state of everything right now but in general BDB changes fast enough that the RO configs are often out of date.

http://heroicrelics.org/info/titan-i/titan-i-stage-2-engine.html I've generally found Heroic Relics to be a reliable source

Looks like probably node_stack_top/node_stack_bottom, verify the the parts you're targeting actually have a size specified on the nodes Also prefer @RESOURCE[LiquidFuel] { @amount = x @maxAmount = x } over indexing, it's less brittle

@Pappystein Titan I only lit the 2nd stage verniers prior to stage separation, the gas generator was run off of a separate set of pumps to facilitate this (this was removed on later LR-91s as they had exhaust holes in the interstage to support full hotstaging. AFAIK they ended up with separation motors too in the end though.

The error message is somewhat misleading, it's almost always mod misconfiguration (which B9PartSwitch is just noisy about rather than swallowing silently). I can help look through logs and config caches if that would be helpful, usually between those and cross-referencing patches on Github it's possible to figure out which mod is misconfigured.

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 scale, accepts a single number for all 3 axes or 3 numbers for different axis scaling } } } }

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?

The key you're trying to set is in systemPower, which means systemPower is the current node it's going to look at. E: to be clear, the exact syntax you want is key = #0 $../INPUT_RESOURCE[ElectricCharge]/Ratio$, should have noticed that in the original question

It's only going to look in that node. If you want to look up a level, you need ../INPUT_RESOURCE, or ../../INPUT_RESOURCE for two levels, etc

the # goes before the 0. The # tells MM that there are interpolations, the actual interpolations themselves are bounded by $ signs