blowfish

ModuleManager copies to the main log too. It's hard to see errors with everything else but looking for log lines starting with [ERR is a good place to start

My guess is that the stock switcher is messing with nodes even though it's not actually managing them. Hard to say though since that logic is not public.

Yes, minus the space before the *

Not sure what you're asking. In the quoted patch, it will target any PART with at least one RESOURCE, and remove the first RESOURCE node, repeatedly (because of the loop), until the original condition (has at least one RESOURCE node) is no longer true. Note in this instance there's actually a way to do it without the loop: !RESOURCE,* {} will remove all RESOURCE nodes at once so no need to loop, but loops are useful in other scenarios.

See Gemini 8

My guess is that RO's BDB configs are not updated for the latest parts (this is very often the case). I'm not sure who's maintaining those these days. But expect some stuff to be broken (in this case on some of the solar parts, but probably other stuff too unrelated to the warnings)

Check your brackets here, I'll look at the other one later.

To negate you'll need !OUTPUT_RESOURCE:HAS[~name[ElectricCharge]] Quick change as above - !OUTPUT_RESOURCE:HAS[~ResourceName[ElectricCharge]] It's a bit confusing unfortunately. Don't ask me why, it long predates my work on ModuleManager. At the top level this is correct, but within a patch it's only true under one of two conditions: (1) it has a ,* (i.e. -MODE,* {}) or (2) it has a :HAS block So you probably just want -MODE,* {} DStaal already answered the question generally, but I can add a bit more technical detail if you want. Most KSP plugin DLLs don't contain any os-native code - they contain MSIL (Microsoft Intermediate Language) byte code which can be run in the .NET runtime - Unity uses Mono which is an open source, cross-platform implementation of the .NET runtime.

@Gordon Dry finally had a chance to look at this, I think it's a simple capitalization error of BODY vs Body

Some mod's dependencies are messed up. Can you give KSP's log (I only see the ModuleManager logs in there)

What?

@Gordon Dry your syntax looks correct, can you show an example of one of the nodes you're trying to patch?

If they're not in the cache file they don't exist. If the cache file isn't there then MM is running into an error while patching and that should be looked at.

SimpleAdjustableFairings Plugin v1.11.0 for KSP 1.10.1 Recompile against KSP 1.10.1 (did this a while ago but forgot to post) Simple Adjustable Fairings - KW Rocketry Fairing Pack v1.3.0 for KSP 1.10.x No changes, just a version bump for KSP 1.10.x

@boribori couple of things you should pay attention to (not sure if it'll be a problem with those particular parts): There might be more than one ModuleB9PartSwitch on a part. The patch you have will target the first one, which may or may not be correct. You can be more specific by targeting by baseVolume > 0 or a specific moduleID If the different fuel subtypes have different visible meshes, they'll all show at once if you remove the module. I made a crappy patch in B9 HX that tries to handle this. It's not perfect though - for instance it doesn't handle the case that a structural subtype uses one mesh and multiple fuel subtypes use another. Fundamentally you just have to look at every part and see what its requirements are.

You probably want to read this for some background Now, the problem you're running into with the value of that field disappearing is Unity serialization - when the part prefab is instantiated your field isn't copied over. I should really do a post about this some time. There aren't really any simple general-purpose solutions, just annoying workarounds. Here's one. Report your own post and a moderator will remove it.

But to clarify, no real changes are needed on the parts side.

Because my update process involves waiting several hours between the two which makes it likely I'll forget.

This did not exist in reality did it?

@Starwaster looks like 12.8.5 is missing the actual release package?

B9PartSwitch shoves data into each module pretty generically. Some models handle it better than others. The system allows creating custom handlers for different modules, probably what's needed here. If you do end up needing it, create an issue at Github and I can look.

So there are a lot of issues with your install, the biggest is that you have a GameData folder within your GameData folder though. You can try deleting just that, but if you continue to have issues I recommend removing all mods and reinstalling them all from scratch.

The official guidance is: avoid distributing :FINAL patches with a mod if at all possible.

Really no way to balance hydrolox rockets with denser fuels. A lot of people have tried and and the result has not been good. Just look how the skinny stock Ariane V turned out.

So, I think you're making a common mistake in how you're thinking about this. ModuleManager doesn't care about PARTs, or MODULEs, or anything else, all it sees is data. If you have WHATEVERNODE, you can patch it with @WHATEVERNODE (or delete with ! etc etc). If that WHATEVERNODE has name = blah, you can target it with @WHATEVERNODE[blah]. To check sub-nodes/values, use :HAS. Does that make sense?