XPath Patching - Modular Modding

Currently, your system of XML modding requires that you overwrite entire segments in order to change one thing. This system is extremely inefficient, and causes incompatibility with mods that want to modify the same section of code. One example of mine, is that one mod of mine, disables a set of DLC blocks from the game. These DLC blocks share a Block Variant Group with other DLC blocks. Now, if someone only uses this one mod, those blocks will be removed from that group. However, I have a second DLC that blocks the other blocks that share that same BVG. Now both mods conflict, because the BVG can only be modified once, by one mod. Now the most recently loaded mod overrides that group, and allows the blocks that are disabled, to be enabled again through groupings.

This isn't the only case though, there are multiple applications for xpath patching. Lets take a look at how it could theoretically be used, to add a new crafting category to the Survival Kit, without overwriting the entire survival kit:

<Patch>
  <Operation Class="PatchOperationAttributeAdd">
    <xpathIdentify>/CubeBlocks/Definition[SubtypeId="SurvivalKitLarge"]/</xpathIdentify>
    <xpath>/Definition/BlueprintClasses/</xpath>
    <value>
      <Class>BasicIngots</Class>
    </value>
  </Operation>
</Patch>

Now with this example, I used a copy of what Rimworld uses for its xpathing, slightly modified to identify a particular item in a particular cubeblock, as SE does things differently than Rimworld. In the above example, I locate the cubeblock "SurvivalKitLarge", and run the patch operation "add", to add <class>BasicIngots</class> to the BlueprintClasses section. Without touching any other part of the survival kit code. This means that someone else can modify the survival kit as well. Say, they want to change its component costs. They can easily run another patch operation, and patch the crafting costs, without affecting the above patch at all. Two mods could then modify the same block without conflicting.

Patch operations can do lots of things, add, remove, set (overwrite). You can also run tests to see if block or mod exists before doing a patch. A patch with an if/else statement basically. "If mod-6783246 exists, patch add this to that" "if this-object exists, patch remove this". So on so forth.

I will now show the Rimworld xpath page to show how they implemented this feature to prevent mod conflicts like what we have in SE, as an example of an existing, working system.

https://rimworldwiki.com/wiki/Modding_Tutorials/PatchOperations

XPath isn't something new to this one game either!

https://www.w3schools.com/xml/xpath_intro.asp

Patching process begins after all mods have been loaded, that way the patches can then be applied. So regardless of mod load order, any "patches" would be saved till all the content has been loaded, and then the patches would be loaded in their discovered order. If possible, it would be great to mark patches that load after a specific mod, so that the patch can be applied in a proper order if multiple patches are required on the same object in the same category.

E.G. A mod patches the assembler to handle three new groups of items, and another mod re-patches that same assembler to remove one of those three new groups. Therefor, that mod would need to check for "mod-82634345 existence" and then if it does, load after it. This presents the risk of loops if a troll decides to check for the existence of a mod uploaded after his own where both check each other. Such a loop should be caught and disable both mods from loading in order to punish the authors for doing such.

Not everyone can code in C# to alter the game in an advanced way as some people currently do. This patching method would help lots of people make better mods for the game without causing mod conflicts all the time. A simple Patch folder inside mods, that has patch XML files in it to tell the game what to overwrite where, would be a tremendous boost to the modding community.

One thought I have for patch orders too, is something I saw while modding Factorio, where they have patch file names that determine which order the patch is run in. So what we could do for SE, is "FirstPassPatching.xml" "SecondPassPatching.xml" and then "FinalPassPatching.xml", three files, each determines their order. The game would then take all 1st Pass patches, in the order they were loaded in the mod list and put them after the completion of all the loaded content. Then add the 2nd Pass content in the same order they were loaded, after the 1st Pass content, and then the Final Pass content after that. Allowing modders to determine where their patch should fall so that someone can then patch on top of theirs, in the event that you don't allow modders to run mod checks to determine if a patch should fall after theirs. Factorio also has a unique system for that as well, but alas I am unable to figure out a good way to do it for this game right now.

I sincerely hope that the community of the game, and that the developers, find this idea extremely useful and worthy of doing. This would quite honestly, save a lot of headaches once people get used to the system and would add a lot more modularity to the workshop.