Mod load order on game servers

Load order is the sequence in which a game reads its mods, and it matters for one reason: when two mods change the same thing, one of them wins. In some games the last mod loaded wins, in others the first, and in a few the loader sorts everything itself from declared dependencies and ignores what you wrote. On a server there is a second rule on top: the server and every client usually need the same mods at the same versions, sometimes in the same order. Most "it worked yesterday" modded crashes are a dependency loading after the mod that needs it, two mods editing one record, or a client whose list differs from the server's. This post explains the mechanics once and then goes game by game.

Three things that get confused#

People say "load order" for three different problems, and they have different fixes.

1. Dependency order. Mod B uses code or data from mod A, so A must be loaded first. Get it wrong and B fails, usually with a missing-class, missing-addon or nil-reference error at startup. This is the one that stops servers booting.
2. Override order. Mods A and B both change the same value - the stack size of wood, the stats of a rifle, a loot table. Both load, and whichever applies last (or first, depending on the game) is what you get. Nothing crashes; a setting just does not do what you expected.
3. Code conflicts. Two mods patch the same function in the game's code. Order may help, or it may not matter because the patches are incompatible whatever the order. This produces the strangest crashes and the longest evenings.

The first is solved by order or by the loader. The second is solved by deciding which mod should win and arranging for it to. The third is solved by removing one of the two mods, or finding a compatibility patch someone has written.

Last wins, first wins, or the loader decides#

Knowing which model a game uses tells you what to try. In a last-wins game, move the mod you want to win lower in the list. In a loader-sorted game, moving things around in a folder does nothing; you fix the dependency declaration or remove the conflict. In a startup-order game, a dependency simply has to start before the thing that uses it.

Minecraft: the loader decides#

Forge, NeoForge and Fabric do not have a user-editable load order. You drop jars into mods/ and the loader reads each mod's metadata - META-INF/neoforge.mods.toml on current NeoForge, META-INF/mods.toml on Forge and older NeoForge, fabric.mod.json on Fabric - builds a dependency graph, and sorts it.

What you control is which jars are present. The errors you see are therefore about presence and versions:

Mod create requires flywheel 1.0.0 or aboveCurrently, flywheel is not installed

Fabric's metadata has depends, recommends, breaks and conflicts fields. A breaks entry stops the server with a clear message naming both mods; conflicts only warns. NeoForge's equivalent is a dependency type of required, optional, incompatible or discouraged. Read these messages literally - they are among the clearest errors any modded game produces.

Code conflicts in Minecraft come from Mixins, the system mods use to patch the game's code. Two mods injecting into the same method can crash with a MixinApplyError or InvalidInjectionException naming the target method. Order cannot fix that; one mod has to go, or a newer version has to fix it. Modded Minecraft without the crashes goes further into reading these.

Paper plugins are a different system with the same idea. Each plugin's plugin.yml declares depend (hard dependency - the plugin will not load without it), softdepend (load after it if present) and loadbefore. If a plugin fails with "Unknown dependency", the named plugin is missing, not out of order.

name: MyShopdepend: [Vault]softdepend: [LuckPerms, PlaceholderAPI]

Arma 3 and DayZ: the -mod line#

Bohemia's games load mods from the -mod= launch parameter, separated by semicolons, in the order written:

-mod="@CF;@Dabs Framework;@DayZ-Expansion-Core;@DayZ-Expansion-Vehicles"-serverMod="@ServerOnlyTools"

Two orders are actually at work. The -mod order decides which folders are loaded first. Inside the mods, each addon's config.cpp declares requiredAddons in its CfgPatches class, and the engine uses that to order the config classes themselves. A mod that declares its dependencies properly works in nearly any -mod position; one that does not depends on you putting its prerequisites first. The rule of thumb is frameworks first (Community Framework, CBA_A3 in Arma 3), then large content mods, then the mods that patch them, then small tweaks.

-serverMod loads mods only on the server, which is right for admin tools and server-side scripts that clients should not need. Anything that adds items, vehicles or map objects must be in -mod, and every client must load it too.

Signature keys are the other half. Each mod ships a .bikey in its keys folder, and the server only admits clients whose mods are signed by a key present in the server's own keys directory (with signature verification on). A client kicked for a signature mismatch usually has a different version of a mod, not a different order. The DayZ side is covered in DayZ server and mods, and Linux servers add a case-sensitivity trap described in Linux vs Windows game servers.

7 Days to Die: alphabetical folders and XPath#

7 Days to Die loads every folder in Mods/ that contains a ModInfo.xml, in alphabetical order of folder name. The game itself ships one there, 0_TFP_Harmony, which is why the convention of numeric prefixes exists: renaming a folder to 1_SomeMod or zz_MyTweaks is how you move it in the order.

Most mods do not replace the game's XML files; they patch them with XPath operations:

<configs>  <set xpath="/items/item[@name='resourceWood']/property[@name='Stacknumber']/@value">1000</set></configs>

Patches apply in load order, each on top of the result of the last, so the last mod to set a value wins. That is why a personal tweaks mod belongs at the end, with a name like zz_. If an earlier mod has removed the node a later one tries to patch, the later patch fails, and the log says so. Search it for XPath warnings after every mod change; they are the overlooked cause of "my setting did nothing". Overhaul mods such as Darkness Falls rewrite so much that most other mods need a compatibility version to sit beside them. More on that in 7 Days to Die admin commands and mods.

Factorio: dependencies in info.json#

Factorio orders mods from each mod's info.json. The dependencies array uses prefixes:

"dependencies": ["base >= 2.0", "? space-age", "! some-conflicting-mod"]

Beyond the dependency graph, the order is by mod name, so you cannot rearrange it by hand. Factorio also checks the mod list strictly: clients must have exactly the server's mods and versions, and the game offers to sync them on join from the mod portal. Factorio mods and UPS performance covers the cost side.

