blowfish

Does indeed appear to have been broken recently. I just wrote a fix, should be released soon.

They’re equivalent. However, I’d prefer the 2nd as it’s more common and , means something different in other contexts.

If you have a mod installed that requires CRP and uses B9PartSwitch and you don’t have CRP installed, you will encounter a fatal error. If there was a breaking change I knew about I would have documented it and updated the major version to 3.0. Alas, 2.9.0 is fully backwards compatible.

The commit log isn't really meant to be human readable. But I put together a list of the meaningful changes: Logging: Fix context not showing up for exceptions in logs Remove datestamps from log messages (only put time), instead write date at top of logs Have timestamps on logs reflect when the log message was created rather than when it was written to the log Fix files with a space before the extension breaking the cache Fix tabs and newlines (\t and \n) getting stripped out of values

The RO thing was a backport to make it work with KSP 1.3.x. I don't think it's necessary anymore.

Read the "how to get support" link int my signature. It will tell you how to find and upload KSP's log. If I can read that I will be able to tell you what's wrong. Most likely something is installed incorrectly.

I'll give you one and you can infer the rest

B9PartSwitch can update any number of things that it supports at once.

As was correctly surmised on the previous page, this is because CKAN pulls CryoEngines from Spacedock and version 1.0.2 does not appear to be there.

Yeah, that's frequently done in a patch that runs near the end.

That's KSP, not ModuleManager. It's saying that it doesn't know what those fields mean. ModuleManager has already completed its part at this point, here KSP is parsing the configs and compiling parts from them.

It's 100% backwards compatible. As a modder you don't have to make any changes if you don't need to customize anything. And as Jade said the automatic info in the tooltips will only show things that are actually changing. If your switching meshes it will only display the subtype title.

B9PartSwitch v2.9.0 for KSP 1.7.3 Implement new switching UI based on the stock variant switcher Have subtype switching buttons show some info about the subtype being switched to in a tooltip By default shows resources (including parent), mass, cost, max temperature, max skin temperature, crash tolerance Also shows descriptionSummary and descriptionDetail from subtype, before and after auto-generated info respectively, if present 4 new fieds on SUBTYPE descriptionSummary - any info here will be put in the subtype switching tooltip before the auto-generated info - make it brief descriptionDetail - any info here will be put in the subtype switching tooltip after the auto-generated info - go nuts primaryColor - color to use in the left part of the switching button if not specified, use the tank type's primaryColor if that's not specified, use white secondaryColor - color to use in the right part of the switching button if not specified, use the tank's secondaryColor if that's not specified, use the subtype's primaryColor if that's not specified, use the tank's primaryColor if that's not specified, use gray 2 new fields on B9_TANK_TYPE primaryColor - color to use in the left part of the switching button i they subtype does not specify one. If not specified, common resource combinations will be used. secondaryColor - color to use in the right part of the switching button i they subtype does not specify one. If not specified, common resource combinations will be used. add default colors for common resources ResourceColorLiquidFuel ResourceColorLqdHydrogen ResourceColorLqdMethane ResourceColorOxidizer ResourceColorMonoPropellant ResourceColorXenonGas ResourceColorElectricChargePrimary ResourceColorElectricChareSecondary ResourceColorOre Automatically apply resource colors to common resource combinations in tanks (if colors are not specified by the tank or subtype): LiquidFuel LiquidFuel/Oxidizer LqdHydrogen LqdHydrogen/Oxidizer LqdMethane LqdMethane/Oxidizer Oxidizer MonoPropellant XenonGas Ore ElectricCharge Feel free to give any feedback about the new UI once you try it out

The realm of what's simple in game design in general and what's possible to change in KSP by modders are very different things. As a game developer you generally have access to change all of the game's code as well as things like UI prefabs. In KSP modding that isn't the case. We get a very limited window into KSP and what it's doing. So there is no "just do" any of those things

KSPField has the fields groupName, groupDisplayName, and groupStartCollapsed (default false). Any fields with the same groupName will end up in the same group, I think for the second two you would only need to specify on the first field (doesn't hurt to specify on all of them of course).

Fun fact, the part action window already sort of has support for collapsible groups It doesn't look the best. And nothing uses them anyway.

B9PartSwitch v2.8.1 for KSP 1.7.3 Recompile against KSP 1.7.3 I'm working on some major overhauls to the UI right now. The new switching UI is based on the stock variant selector (not exactly the same, and hopefully better in some ways). This will pave the way some other big planned/in progress features, such as tech unlocks and switching data on other modules.

@PART:HAS[@MODULE[ModuleEngineConfigs]:HAS[#type[ModuleRCS*]],!MODULE[ModuleRCS*],~name[xxx],~name[yyy]]:AFTER[RO-RCS]

Here was the previous sequence of events KSP loads plugins -> KSP loads textures -> KSP loads models -> ModuleManager applies patches -> ModuleManager runs post patch callbacks -> KSP compiles parts Here is the new sequence -> KSP loads textures -> KSP loads models -> KSP loads plugins -> -> ModuleManager runs post patch callbacks -> KSP compiles parts -> ModuleManager applies patches ----------> There shouldn't be any effect as 99% of mods are concerned. Also note that applying patches is still done one by one, it's just done in the background while KSP is doing unrelated stuff. There shouldn't be any effect as far as the cache is concerned (and changing ModuleManager versions invalidates the cache anyway)

I wonder if this was actually a change in KSP's ConfigNode parser... Still very curious how this would have worked. ModuleManager wouldn't have had any way to know to process the node before the value, then or now.

2.0.8 is ancient history, like pre-Sarbian ancient history. I checked the code around then and I don't see it looking for | in HAS blocks, but maybe if you say so? That was probably before I was even playing KSP. The problem here is that when KSP parses nodes, it puts all the nodes in one list and all the values in another list. So ModuleManager has no way of knowing which came first originally. I'm not sure how this could have worked before, and a few years sounds before my time working on ModuleManager, but if you narrow it down to a version update I might be able to look at the code and see. Also it would have to be !leaveTemp = DEL (or some other value that doesn't matter), otherwise KSP doesn't parse it as a value Close... @title ^= :^:#$bulkheadProfiles$: As starwaster mentioned you probably want a space before the final :

This never worked to my knowledge. It was not implemented. In fact, you can go look at old versions of the code and confirm that. Could you be more specific? Maybe an example?

| doesn't work in a HAS block, unfortunately you need a separate patch for each

There was a change, but it happened quite a while ago (maybe more than a year at this point?). EXPERIMENT_DEFINITION nodes don't have a name value, so @EXPERIMENT_DEFINITION[*] no longer works (you want @EXPERIMENT_DEFINITION:HAS[#id[crewReport]]) Less sure about the 2nd part, I don't think that has anything to do with ModuleManager though.

Yeah, Tweakscale and robotics involved points to "likely not a B9 specific issue" in my mind