RimWorld Multiplayer mods: compatibility and load order

Most RimWorld mods work with the Multiplayer mod, and the ones that do not fail in a predictable way. Mods that only add data - new items, animals, apparel, buildings, factions written in XML - are always compatible, because there is nothing in them to desync. Mods with C# code are where the trouble is: anything that adds a button, a gizmo or a menu that changes the game has to be synchronised, and anything that rolls its own random numbers or keeps its own timers has to be patched. The Multiplayer mod shows a crowd-sourced score for every mod in your list, the Multiplayer Compatibility mod patches a long list of popular ones, and the load order is fixed at the top: Prepatcher, Harmony, Core, your DLCs, then Multiplayer. The rest of this guide is how to read the scores, build a list four people can share, and prove it works before you sink sixty hours into a colony.

If you have not chosen between the Multiplayer mod and RimWorld Together yet, read the RimWorld multiplayer server guide first. This post is only about the Multiplayer mod - one shared colony, deterministic lockstep, every machine running the same simulation - because that is the one where mod compatibility decides whether you can play at all.

Why some mods break multiplayer and others do not#

The Multiplayer mod does not send the game state across the network. It sends commands. When a player drafts a pawn, changes a bill or designates a tree for cutting, that action is wrapped up, stamped with a tick and executed on every machine at the same moment. Every copy of the colony then computes the same result, because RimWorld's simulation is made deterministic by the mod: random numbers are seeded identically, and anything that would differ between machines is either synchronised or kept out of the simulation.

A mod breaks this in one of three ways.

1. It changes the game from the user interface without going through sync. A new gizmo, a right-click option, a settings window that edits a building. The click happens on one machine only, the other machines never hear about it, and the colonies diverge. This is the most common problem, and it is the one compatibility patches fix - they tell Multiplayer which methods to sync.
2. It uses randomness or state the mod cannot see. Code that calls a random number generator outside RimWorld's own, reads the system clock, caches results based on what the local player is looking at, or does work on a background thread. Two machines get two answers.
3. It changes how ticking works. Performance mods that skip, batch or throttle ticks for things off-screen are a particular risk, because what is on screen is different for every player. Some of these have been made compatible; check before assuming.

XML-only mods avoid all three, which is why the in-game compatibility window says outright that they are always compatible. The catch it also states: an XML mod can depend on a framework mod that has C# code, and that framework then has to be compatible too.

Checking a mod: the scores and where to find them#

The Multiplayer mod adds a Multiplayer compatibility button to RimWorld's own Mods screen. It opens a window listing your active, installed and outdated mods with a status score and notes for each. The data is crowd-sourced and downloaded from the Multiplayer team's server, cached locally in the MpCache folder, and can be switched off with the "Show crowd-sourced compat info" setting if you would rather not fetch it.

The same scale (with 0 for untested) is used in the community spreadsheet linked from the mod's Workshop page and in the Discord's mod-report channel, which is where the scores come from. Treat them as a starting point, not a guarantee. A 4 means someone played with that mod and saw no problems; it says nothing about how it behaves next to the other 150 mods in your list. The Multiplayer team's own FAQ makes the point directly: two mods that are each listed as fully compatible can still desync together.

How to act on each score:

• 4: include it.
• 3: read the notes. "Minor" is usually one button or one window that does not sync. If your group will not use that feature, it is effectively a 4.
• 2: only if the broken part is something you can avoid entirely, and test it on purpose.
• 1: leave it out. No amount of load-order shuffling fixes a score of 1.
• Unknown: test it yourself, and report what you find so the next group does not have to.

Scores are tied to versions. A mod rated 4 two RimWorld versions ago may have rewritten half its code since, and the "Outdated" section of the window exists for exactly that reason.

The Multiplayer Compatibility mod#

Multiplayer Compatibility (package id rwmt.MultiplayerCompatibility, by the same RimWorld Multiplayer Team) is a single mod full of patches for other people's mods. It contains no content of its own. For each supported mod it registers the methods that need syncing, marks the ones that must run only locally, and fixes the randomness - the work the original mod author would have done if they had written for multiplayer.

