blowfish

Not currently possible. But you can use the fact that x > y is equivalent to x - y > 0 (store the difference in another variable and check whether it's greater than zero)

B9PartSwitch v2.3.2 for KSP 1.4.4 Recompile against KSP 1.4.4

I think you want @PART - just PART creates a new one

@Gordon Dry it's case sensitive, MODULE vs Module

HAS[@MODULE[ModuleGimbal,ModuleEngines]] is the bad part, it doesn't work that way. You need HAS[@MODULE[ModuleGimbal],@MODULE[ModuleEngines]]. It's looking for a module with name = ModuleGimbal,ModuleEngines which does not exist on any part. If you search the log for this patch, you might have noticed that it was not being applied to any part. That would have been the first clue as to what was wrong.

@PART:HAS[@MODULE[ModuleEngines*],~name[RSB*]]:FINAL contrary to what @Gordon Dry said, :NEEDS is not correct here, since that will turn the patch on or off for everything based on the presence of a mod.

There's a maxEngineTemp field on the module you can set. It defaults to 4000 K

There is no such thing as ModuleEnginesAJEscramjet, and no scramjet model in AJE. Not enough data on scramjet performance has been published to implement one.

B9 itself should. For the dependencies though you should check if there's a version for 1.4.1 - for instance, for B9PartSwitch I know for a fact that it now uses code that's only in 1.4.2, but you should be able to find a 1.4.1/1.4.0 version that will work.

Might want to let @Bamse know that. It's not my install, I'm just reading the logs.

Thanks for the log, was able to see what's going on Kerbalism and SSPXR's MKS patches do not play well together it seems. Kerbalism removes ModuleDeployableHabitat, but the SSPXR MKS patches expect it to be there. I don't know which side the fix would be on though. Kerbalism patch: https://gitlab.com/N70/Kerbalism/blob/05b11b291acc49e42a5255a2576ed98d92b95297/GameData/Kerbalism/Support/SSPX.cfg#L138 SSPXR MKS patch: https://github.com/ChrisAdderley/StationPartsExpansionRedux/blob/d38160bd6382b798183780a64021e486c58db303/GameData/StationPartsExpansionRedux/Patches/SSPXR-MKS-Extras.cfg#L154

Right, because errors would prevent it from generating. It looks like the patch is in fact coming from Ven's - GameData/VenStockRevamp/Patches/SoftTanksLH2.cfg is badly broken. I noticed that GameData/VenStockRevamp/Patches isn't included in the main download - is it even supported?

Hmm, based on a look at the configs involved and other reports, I think this is actually caused by having an empty CryoTanks folder in GameData. Near Future should be able to function without CryoTanks but the empty folder makes ModuleManager think it's installed when it isn't.

Looks right to me

Check your brackets. You have multiple :HAS blocks at the top level. You want :HAS[@MODULE[ModuleDataTransmitter]:HAS[#antennaPower[>1000000000000],#antennaType[RELAY]]]

That's probably coming from CryoTanks. But it's odd, the patch should check for the presence of liquidFuel. Would you mind posting your full KSP.log and ModuleManager.ConfigCache

It's a known issue, 1.4.x messed up a lot of RCS effects that were previously working. It's pretty simple to fix in the configs, I just haven't had time lately.

A MODEL node can only take one model. So you do that and then they all show up at the same time. Good. That's what you want, sorta. Everything needs to be there in the first place, B9PartSwitch just disables the ones you don't want. I can tell you that you don't have the transform names quite right. I'm at my desktop now, so I can tell you that when KSP inserts a model into the hierarchy, it ends up with a name like "Squad/Parts/Aero/cones/ConeA(Clone)" - and note that you need to get the exact name right, since there is no fuzzy matching. You should be able to see this with DebugStuff.

It's doable. Not sure I have an example handy though. Combining models can be tricky - you can get them all on the same part with the part's MODEL nodes, but then the question is how do you reference them in order to switch. Some models do have uniquely named transforms you can reference, but others don't, in which case you need to figure out what name KSP uses when inserting the model into the hierarchy. I think it's something like "/Path/To/Model (clone)". I'd recommend sarbian's DebugStuff plugin for figuring out the transform names. Couple of other things worth noting: Nodes can't currently be moved, only turned on/off. This means that when you switch the subtype in the editor, any attached parts will stay where they are until you pick them up and move them. I haven't tested extensively with any switching that changes a part's size significantly. I think it works, but there may be scenarios I don't know about. Colliders and drag cubes are fine, I'm more concerned about things like Unity's moment of inertia calculations.

It probably expects CryoTanks to be installed but it is not.

What's broken? I used this to test RF v12.7.1 - I only tested a few engines but they seemed to work fine. There was a bug in RF v12.7.0 that broke nearly everything but that's fixed.

Why would nosecones require any sort of technical advancement though? Nozzle gimbaling - if you wanted to do this you could set the gimbal range to zero early on and have upgrades increase it, but there's no way to remove the gimbal module entirely. E: maybe you could set moduleIsEnabled = false on the gimbal module which it looks like would hide most of the UI. Haven't tested this though.

Engines and fuel tanks used to be combined in the propulsion category, then it got split into engines and tanks.

I'd avoid the default DX9 mode if possible anyway - it uses a lot more RAM than either DX11 or OpenGL.

RealFuels v12.7.1 for KSP 1.4.3 Fix exceptions when initializing ModuleEnginesRF Fix mass display in the part action window not accounting for MLI Remove a bit of log spam