You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some MOLE engines ("WB-2 Corvette", "LV-T270 Fulcrum"...) have stock upgrades defined, notably an ISP upgrade applied at the precision propulsion node. With KSPCF installed, these upgrades somehow result in an ISP of 0.001 once applied.
Debugging indeed show that on the PartModule.ApplyUpgradeNode() call, the following node is being applied to the module :
The incorrect node is the result of a ConfigNode.CopyTo() call (with overwrite: true), when the upgrade node is copied to the node effectively applied on the PM. KSPCF indeed patches the ConfigNode.CopyToRecursive() method, so I guess we have a bug in there involving multiple same-name values. This piece of code does indeed looks quite sketchy :
for (int i = 0, iC = __instance._nodes.nodes.Count; i < iC; ++i)
{
ConfigNode sub = __instance.nodes[i];
if (overwrite)
{
node._nodes.RemoveNode(sub.name);
}
ConfigNode newNode = new ConfigNode(string.Empty); // will be set above when we recurse.
node._nodes.nodes.Add(newNode);
ConfigNode_CopyToRecursive_Prefix(sub, newNode, overwrite);
}
In particular, the fact that we recurse passing overwrite. Stock does not. However, stock is subject to a different bug, wherein copying a node without overwrite will lead to duplicate subnodes rather than merged subnodes. Well, that's not necessarily a bug, but either way it's probably behavior we need to retain.
Repro setup :
Some MOLE engines ("WB-2 Corvette", "LV-T270 Fulcrum"...) have stock upgrades defined, notably an ISP upgrade applied at the precision propulsion node. With KSPCF installed, these upgrades somehow result in an ISP of 0.001 once applied.
Debugging indeed show that on the
PartModule.ApplyUpgradeNode()
call, the following node is being applied to the module :However, the node referenced in the upgrade is correct :
The incorrect node is the result of a
ConfigNode.CopyTo()
call (withoverwrite: true
), when the upgrade node is copied to the node effectively applied on the PM. KSPCF indeed patches theConfigNode.CopyToRecursive()
method, so I guess we have a bug in there involving multiple same-name values. This piece of code does indeed looks quite sketchy :KSPCommunityFixes/KSPCommunityFixes/Performance/ConfigNodePerf.cs
Lines 361 to 367 in 213177b
The text was updated successfully, but these errors were encountered: