Nodes with underscores in the name can have issues

[JonnyOThan]

SuicidalInsanity/Mk2Expansion#69

Test case: place random object in editor. place two tricouplers in symmetry on it. Place objects on all nodes on the tricoupler. launch this device and revert to the editor. Inspecting the drag cube on the tricoupler shows very high drag on the back face, and after removing the part mounted on the centre node, no node is visible on the part.

I believe this happened because KSP uses string.split with underscore as the delimiter in order to aid with the node_stack_ parsing.

This issue can only affect modded parts (I think?) and may not be easy to fix, but I thought at least it should be documented.

[CensoredUsername]

It's definitely curious that when having node_stack_bottom and node_stack_bottom_01, the _01 variant will be remembered, but the bare variant won't.

Not sure if this qualifies as a bug though, it seems more like a coincidence that node_stack_bottom_ works to begin with.

Nodes should likely just be node_stack_[identifier] to disambiguate them, without underscores in identifier

[JonnyOThan]

It's definitely curious that when having node_stack_bottom and node_stack_bottom_01, the _01 variant will be remembered, but the bare variant won't.

Are you sure about that? I haven’t investigated at all yet but I suspect the ordering in the cfg file matters more than the name.

[CensoredUsername]

I haven't tested if it might be order dependent, just a hypothesis at this point. In this case, there was a node_stack_bottom first, and node_stack_bottom_01/02 afterwards. The latter survived saving, the former occasionally did not.

[JonnyOThan]

Right, I happen to know that the KSP code uses string.split with underscore as a delimiter. So my hypothesis is that anything after the 3rd underscore is going to be ignored, and if you have multiple nodes with the same name then likely the last one is used (last writer wins)