The supported list is long and changes constantly. At the time of writing it includes the Vanilla Expanded framework and much of the Vanilla Expanded series, Common Sense, Simple Sidearms, Pick Up And Haul, RimFridge, LWM's Deep Storage, Prison Labor, Alpha Animals and Alpha Biomes, among many others. The authoritative list is the mod's own description and its GitHub README, not a forum post from last year.

Three rules:

• Install it whenever you run any C# mods. It does nothing for mods it does not patch, so it costs nothing to have.
• It needs the current Multiplayer. It declares Multiplayer as a dependency and is updated alongside it. An old copy of one with a new copy of the other is a version mismatch waiting to happen.
• A mod being in its list does not make the mod a 4. The patch may cover the main features and leave the rest. The score in the compatibility window is still the thing to read.

Some mods do not need it at all because their authors support multiplayer natively - they call the Multiplayer API themselves. Achtung! is the usual example. Those show up as compatible without any patch.

Load order for a multiplayer modlist#

RimWorld's load order is the activeMods list in ModsConfig.xml, and later mods override earlier ones. For the general rules - dependencies, overrides, code conflicts - see mod load order explained. For Multiplayer the top of the list is fixed by the mods' own metadata, and getting it wrong produces errors at startup rather than subtle bugs.

• Prepatcher goes first, above Harmony and above Core. Current Multiplayer releases list it as a hard dependency (it replaced the old Harmony dependency in the 0.11 line), and it is also what makes rituals work in multiplayer.
• Harmony next. Prepatcher bundles its own copy of Harmony, but most other code mods still declare brrainz.harmony as a dependency, so keep it.
• Core and the DLCs in their usual order: Royalty, Ideology, Biotech, Anomaly, Odyssey.
• Multiplayer directly below the last DLC. The mod's description says so in bold, and its metadata declares it loads before HugsLib and the Vanilla Expanded framework.
• Multiplayer Compatibility immediately after Multiplayer.
• Then frameworks (HugsLib, the Vanilla Expanded framework and so on), content mods, and patch mods last.

<activeMods>  <li>zetrith.prepatcher</li>  <li>brrainz.harmony</li>  <li>ludeon.rimworld</li>  <li>ludeon.rimworld.royalty</li>  <li>ludeon.rimworld.ideology</li>  <li>ludeon.rimworld.biotech</li>  <li>ludeon.rimworld.anomaly</li>  <li>ludeon.rimworld.odyssey</li>  <li>rwmt.multiplayer</li>  <li>rwmt.multiplayercompatibility</li>  <li>unlimitedhugs.hugslib</li>  <li>oskarpotocki.vanillafactionsexpanded.core</li>  <!-- content mods, then patches --></activeMods>

The file lives in the Config folder of RimWorld's save data: %USERPROFILE%\AppData\LocalLow\Ludeon Studios\RimWorld by Ludeon Studios\Config on Windows, ~/.config/unity3d/Ludeon Studios/RimWorld by Ludeon Studios/Config on Linux. You rarely need to edit it by hand - the in-game Mods screen and sorting tools such as RimSort write it for you, reading each mod's loadAfter, loadBefore and modDependencies - but it is the one place to look when you want to know what the game actually loaded.

Order matters more in multiplayer than in single player for one simple reason: the join check compares it. If everyone has the same mods in a different order, the joining player is told the lists match but the order does not, and has to restart.

DLCs and versions: everything must match#

The Multiplayer team's answer to "do we need the same DLCs" is that everything needs to be the same. A player without Biotech cannot join a game where the host has Biotech enabled, because the host's world contains Biotech definitions the client cannot load. The practical consequence is that a group's DLC set is the intersection of what everyone owns. If one friend has only the base game, either they buy the DLCs or everyone disables theirs for this colony.

Support for each DLC also arrived at different times. Royalty and Ideology have been supported for years. Anomaly support came in stages through the 1.5 releases, with rituals and some of its mechanics fixed later than the rest, and the team's FAQ warned of desyncs with it for a long time. Odyssey and gravships are supported in the 1.6 releases, which are still being actively fixed. If you are planning a long colony around the newest DLC, read the latest release notes on the Multiplayer GitHub releases page first, and test the DLC's headline mechanics specifically (see the test plan below).

