blowfish

This thread is a little old, but should still be relevant. It's important to note that what you mean by "most efficient" depends on the answer. If you mean least delta-v, then yes, a higher TWR will be best up until drag losses start becoming significant. If it's least cost, then the calculation is different and you want a lower TWR.

It's a couple of KW patches that are causing ModuleManager to think that FAR is installed. Delete KWRocketry/KWCommunityFixes/KW_FAR.cfg and the problem should go away. @linuxgurugamer I just submitted a PR to fix this. As another aside, you're not on the latest KSP. CKAN reports (and logs confirm) that you're on 1.1.0, whereas the latest is 1.1.2. As a general debugging tip, it's not usually useful to say that you're on the latest version of anything - the exact version number is much more informative.

@siliconworm Wrong thread? I don't see any B9 parts in that screenshot.

This does sound frustrating, but it also sounds like a very difficult issue to debug. Does it happen with RPM on the stock cockpits? Is there a way to replicate without having an active survey contract? Please read "how to get support" in my signature. No way to debug issues like this without logs.

Ok. It's pretty easy to change only for specific engines - just go into GameData/AJE/Squad.cfg and comment out/remove all the @mass = x or %CoMOffset = a,b,c. That will put the stock engines back the way they were.

It would be rather complicated to set up like that. At any rate, the performance itself can vary quite a lot from the stock equivalent - even if the mass and CoM didn't change, the plane still might not behave the same way.

It's >0

Which part? Is it not clear what lines I'm talking about?

:HAS[#CrewCapacity[>]] you haven't specified what it should be greater than (should probably be [>0] Some other things I see about the patch: kerbCount isn't necessary, since it's always just the crew capacity. You can just use @amount *= #$../CrewCapacity$ directly You will always have 0 for the amount and maxAmount of mulch. Typo maybe?

Just offset them? That's always worked for me.

@GoldForest All the engines are surface attachable. I think that would cover your use case. Trying to add unique node setups to all the mounts in addition to everything they already have would probably be excessive.

KSP's load time is usually dominated by (single threaded) CPU processing. But unless you have a very slow processor, an upgrade might not give you that much benefit.

Note that it will still take a while the first time. You only get the benefit the second time after not changing your mod configuration.

It turns out MM tells you in the log. The more you know [ModuleManager] Changes : Added : KSEA/Historian/Plugins/Historian.cfg Deleted : KSEA/Historian/Historian.cfg Looking at CKAN's metadata, that's the mod "Historian"

@Lewtz ModuleManager caches patches, so after the first run with a particular set of mods, later runs are supposed to be faster. If it's not loading patches from cache, then it means one of your mods is doing something it shouldn't and writing a cfg to GameData without putting it in a PluginData folder. Unfortunately telling which is quite difficult.

It's just a plugin. Copy ModuleManager.2.6.24.dll (or watever the current version is) into your GameData folder. It doesn't do anything by itself, of course, that's up to other mods.

Welcome to the forums! Please read "how to get support" in my signature - it should tell you what you need to provide for us to debug your issue.

@NecroBones Notice useCache=true. MM will cache the patches for faster loading time. Delete ModuleManager.CondigCache and it'll re-apply the patches.

@Jenyaza Could you state in words what you're trying to accomplish? I think there's probably a simple solution I don't believe this would work the way you think. MM goes through at the beginning and generates a list of FOR matches which it considers to be installed mods. Dependency checking and actual patching is done later.

@blorgon Also this should probably go in the ModuleManager thread. Not really related to plugins.

@blorgon: HAS[#CrewCapacity[>0]] should work fine. Note that for values in a HAS block, you want '#' for does have or '~' for does not have. '@' and '!' are for nodes.

Not sure what you're trying to accomplish here. FOR is meaningless outside of top-level nodes. Maybe you wanted NEEDS, which does work on subnodes (example).

@KocLobster I was thinking just dry/wet mass/cost. You can already see the resource amounts ... do you really care about the specific resource masses?

My SSTU install is symlinked from a local copy of the repository, so I'll probably always be the first one to ask

@Shadowmage Perhaps you forgot to push again?