blowfish

Right. When debugging ModuleManager patches, it's always a good idea to see what the final result is in ModuleManager.ConfigCache since that won't be affected by how KSP/whatever mod is actually loading the data.

Are you absolutely sure @LIFE_SUPPORT_SETTINGS:AFTER[USILifeSupport]{} didn't work? This should target every LIFE_SUPPORT_SETTINGS node, and should have worked both before and after the update.

It was a change. It wasn't exactly intended, but after consulting the docs, it is 100% consistent with the intended behavior, so it was kept. You want @EXPERIMENT_DEFINITION:FINAL - the [*] bit implies that there is a name value to match the * against (however, experiment definitions use id rather than name). If you want to match a particular experiment definition you can use @EXPERIMENT_DEFINITION:HAS[#id[xxx]] Just to clarify why this worked before, it was actually matching * against EXPERIMENT_DEFINITION (quirk in the way that KSP interprets root nodes). So e.g. @EXPERIMENT_DEFINITION[EXPERIMENT_DEFINITION] would have matched every EXPERIMENT_DEFINITION

There's no way to target nodes based on their location in GameData unfortunately.

Correct, it's a KSP limitation. KSP excludes everything after the first space from the node name*, so MM has no access to it.

@PART[foo|bar] works (and will look for a PART node with name = foo or name = bar). | does not work in a :HAS block (only , or & which represent AND will work, and then only separating different conditions, e.g. :HAS[#foo1[bar1],#foo2[bar2]]). However, you can use any of | & , in a NEEDS block (first is OR, second two are AND, OR binds tighter than AND) E: clarified about and in a :HAS block

It's not on Spacedock, but I'll update.

Oh sorry, I missed that part. As far as I'm aware, there are not issues in 1.3.1

I can submit a PR, yeah. The point of having it be in some PluginData folder is that setting changes don't invalidate ModuleManager's cache.

@swjr-swis I'd actually point to the fact that there is no standardized notion of how a "mod" is structured in KSP. Some mod authors prefer to keep all their mods in the same GameData directory, others split them out, some are just a plugin, etc. So with regard to CKAN, it's really difficult to justify the assumption that just because CKAN doesn't know about the remaining files in a particular directory, they can be removed. ModuleManager has several ways of determining that a mod is "installed", and the GameData subdirectory way isn't going away any time soon (I can tell you from my own experience how difficult making breaking changes to ModuleManager is). With regard to the settings files being dead themself, the difference is that KSP doesn't load them automatically, which is not the case if you e.g. have a dead texture or something - that will impact loading time and memory usage. And finally, I'd question whether even a significant fraction of users are aware that settings are stored in GameData/<some_mod>/PluginData @Ezriilc if the settings are going to be moved back to GameData, they should be within some PluginData directory. Probably GameData/Kerbaltek/HyperEdit/PluginData. Also, I think that the code I added to migrate the settings to the new location is instead deleting them on each KSP startup after your most recent change (since the "old" and "new" settings locations are now the same).

Well then, I think the fundamental problem is that you more or less need FAR to use AJE. The stock atmosphere is a fair bit draggier than FAR's. The stock engines compensate for this by growing thrust very quickly with speed, but AJE doesn't have that.

Could anyone here ( @swjr-swis @linuxgurugamer ) elaborate on why you think putting data in <ksp_root>/PluginData/SomeMod/ is a bad idea? I've seen some issues with <ksp_root>/GameData/SomeMod/PluginData ... most notably, if you install via CKAN, then the mod puts some stuff there, then you uninstall, the SomeMod folder will remain in GameData (since CKAN doesn't know about those files, it won't remove them), making ModuleManager think that the mod is still installed. If you are manually installing mods, keeping settings out of GameData also makes it easier to update a mod without loosing all of your configuration. Consider this scenario: Version A has a particular file, version B (the next version) no longer requires that file and removes it. To ensure that you aren't left with dead files, when installing a new version, it's really best to delete the mod's entire directory first ... except that if you're using GameData for settings, that directory also has all those settings, so you either have to re-do all your settings in the next version or figure out which files to copy over. @Stone Blue nothing to do with MM changes, this has been a long-standing issue.

@Ninadragonborn Thrust will drop off a bit compared to standstill at low speed, and Isp will drop steadily with speed, that's just how jet engines work (I'm less sure about propeller engines). Just to be sure, are you using FAR?

You still want @description:NEEDS[mod1] ^= As it is you're duplicating the description field and appending to the end. If you find the part configuration in ModuleManager.ConfigCache you will probably see this.

You don't actually have a UI_FloatRange property on that field. uiControlEditor will return the UI_Label you have defined.

More or less, yeah

There wasn't really anything in 1.3.1 that affected AJE

I'm not opposed to it, but I also don't have the time to go through and make sure all the engines are actually playing nice with Tweakscale. If someone wants to make any necessary fixes and submit a pull request, I will include it.

Fuel flow is calculated from initial thrust and Isp, then modified by all the flow modifying curves I mentioned. atmCurve modifies flow at constant Isp, so thrust and flow will both change proportionally. This is the case for all the flow-modifying curves I mentioned above. For the Isp-modifying curves, it will modify the Isp at constant fuel flow, so the thrust will also change.

"No fuel" is not a stock message - do you have AJE installed? If so, the engine configuration is completely different. There's also a problem with how you're defining the curves - if you use %key multiple times, it will see that there's already a key there and only modify the first one. For those things, better to just remove the curve entirely (if it already exists) and then recreate it. A great way to debug what's going on is to find the part configuration in ModuleManager.ConfigCache. That will tell you what it looks like after all the patches have been applied.

Okay, as far as I can see here's what's what: atmosphereCurve - Isp vs static pressure (atmospheres). Always used. atmCurve - flow multiplier vs atmosphere density (normalized, i.e. 0-1). Used if atmChangeFlow = true and useAtmCurve = true atmCurveISP - Isp multiplier vs atmosphere density (normalized, i.e. 0-1). Used if useAtmCurveIsp = true velCurve - flow multiplier vs mach number. Used if useVelCurve = true velCurveIsp - Isp multiplier vs mach number. Used if useVelCurveIsp = true thrustCurve - flow multiplier vs amount of propellant left (normalized, i.e. 0-1). Used if useThrustCurve = true. Ignores any propellants with ignoreForThrustCurve = true throttleIspCurve - Isp multiplier vs throttle (normalized, i.e. 0-1). Used if useThrottleIspCurve = true throttleIspCurveAtmStrength - Modifier for how much throttleIspCurve actually affects Isp vs static pressure (atmospheres). 0 means that throttleIspCurve doesn't affect Isp at all, 1 means that throttleIspCurve has the full effect. Used if useThrottleIspCurve = true

@Toonu the crash is because it's case sensitive, you want velCurve not VelCurve. I will attempt to give an explanation of what is what in your other thread.

Just set it to run near the end, e.g. :FOR[zzz_MyMod] - this is pretty common in existing mods

If you're willing to run with 3.0.1 again, you could post KSP's log here and we can inspect it to see which mods have this issue. 3.0 and 3.0.1 do improve the speed of applying patches, and code changes in them pave the way for future improvements.

Yes, sorry about that. I had hoped that posting a rerelease version well in advance would give mods time to adjust, but evidently that wasn't exactly the case. Do you have a list of mods you're having issues with? We've been trying to clean them up after the fact either by notifying the authors or by submitting fixes directly.