Versions have to match at three levels:

Multiplayer tracks the current RimWorld version and states a minimum build in its description; the team does not test new mod versions against old game versions. Keep everyone on the latest public RimWorld build, and do not opt into a beta branch unless the whole group does it together.

What the join screen checks, and Sync configs#

When a player connects, Multiplayer compares their game with the host's and shows a Data mismatch screen if anything differs. It has four tabs, and each one tells you something different.

• General: RimWorld version and Multiplayer version. Nothing else can be fixed until these match.
• Mod list: the host's mods against yours, with "Not installed" against anything missing. "Subscribe to missing" subscribes you to every missing mod that is on the Workshop and downloads them in the background. "Apply server's mod list" replaces your active list with the host's - your own list is overwritten, so save it first if you care about it.
• Files: mods with the same name but different files. Usually one player has an older version, or an update left files behind. The fix is to update or resubscribe to the mod; for Core and DLC differences, the screen tells you to delete their folders and verify the game files in Steam.
• Configs: mod settings that differ.

After any change the game restarts and reconnects you automatically once it has loaded.

The configs part is controlled by the host's Sync configs option when hosting. With it on, joining players temporarily use the host's mod configuration files: nothing on disk is overwritten, and a restart puts your own configs back. The mod's own description of it is accurate - it reduces desyncs. It also warns that some mods keep sensitive things in their configs, such as the Twitch tokens used by streamer mods, so a host running one of those should think before sharing.

Leave Sync configs on unless you have that reason. A mod setting that differs - a slider in a storage mod, a toggle in a combat mod - is invisible until the moment it produces a different result, and then it is a desync with no obvious cause.

Building a shared modlist that stays shared#

The Multiplayer mod will happily copy a mod list from host to client. It will not stop the list drifting over the following weeks. These are the habits that do.

1. One person owns the list. Usually the host. Everybody else suggests; one person adds, scores and tests.
2. Start from the compatibility window, not from a Workshop collection someone else made for single player. Go through the active list and remove every 1, read the notes on every 2 and 3, and mark the unknowns for testing.
3. Keep it smaller than your single-player list. Every C# mod is another chance of a desync, and every desync costs the whole group a reload. Content mods that are pure XML are cheap; quality-of-life mods with new buttons are where to be selective.
4. Publish it as a Steam collection. Everyone subscribes to the collection and nothing else, so updates arrive for everyone together. The join screen's "Subscribe to missing" then has almost nothing to do.
5. Send the order as a file. RimWorld's Mods screen can save the active list to a .rml file in the ModLists folder of the save data, and load one back. Send that file, not a screenshot.
6. Freeze updates during a run. Steam updates Workshop mods whenever it likes. A mod that updates on one machine on Tuesday is a Files mismatch on Wednesday, or worse, a version that has quietly lost its multiplayer support. If a mod update breaks the list mid-colony, what to do when a mod update breaks has the recovery steps, and the general mechanics of Workshop syncing are in Steam Workshop mods on dedicated servers.

Players who are not on Steam have to install every mod by hand, in the exact versions the host has. It works, and it is the single most common source of Files mismatches. If one player is on a different storefront, put the whole list in a zip on the same day and have them install from that.

Testing before a long colony#

A modlist that loads is not a modlist that works. Desyncs appear when a specific code path runs, and some code paths - a raid, a caravan, a ritual - may not run for the first ten in-game days. Spend an evening on a throwaway colony first. It is the cheapest hour in the whole run.

Host the test with the arbiter on. The arbiter is a background copy of the game that the host runs alongside the real one, used only to detect and pin down desyncs; it costs the host's machine real memory and CPU, so turn it off again for the real colony if the host's PC is not strong. The "Desync traces" option logs extra stack traces that make a desync report far more useful, though it does not work on 32-bit or ARM processors such as Apple Silicon.

Then, with at least two players connected, deliberately do each of these:

