Proposal: .patch system for better mod compatibility

[Thundercraft]

Often, we can use several mods together without much issue. However, sometimes, mod conflicts can cause players a lot of grief, especially if they are trying to use a lot of mods together. Just tracking down the culprit can be a frustrating task. And I have to wonder if this may be discouraging some players from using mods altogether.

When I was learning how to mod for Starbound (a sandbox akin to Terraria in space), I read the following announcement. It struck me as an innovative approach to maximizing mod compatibility and reducing the likelihood of issues:
August 19 – The day when all your mods died.

This .patch system allows modders to easily change a single line (or even part of a line) in their JSON files, without having to replace entire files or entire sets of data. The "op" operator can take "test", "add", "replace", "move", and "copy" commands, to change, remove, or shuffle data around.

Granted, the situation with RimWorld mods is different. Instead of using JSON, it involves .XML files and/or maybe compiling a .DLL. And modders can opt to change just one item in a file, rather than replace the whole thing. However, with lots of mods, it is inevitable that several of them will try to change some of the same vanilla items.

Wouldn't it be nice if we could "add" new tags to a vanilla item (say, the stonecutter's table) or perhaps "replace" something (say, the <SharpDamageMultiplier> of steel) and do this in a way that would not automatically cause a conflict or other issues with other mods?

Often, we can deal with mod conflicts by making sure that the mod we arbitrarily place more importance on is later in our load order, to make sure those changes take priority. But this does not always work. Sometimes, the only solution is to either disable an offending mod or manually combine the two.

For example, Combat Realism has nearly 600 files and many of these make changes to vanilla items! It's no wonder, then, that it conflicts or causes issues with so many other mods. I'm no expert, but it seems like large mods such as CR depend heavily on the changes it makes to vanilla files, such that any changes other mods make to the same files are likely going to cause problems.

[Thundercraft]

Only 41 views an no replies? 

Isn't there a desire for better mod compatibility? With their new .patch system, mod conflicts are quite rare in Starbound. Just imagine if RimWorld players were able to use huge mods like Combat Realism without worrying about compatibility with other mods.

[Thundercraft]

I just discovered notfood's documentation for MFO (Mod Friendly Overrides). From reading it... that sounds a lot like what I was talking about. I had no idea it could do stuff like that.

(BTW: notfood's Mod Friendly Overrides original post and discussion is buried inside the Miniaturisation Overloaded topic, so it seems easy to miss.)

It sounds like if more modders used MFO (or overrides) to make changes to vanilla stuff, then mod conflicts would be much less common.

[Lightzy]

Cuz it's a good suggestion and not much idea to develop, so not much replies.

Yeah since rimworld is a VERY mod-heavy game, just.. yeah.

[Fluffy (l2032)]

xml patches/overrides/injections would be a nice thing to have, but those incompatibilities are generally more or less trivial to begin with, they just require a bit more busywork replacing whole defs instead of just patching a value or two.

The real problematic incompatibilities are in .dll conflicts, where only better coordination between modder(s) involved is going to make any real difference.

Mind you, 'patchers' would be nice tools, but they're not the answer to mod incompatibilities.

[Thundercraft]

I just discovered AlcoholV's Ac-Override Injector. In some ways, this is similar to notfood's MFO. However, MFO can do a lot of things that Override Injector can't.

Override Injector only has one use. But that makes it a lot easier to use. It's perfect for changing the values of specific tags without having to copy or replace a whole def or a whole set of data.

For example, I used Override Injector to directly change the <fuelCapacity> of the PodLauncher. One line of code is all it took:

Code Select Expand

<LanguageData>

<PodLauncher.comps.0.fuelCapacity>300</PodLauncher.comps.0.fuelCapacity>

</LanguageData>

To accomplish the same thing with MFO required replacing the whole <comps> section (with less potential mod compatibility):

Code Select Expand

<Defs>

<Override.Def Target="PodLauncher">

    <comps Mode="Replace">
      <li Class="CompProperties_Refuelable">
        <fuelCapacity>300.0</fuelCapacity>
        <targetFuelLevelConfigurable>true</targetFuelLevelConfigurable>
        <initialConfigurableTargetFuelLevel>75</initialConfigurableTargetFuelLevel>
        <fuelFilter>
          <thingDefs>
            <li>Chemfuel</li>
          </thingDefs>
        </fuelFilter>
        <consumeFuelOnlyWhenUsed>true</consumeFuelOnlyWhenUsed>
        <autoRefuelPercent>1</autoRefuelPercent>
        <showFuelGizmo>true</showFuelGizmo>
        <drawOutOfFuelOverlay>false</drawOutOfFuelOverlay>
<drawFuelGaugeInMap>true</drawFuelGaugeInMap>
      </li>
    </comps>

</Override.Def>

</Defs>

xml patches/overrides/injections would be a nice thing to have, but those incompatibilities are generally more or less trivial to begin with, they just require a bit more busywork replacing whole defs instead of just patching a value or two.

I think you're missing the point. XML patches, overrides, and injections are not really about making it easier for modders to mod. Rather, it's more important that mod users can use a lot of mods together without error messages, lost functionality, or worse.

The common practice of "replacing whole defs instead of just patching a value or two" is a major culprit of mod conflicts. Different mods may try to change different aspects of the same defs. But there would be no reason for them to not work alongside each other if mods could freely change or insert whatever XML code they needed to without throwing out the baby with the bath water.

For instance, one mod may add "Neutroglycerin" to Boomalopes and Boomrats as a milkable item to make drugs or explosives. Another mod may change Boomalope leather. Still another may make Boomalopes trainable so they can haul like dogs. And yet another (Combat Realism) may add FSX to Boomalopes and Boomrats as a shear-able material.

Have you tried to get Combat Realism to work with mods? It replaces so many vanilla files and vanilla defs that it seems incompatible with a good chunk of the mods out there. Aside from everything guns and combat related, it also changes:

• humans
  
• mechanoids
  
• boomalopes
  
• boomrats
  
• oribital/outlander/caravan traders
  
• food (all raw food ingredients and all cooked meals)
  
• stone chunks
  
• all resources like wood, silver, gold, steel, plasteel, etc., etc.
  
• medicines (all of them)
  
• factions (pirate, tribe and outlander)
  
• and much, much more

What does stuff like food and stone chunks have to do with combat, you might ask? Well, a lot CR's changes are done solely to add <Bulk> tags to everything.

With something like MFO, though, <Bulk> tags could have been inserted without replacing everything outright and without affecting mod compatibility.

The real problematic incompatibilities are in .dll conflicts, where only better coordination between modder(s) involved is going to make any real difference.

Those may be more problematic. And, unlike XML conflicts, it does sound like the only solution is better cooperation between modders. But while I may not be as knowledgeable in .dll modding, in my experience XML conflicts seem a lot more commonplace.

Perhaps if more modders took advantage of XML tools like MFO or Override Injector, then the importance of XML conflicts would give way to .dll conflicts. But such tools remain largely unused and unheard of. I'm not aware of a single mod that takes advantage of MFO. And the only mods that use Override Injector (that I could find) are the author's own Quiet Weather and my Mid-Range Drop Pods: MF.