blowfish

I'm not seeing anything wrong with the cache. Can you show me what you're seeing? E: Could not replicate any issues with pasting nodes either @Wyzard not currently possible to use or in that context. Will probably be done eventually but need to clean up a lot of code first. But patches in the same file and pass will be applied in order.

I've been trying to get dirty data cleaned up lately, but I could be convinced that this should be a warning rather than a fatal error (still gives you a dialog but allows you to dismiss rather than exiting). Really fuel switching should be disabled in the config if another resource management system is present on the part, but I don't think there's any universal way to do that, there are too many edge cases.

The MFT patches should remove the fuel switching ModuleB9PartSwitch (or if it also switches meshes, remove the fuel switching capability from it)

That looks correct to me. Maybe check with DebugStuff one more time to make sure everything looks as it should? And also check for errors in the log.

They need to be in separate MODEL nodes, but otherwise yes.

Well it looks like you've only added one MODEL {} to the part. B9PartSwitch can't actually add anything to the part, it can only enable/disable what's already there.

Should be done once this is merged: https://github.com/KSP-CKAN/NetKAN/pull/6852

Can you show me the full config as it currently stands?

That's the part itself, you'll want stuff below the "model" object. It looks like in your case you'll want the long name ( PlanetaryBaseInc/ModSupport/Parts/LifeSupport/Container_Sabatier(Clone) ). Some models have another object below that with a unique name you can use, but not all (just depends on how they are set up). If you add more than one model with MODEL {} nodes and then look at the hierarchy you will probably see why this is the level you need to switch at.

KSP adds all the models to the part's hierarchy. That doesn't mean that you will end up with objects having the same name as the model's filename in there. You need the names of the actual objects. I'd recommend using sarbian's DebugStuff plugin to determine exactly what names you need.

It's all in the log.

B9PartSwitch v2.5.0 for KSP 1.5.1 Allow moving stack nodes Within a SUBTYPE, NODE nodes take a name (node ID) and a position (x, y, z position of the node) Fix log message for duplicated subtype names Fix texture switching behaving weirdly when copying a part in the editor Quick example for moving attach nodes: PART { // ... node_stack_top = 0.0, 2.0, 0.0, 0.0, 1.0, 0.0, 1 MODULE { name = ModuleB9PartSwitch SUBTYPE { name = Default } SUBTYPE { name = Moved NODE { name = top position = 0.5, 2.0, 0.0 } } } } As with other things, any subtypes that don't specify a position will have the attach node moved back to its original position. Only one module on a part can manage any individual attach node's position. Also note that a NODE will not modify the stack node's enabled status, that is still done only via node = xxx on the subtype. I acknowledge that this might be somewhat confusing and may look into changing it in the future.

Unhelpful log message was an oversight in my part, will be fixed in the next version of B9PartSwitch (should be released in the next couple of days)

Welcome to the forums! This is something that has to be fixed in the mod that's causing it (Near Future Launch Vehicles). This error looks familiar so it may be known already but I'm not 100% sure. It will not prevent you from playing the game but may point to some unexpected behavior when using that particular part.

3.1.1 was before the fix

Ahh thanks. Got a report of this earlier it turns out but couldn't make sense of it until now.

Order does not matter.

Bit more info on this update, there are some noteworthy changes: The parsing of root node and patch names (e.g. @PART[www]:HAS[xxx]:FOR[yyy]:NEEDS[zzz]) now follows a formal structure rather than each bit trying to be extracted individually. This makes it much easier to change or add features. It could mean that there is some bad data that was silently accepted before but will error now. Eventually this system will be extended to parsing subnodes and values of patches too, but one thing at at time. Some things that were previously errors are now just warnings. Warnings will still complain to the user, but they will not prevent the cache from being created. These are generally things where a patch has bad data but ModuleManager can guess the intent. In general these should be fixed by the mod author in a timely manner. One example is multiple pass specifiers on the same patch. Previously it would error, now it will take the first one and warn.

Apparently I've been pretty lazy about updating the thread Simple Adjustable Fairings Plugin v1.3.0 for KSP 1.5 Recompile for KSP 1.5 Simple Adjustable Fairings Plugin v1.3.1 for KSP 1.5.1 Recompile against KSP 1.5.1 Simple Adjustable Fairings KW Rocketry Fairing Pack v1.1.0 for KSP 1.5.x Bump .version file for KSP 1.5

Advanced Jet Engine v2.12.1 for KSP 1.5.1 Bump SolverEngines dependency version to get around issue with KSP dependency version checking

That's strange. RealFuels requires SolverEngines 3.3.0, AJE requires SolverEngines 3.6.1, and you have 3.7.0 installed, and yet RF loads fine but AJE refuses. I'll look into this, could be an issue with KSP's version checking.

Well, it looks to me like you don't have the main B9 pack installed. It would be at GameData/B9_Aerospace/ but no such directory exists in your install.

I'll need to see your full logs then. The thing it's complaining about (tank type named B9_LiquidFuel) definitely exists.

@SciMan do you have the main B9 pack installed? Legacy isn't designed to work by itself.

I'm not aware of anything that changed in this regard. Please provide logs so that I can determine what's causing the incompatibility.