• Use dev mode to fire a raid and fight it, with drafted pawns from both players.
• Form a caravan, travel, and come back. Visit a settlement and trade.
• Use every new gizmo and button the mods add, from both players' machines, not only the host's.
• Change a mod's settings mid-game, if you expect anyone to do that during the real run (or agree that nobody will).
• Run a ritual and, if you use them, the headline mechanics of your newest DLC - gravships on Odyssey, the anomaly-specific events on Anomaly.
• Save, quit, reload, and have everyone rejoin.
• Play an hour at the fastest speed the group will use, with the host watching their frame rate.

If something desyncs, the game says so and writes a report to the MpDesyncs folder in the save data. Remove the most recently added C# mod, or the one whose feature you were using when it happened, and repeat that action. When you find the culprit, check its score and notes again, and if it was listed as compatible, the desync report is what the Multiplayer team needs.

Two settings to decide before you start, because changing them later changes how mods behave. Async time gives each map and the planet its own time controls, so one player can pause their map while another plays on; most mods are fine with it, but anything that assumes one global clock is worth testing with it on. Multifaction lets players run separate colonies in the same game, and the team still describes it as work in progress - expect more mod rough edges there than in a single shared colony.

When it desyncs mid-run#

Desyncs in a long colony are rarely random. In rough order of likelihood:

1. Someone's mods updated. Compare the Files tab when they rejoin; resubscribe or roll back.
2. A setting changed. Make sure Sync configs is on and that nobody has a locally edited config.
3. A mod feature that was never tested. Note what the player was doing when it fired.
4. The host's machine fell behind. A host whose frame rate drops below the game's tick rate drags everyone out of step. This is not a mod problem, though a heavy mod list causes it; CPU vs RAM for game servers explains why one slow core matters more than total memory.
5. A bad connection. The team's FAQ names a poor link between host and player as the most common cause. Latency, jitter and packet loss covers how to tell which of the three you have.

Keep the autosave interval short and the slot count generous - the host's gameplay settings set both - and keep a copy of the save folder somewhere other than the host's PC. A desync is recovered by reloading the last good save, and a corrupted save with no copy is the end of the colony. Backups that actually restore is the longer version of that argument.

What a hosting plan can and cannot do here#

The Multiplayer mod runs inside each player's copy of the game, and the session lives on the host's PC. Recent releases have started work on a standalone server mode, but it is new and not how most groups play yet; check the project's release notes before planning around it. None of the compatibility work in this guide happens on a server - it happens on four desktops that have to agree.

If what your group really wants is a world that keeps going when the host is offline, that is RimWorld Together, which does have a proper server program. RE:NODE's RimWorld plans start at 1 GB of memory with one port allocation, which is all its server needs, with the mod list and configs edited in the browser file manager or over SFTP. The setup is in the RimWorld multiplayer server guide.

FAQ#

Are all RimWorld mods compatible with Multiplayer?

No, but more are than most people expect. XML-only mods always work. Mods with code work if they sync their actions, either natively or through the Multiplayer Compatibility mod. Check the score for each one in the Multiplayer compatibility window on the Mods screen.

Do I need the Multiplayer Compatibility mod?

If your list has any code mods, yes. It patches a long list of popular mods so their buttons and features sync, and it does nothing for mods it does not cover, so there is no cost to having it. Load it directly after Multiplayer.

Does everyone need the same DLCs?

Yes. Every player needs the same DLCs enabled as the host. If one player lacks a DLC, the group either plays without it or that player buys it.

Where does Multiplayer go in the load order?

Prepatcher at the very top, then Harmony, then Core and the DLCs, then Multiplayer directly beneath the last DLC, then Multiplayer Compatibility. Frameworks, content and patches follow.

Can players have different mod settings?

Not safely. Differing settings cause desyncs. Turn on Sync configs when hosting and joining players temporarily use the host's configs without anything on disk being overwritten.

Can we add mods to a colony that is already running?

XML content mods can usually be added with a save, reload and everyone resyncing their list. Removing mods, or adding code mods mid-run, risks broken saves as well as desyncs. Back up the save first and test the change on a copy.