Compatibility Issue: ConfigNodePerf patch & SCON/EPL

[MartyrKomplx]

Posted this issue in the Github for SCON first, but since I'm not sure which mod actually causes the incompatibility or how, posting it here as well.

With both KSPCF and SCON installed, resource requirements (Rocketparts & Electric Charge, etc) occasionally don't show when opening the in-flight crafting menu. Additionally, for the craft that shows no requirements, when attempting to build it, it will build instantly with no resources used.

Tested on an install with only these two mods to verify. Works as expected without KSPCF, works as above with KSPCF. Set all modules in KSPCF to "false" in the settings file to try to narrow down the issue; the issue persists with all "false" settings.

Issue is not quite random, does not affect all craft builds but once I found a craft that it affects, it is reproducible even after quitting, and reloading (to include installing/uninstalling SCON and/or KSPCF) but I cannot figure out what about the craft causes this.

Log attached: KSP.log

KSP and both mods are latest versions (KSP 1.12.3, KSPCF 1.22.2, SCON 4.0.99.30-prerelease) KSPCF downloaded via CKAN, SCON via CurseForge.

[NathanKell]

Can you get me a minimal reproduction of this? I've never touched SCON (or knew it existed).

[MartyrKomplx]

Can you get me a minimal reproduction of this? I've never touched SCON (or knew it existed).

I hope this is what you meant by a minimal reproduction ...?

With only SCON installed: (Youtube)

• Build menu comes up, and shows resource requirements.
• When starting the build, resources are used and the build takes time.

With both SCON and KSPCF installed: (Youtube)

• Build menu comes up, but doesn't show resource requirements.
• When starting the build, build completes instantly. No resources used to build.

Not all craft are created equal: (Youtube)

• Affects some craft, not all (not sure what the difference is)
• Will always affect the same craft the same way.

[Edited to add the third video]

[NathanKell]

What I mean is:

• Create a fresh KSP installation with the fewest mods that cause the issue (ideally just KSPCF and SCON, and their dependencies).
• Give me a set of step-by-step instructions that let me recreate the problem.

Videos of you encountering the problem don't really help in this case because, well, I already believe you that you are encountering it. ;) What I need is a way to reproduce the problem under development conditions, so I can figure out what's going wrong.

[MartyrKomplx]

Let's try this again then:

Completely clean "Fresh from Steam" copy of KSP with only latest versions of Module Manager (CKAN), Simple Construction (CurseForge), Harmony (CKAN), and KSP Community Fixes (CKAN) are installed. Using sandbox mode to make sure parts are available (but can reproduce bug in my normal save in career mode).

Create the "Builder"

• Go to VAB
• Select "Mk1 Command Pod"
• Attach "Clamp-o-Tron Docking Port" to top node. (Make sure description of port says "SimpleConstruction Augmented" in Orange at the end)
• Attach "Large Holding Tank (Rocketparts)" to bottom node of Command Pod. (Find part in new "EL Items" parts tab.)
• Adjust slider on Tank to contain full RocketParts
• Save. (I will name it Builder)

Create Simple Crafts to build.

• Only "Mk1 Command Pod" named as desired and save. (I will name it Simple 1)
• Only "KV-1 Onion Reentry Module" named as desired and save. (I will name it Simple 2)
• Only "Probodobodyne Stayputnik" named as desired and save. (I will name it Simple 3)
• Only "KV-3 Pomegranate Reentry Module" named as desired and save. (I will name it Simple 4)

Attempt to build

• Launch "Builder"
• Click on "SC EL" icon on toolbar to open Build menu.
• Click on "Select Craft"
• Select any of the Simple crafts and hit "Load"
• Back on the main Build Menu, observe whether or not a RocketParts Needed/Have section exists.
• Click "Build" button.
• • If Section did not exist, it will proceed immediately to the next window variant.
• • If Section did exist, the window will change to show build progress, with percentage and time remaining, as well as the rocket parts being used.
• Regardless of whether the section exists or not, the next window variant is to "Finalize Build" Clicking this will (ironically enough) finalize the build into the "real" world.
• Close the Build window, and you will see the selected craft sitting, attached to the docking port.

I've observed that Simple 1 & 3 produce the bug in question. Simple 2 & 4 does not.

[NathanKell]

Awesome, thank you! I'll work on this as soon as I have time. :)

[gotmachine]

@NathanKell
I can reproduce this on KSP 1.12.3, SCON 4.0.99.30 (don't try to install this with CKAN, it doesn't work) using EPL 6.99.3 under the hood and the above repro instructions. The issue can be tracked down to the ConfigNodePerf patch, the issue isn't there if I disable it, while disabling all other KSPCF patches has no effect.

Note that the likely root trigger for this issue is in EPL (ExtraPlanetaryLaunchpads), SCON is just a set of alternative configs repackaging EPL.

I think the place where this is happening is in ExtraplanetaryLaunchpads.ELBuildControl.LoadCraft(), calling :

    string text = File.ReadAllText(craftfilename);
    ConfigNode configNode = ConfigNode.Parse(text);

I didn't found any difference when round-tripping that ConfigNode back to a string with and without the ConfigNodePerf patch.

Then EPL load the node in a new ShipConstruct, instantiate/load the Vessel, does some data gathering on the Vessel stats then immediately destroy the Vessel. This is mainly calling stock methods, see ExtraplanetaryLaunchpads.ELBuildControl.getBuildCost().

[gotmachine]

So, gave a look at this because having a bug in the config parser isn't something that we should let fly.

So, as far as EPL is concerned, this is because it calls ConfigNode.Parse("RocketParts = 1"), which ends up being an empty node in KSPCF instead of a node having that key-value pair.
In a similar way, ConfigNode.Parse("k1 = v1\nk2 = v2") ends up with a node that only contains the k1/v1 pair.

The issue is in the KSPCF ConfigNodePerf.ParseConfigNode() implementation, which assume a value is always followed by either a new line char \n or a node closure }. If it reach the end of the string without having encountering those characters, it simply won't write the last value.

[gotmachine]

Fixed in 1.27.0

[NathanKell]

Ugh, thank you got. Sorry I dropped the ball on this.