RimWorld, Zomboid, ARK, FiveM and others#

RimWorld

RimWorld's order is the activeMods list in ModsConfig.xml, and later mods override earlier ones. The convention is Harmony first, then Core (ludeon.rimworld), then the DLCs, then frameworks, then content, then patches. Each mod's About/About.xml can declare loadAfter, loadBefore and modDependencies, and sorting tools such as RimSort read those and arrange the list for you. For multiplayer through the Multiplayer mod, every player needs the same mods in the same order; the mod checks and refuses mismatches. The RimWorld multiplayer server guide covers syncing them.

Project Zomboid

Zomboid's server ini lists mods on two lines that must agree: WorkshopItems= holds the Workshop IDs to download, Mods= the mod IDs to enable, both separated by semicolons. Maps go on a third line, Map=, where order is significant: custom maps come first and the base map, Muldraugh, KY, comes last, or the custom map's cells are covered by vanilla ones. Build 42 changed some of the mod-ID conventions, so copy IDs from each mod's current Workshop page rather than an old guide. Project Zomboid mods and Workshop has the details.

ARK

On ARK: Survival Evolved, ActiveMods= in GameUserSettings.ini listed Workshop IDs, and when two mods provided the same asset, the one listed first won - the reverse of most games. ARK: Survival Ascended moved to CurseForge mods passed with -mods= on the launch line. Put the mod you want to take precedence earlier, and keep map mods in their documented position.

FiveM

FiveM resources do not override each other; they start in the order of ensure lines in server.cfg, and a resource that calls another's exports must start after it. Resources can also declare dependencies in fxmanifest.lua, and FiveM will start those first or refuse with a clear message. The usual order is database connector, then framework, then framework resources, then everything else:

ensure oxmysqlensure ox_libensure qb-coreensure [qb]ensure [standalone]

Bracketed names are folders of resources started together. FiveM frameworks: ESX, QBCore and Qbox explains why the framework has to be up before its dependants.

Valheim and other BepInEx games

BepInEx has no user-facing order at all. It loads every plugin DLL in BepInEx/plugins, and a plugin that needs another declares it in code with a BepInDependency attribute, either hard (the plugin will not load without it) or soft (load after it if present). A missing hard dependency is reported in BepInEx/LogOutput.log with the plugin skipped. Conflicts are Harmony patches from two mods on the same game method, which show up as errors naming the method. The Valheim BepInEx server guide covers which mods must also be on clients.

SourceMod

SourceMod loads .smx plugins from addons/sourcemod/plugins, and anything moved into the disabled subfolder is skipped. Plugins that depend on another plugin's natives or on an extension fail to load with an error in the SourceMod error log until the provider is present; sm plugins list shows which loaded and which failed. Order rarely matters beyond that, but two plugins hooking the same event and changing the same value can fight, with the result depending on which hook runs last. Disabling one of the pair is the quickest way to confirm it.

Client and server must agree#

On most modded servers, the server's mod list is a contract every client has to match:

• Content mods - new items, creatures, blocks, vehicles, maps - must be on both sides at the same version.
• Server-only mods - admin tools, backups, anti-cheat, Discord bridges - only on the server.
• Client-only mods - interface, minimaps, shaders - only on clients, and on Minecraft some crash a server if installed on it.

A mismatch shows up as a refused connection, a kick a few seconds after joining, or objects that exist for some players and not others. Valheim's BepInEx mods, Minecraft modpacks and Factorio enforce this explicitly; others leave you to find it in desyncs. Publishing the exact list, with versions, is half the work of running a modded server. Running a modded server for friends covers keeping a group in step.

Finding the conflict#

When a modded server breaks and the order is the suspect:

1. Read the first error, not the last. The first exception or missing-dependency line names the mod that failed to load. Everything after it is fallout.
2. Check dependencies before order. Most "load order" problems are a missing or wrong-version dependency.
3. Look for override warnings. 7 Days to Die's XPath failures, RimWorld's red errors at startup, Fabric's conflicts warnings.
4. Bisect. Disable half the mods, test, and keep halving the half that contains the fault. Twenty mods take five rounds. What to do when a mod update breaks has the full procedure.
5. Change one thing at a time, and keep a backup of the working mods folder before each change.

On RE:NODE there is no list of approved mods: you upload them through the file manager or SFTP, or use the game's own Workshop support, and the console shows the loader's output line for line. Backup slots on every game plan mean the working mods folder, configs and world can be restored with a button if a change goes wrong.

FAQ#

Does mod load order matter on Minecraft servers?

Not in the sense of arranging a list. Forge, NeoForge and Fabric sort mods from their declared dependencies. What matters is that every dependency is present at a compatible version and that no two mods patch the same code incompatibly.

Which mod wins when two mods change the same thing?

It depends on the game. In 7 Days to Die and RimWorld the later mod usually wins; in ARK: Survival Evolved the earlier one did; in Minecraft and Factorio the loader decides from dependencies. Check which model your game uses before reordering.

Do players need the same load order as the server?

In games that check the mod list strictly - RimWorld Multiplayer, Skyrim Together, Factorio - yes, or at least the same list and versions. In Arma 3 and DayZ the server's -mod list governs, and clients need the same mods and signatures.

Why does my mod not load even though it is in the folder?

Usually a missing dependency, a version built for a different game or loader version, or, on Linux, a folder name whose case does not match the launch line. The log names the reason in the first few lines after the mod is mentioned.

Is there a tool that sorts mods automatically?

For some games. RimSort for RimWorld reads mod metadata and arranges the list; Minecraft and Factorio sort themselves. For Arma 3, DayZ and 7 Days to Die you mostly follow each mod's documented position and its dependencies.