Thoughts on mod conflicts

We all play with a good amount of mods and we have no clue what is happening under the hood. Not all conflicts result in an error or game breaking crash.

I want to explain the different types of conflicts we can experience and brainstorm about possible solutions for each type.

Non-breaking conflicts

A good example for this type of conflicts are mods that make changes to pallets. There are mods that increase the capacity of pallets and some make them lightweight. These are likely to be console compatible mods, thus not having any scripts.

The game loads in the mods in alphabetic orders and with these script-less mods, the data is overwritten by the next - if they do the same thing of course.

Multiple mods overriding the pallet for, let us say, flour, the last one loaded will win in-game.

Sometimes you do not even notice a mod overrides something in the background and you are stuck wondering why another mod does no longer work.

Breaking conflicts

Looking at you script mods.

Because all scripts are loaded and the game does execute all code, mods using the same basegame code have a chance of creating a conflict.

Anything conflicting does not mean your game will freeze or crash, sometimes it results in a massive repetition of Lua callstacks in your game log.

An example I know of is MaizePlus and Swathing Addon, both add new and different types to mowing. Having both these mods active can cause your game to crash when using a mower.

How should we approach (known) mod conflicts?

Should we even bother to check for other active mods? If known conflicting mods when for eachothers existance and both have a different approach to solving the original conflict, could that not create new conflicts?

Can we add Lua pcall function to catch errors, inform the player, and move on? This is something I want to test thoroughly.

Can the game engine provide methods to safely execute code and assert outcomes? This would not make sense from a programming perspective, really.

What can we do about non-breaking conflicts, like the pallet example mentioned earlier? Nothing with the current state of the game engine. An option to improve this would be only to override the XML attributes that exist in the mod. This would not help the pallet issue, but it would allow certain things to "merge" when they both adjust a different value.

Should the ModHub QA test for conflicts?

I do not think it is their responsibility to police all modders on possible conflicts. There are also too many mods and cross-check. Also, QA does not look at the code at all.

Should we expect modders to test their mod with every known mod to humankind? Would not hope so, they already spent plenty of time creating the mod.

Final thoughts

For now. There is a lot to say about this topic, but I like to keep things short.

In an Utopian Farming Simulator world, modders would try to reach out to eachother and see if they can resolve conflicts. Despite it not always being possible to resolve mod conflicts, we can list known conflicts in the mod description. Now if only players would read mod descriptions. More on mod descriptions coming soon.