RimWorld Multiplayer: waiting for host to accept, and desyncs

If a friend is stuck on "Waiting for host to accept" in the RimWorld Multiplayer mod, the host has not clicked them in. Steam joins are not automatic: the host gets a pop-up with the friend's name and an Accept button, or a list under "Accept Steam players" in the chat window, and nothing happens until they press it. If no request ever appears, the host is not hosting with the Steam option ticked. Desyncs are a different problem with a different cure: almost all of them come from mods, mod settings or game files that differ between machines, from a mod the Multiplayer team has not patched, or from one machine falling too far behind. This guide walks through every stage of joining, the mismatch screen, the desync report the mod writes, and the habits that keep a long colony in sync.

Everything here is about the Multiplayer mod (originally Zetrith's, now maintained by the rwmt team): one shared colony, every machine running the same simulation in lockstep. For what the mod is, how it differs from RimWorld Together and which of the two can run on a server, see RimWorld multiplayer: mods, desyncs, hosting. This post picks up where that one stops - when it is installed and something has gone wrong.

What happens when you join#

Joining a Multiplayer game is not one step. The client walks through a sequence, and the label on the loading window tells you exactly which step it is stuck on. Knowing the order turns "it doesn't work" into a specific fault.

Direct and LAN connections skip the accept step entirely. They go straight from connecting to joining, and if they fail it is usually with "Connection failed" or "Connection timed out" rather than a wait.

"Waiting for host to accept"#

This message only appears on Steam connections, and it means the joining player has done everything right. Steam peer-to-peer networking needs the receiving side to accept a session from someone it has not spoken to before, and the Multiplayer mod hands that decision to the host rather than taking it silently.

In current versions the host sees a small window slide in from the right-hand edge with the player's Steam name and avatar, the line "wants to join your game", and two buttons: Accept and Reject. The same pending requests are listed in the chat window (top right of the screen while in the game) under the heading "Accept Steam players" - click a name there to let them in. Once accepted, the host gets a "Player has been accepted" message and the joining player moves on to the mod check.

The checklist when someone waits forever:

1. The host has to be looking at the game. The request pops up in the host's RimWorld window. If the host is alt-tabbed to Discord, the request is sitting there unanswered.
2. The host must be hosting with Steam enabled. The mod only queues Steam requests when the local server was started with the Steam option ticked in the host dialog. A game hosted on Direct or LAN only will ignore Steam requests completely, so the joining player waits with nothing ever appearing on the host's side. Close the server and host again with Steam ticked.
3. Both sides need Steam running and signed in. The Steam route works only on Steam copies of RimWorld. GOG and Epic copies have to use Direct or LAN.
4. Join through Steam, not by pasting an ID. Right-click the host in the Steam friends list and use Join Game, or use the Steam tab in the Multiplayer menu. A Steam invite cannot be accepted while you are inside a game - the mod tells you to quit to the menu first.
5. A rejected request is final for that attempt. If the host clicked Reject by mistake, or the join timed out with "Connection timed out", the joining player has to start a fresh connection from the menu.

If you host for a fixed group and are tired of clicking, the mod settings (Options, Mod Settings, Multiplayer) have Auto-accept Steam, off by default, which accepts any incoming Steam connection request automatically. Leave it off if your game is visible to people you do not know well - a game password, set in the host dialog, is the other half of keeping strangers out.

Stuck on Connecting, Downloading or Simulating#

Direct connections use UDP port 30502 by default. The host enters 0.0.0.0:30502 (or just leaves the default) in the Direct field so the game listens on every interface, forwards UDP 30502 on their router to their PC, and gives friends their public IP. A friend then types 203.0.113.10 or 203.0.113.10:30502 into the Direct tab. If it fails, the usual suspects are a forward set to TCP instead of UDP, a forward pointing at an old local IP, Windows Firewall blocking RimWorld, or an internet connection behind carrier-grade NAT, where no forward will ever work. NAT and CGNAT for game hosts explains how to tell, and port forwarding vs hosted servers covers what to do about it. A virtual LAN such as Hamachi or Radmin VPN, with both players using the LAN option, is the workaround the mod's own FAQ suggests.

Stuck on Downloading is, according to the mod's FAQ, nearly always a firewall. The quick test is to disable the firewall on both machines for one attempt; if the join completes, add RimWorld (and Steam, for Steam joins) as an allowed application and turn the firewall back on.

Stuck on Simulating means the save arrived and the joining machine is replaying ticks to reach the host. How long that takes depends on how old the join-point is. The host setting Auto join-points creates a join-point - a fresh snapshot newcomers start from - on join and on desync by default, and optionally on every autosave. The host can also type /joinpoint in chat to make one immediately, which is the fastest fix when a friend has been simulating for minutes.

Mod list and version mismatches#

When the client reaches the Joining stage, it compares itself with the host. If anything differs, a Data mismatch screen opens with tabs for General, Mod list, Files and Configs, showing "Server" against "Your client" side by side. Read it rather than closing it; it names the problem.

• RimWorld version or Multiplayer version differs. Both are shown. A different Multiplayer build can also surface as "Wrong protocol version" or the packet error "You are probably using a different Multiplayer version than the host!". Update the mod on both sides - on Steam, unsubscribe and resubscribe if it refuses to update - and make sure everyone runs the same RimWorld build. The mod tracks the current major version only (1.6 at the time of writing), and right after a RimWorld patch there may be a gap before a matching Multiplayer release.
• "Mod lists differ. The game needs to be restarted." Use Apply server's mod list, which overwrites your active list with the host's, then Restart; the game reconnects you once it has loaded. If mods are missing, Subscribe to missing subscribes to whatever is on the Workshop and downloads it in the background. Anything not on the Workshop has to be installed by hand.
• "Mods match but their order doesn't." Same fix: apply the server's mod list and restart. Load order is part of the simulation.
• Files shows mod files marked Missing, Added or Modified. These need fixing by hand, and they are usually leftovers from a mod update or two players on different versions of the same mod. Reinstall or resubscribe the offending mod. If it is Core or a DLC, delete that folder and verify the game files in Steam - your saves live elsewhere and are not touched. The difference can be on the host's side too.

Multiplayer itself has a required place in the list: Harmony and Prepatcher (a hard dependency) above it, then Core and the DLCs, then Multiplayer directly below them, with Multiplayer Compatibility immediately after it. Both Multiplayer and its compatibility mod declare that they load before HugsLib and Vanilla Expanded Framework, so if those sit above them, something is out of order.

HarmonyCoreRoyalty / Ideology / Biotech / Anomaly / Odyssey (the ones you own)PrepatcherMultiplayerMultiplayer CompatibilityHugsLibVanilla Expanded Framework and everything else

Every DLC that is enabled on the host must be enabled for every player. The mod's FAQ is explicit about that, and a player with an extra DLC active is a player with a different mod list.

Config sync and the Configs tab#

Mod settings are part of the simulation as much as the mods are. A mod that rolls for a raid with a 20% setting on one machine and 25% on another produces two different colonies within minutes.

The host dialog has Sync configs, on by default, which lets joining players download the host's mod configuration files. On the mismatch screen it appears as Apply server's configs, and it is temporary: the host's configs are used until you restart RimWorld, and none of your own files are overwritten. While running on someone else's configs, an Active configs button reminds you which game they came from. If the host has turned sync off, the Configs tab says "Config sync disabled by the host" and every player has to match settings by hand.

Leave it on unless you have a reason not to. The one real reason is in the mod's own tooltip: some config files contain sensitive data, such as API tokens used by streamer integration mods, and sync sends them to everyone who joins.

Why desyncs happen#

The Multiplayer mod does not send the game state across the network. It sends commands - draft this pawn, change that bill - stamped with the tick they apply on, and every machine runs the full simulation. A desync is the moment the mod notices that two machines no longer agree. It compares checksums of the game state at regular intervals, and when they differ the game stops and shows "The game state has desynced."

The divergence almost always started earlier than the moment it was detected. Combat, raids and mental breaks are where it tends to surface because they draw the most random numbers, not because they cause it. The causes, roughly in the order you will meet them:

1. Mismatched mods, files or configs. Covered above. If the join check passed, these are ruled out at join time, but a mod updated on one machine afterwards brings them back.
2. Mods the Multiplayer team has not patched. A mod that runs its own randomness, uses real time, or changes the game from its own UI without going through a synced command will desync even when everyone has the identical copy. The Multiplayer Compatibility mod carries patches for a long list of popular mods; the rest have a crowd-sourced rating from 0 to 4, shown in game (the Show crowd-sourced compat info setting) and on the community spreadsheet. Aim for 4; treat 3 as acceptable only when the notes say a patch exists.
3. A machine falling behind. The chat window shows each player's ping and how many ticks behind they are. A player whose PC cannot keep up sees "You are N ticks behind. Consider lowering the game speed." Running a large colony at superfast on a machine that cannot hold it is asking for trouble.
4. Dev mode used wrongly. Spawning items with the debug tools outside the mod's own Dev Mode setting desyncs the game. Use the host dialog's Dev Mode option (Host Only or Everyone) so debug actions go through the synced path. The mod's FAQ singles out editing the ideology in dev mode as a guaranteed desync.
5. Content that is only partly supported. Some DLC systems and multifaction play are still being worked on. The FAQ has listed Anomaly as partially working, and multifaction as a work in progress; check the current notes for your version.

Reading the desync report#

When the desync window opens it has five buttons: Try resync, Save, Chat, Open info folder and Quit. Try resync rejoins the game from the host's state, and when the cause was a one-off it gets everyone playing again quickly. Open info folder is greyed out with "Waiting for data from the host" for a few seconds while the report is written - give it a moment before you quit.

The report is a zip named Desync-01.zip, Desync-02.zip and so on, in a folder called MpDesyncs inside RimWorld's save data folder, next to Saves and Config. The mod keeps the ten most recent and deletes older ones, so copy a report somewhere safe if you want to keep it.

Inside the zip, in current builds:

desync_info                summary: tick data, versions, debug options, hardwarelocal_traces.txt           stack traces from your machine around the divergencehost_traces.txt            the same from the host, if it arrived in timelocal_jitted_methods.txt   methods compiled on your sidehost_jitted_methods.txt    the same from the hostlocal_logs.txt             your log, when availablelocal_metadata.txt         mod list and environmentreplay.rwmts               a replay, only when that setting is on

desync_info is the part a person can read. It records whether the arbiter was connected, the last tick on which everyone still agreed, the Multiplayer and RimWorld versions, whether dev mode or the debug build were on, the player count, whether async time and multifaction were active, and the CPU, GPU, memory and operating system. Before sending it to anyone, check the version lines and the debug options against the other players' reports - a mismatch there is the answer, and nobody needs to read a stack trace.

The trace files are the interesting part for whoever fixes the bug. They show which code was drawing random numbers on each side around the tick where the two machines diverged, so the first differing trace usually names the mod responsible. If you see a mod's namespace in the first lines that differ, search the Multiplayer Discord or that mod's page for a known issue before reporting. Traces are only recorded when the host has Desync traces enabled (on by default), and the mod notes that tracing does not work on 32-bit or ARM processors, which includes Apple Silicon Macs.

The arbiter, and how to make a useful report#

The Run Arbiter option in the host dialog starts a second, background instance of RimWorld on the host's machine that plays along as an extra, neutral client. When a desync happens it acts as a tie-breaker: with three machines instead of two, it becomes clear whose state went wrong. It costs the host real memory and CPU, because it is another copy of the game, so turn it on when you are chasing a recurring desync rather than for every session.

A report the maintainers can act on has four things: the zips from both sides (host and the player who desynced), the mod list, what was happening in the game at the time, and whether it reproduces. The mod's Workshop discussion asks people to test with and without the arbiter before reporting, to rule out a broken save. If the desync happens at the same moment every time you load a particular save, say so - that is the most valuable thing a bug report can contain.

Sync habits that keep a colony playable#

Most groups that play long Multiplayer campaigns arrive at the same rules:

1. Freeze the mod list before the colony starts. Agree on it, publish a Steam collection, and have everyone subscribe to exactly that. Adding a mod mid-campaign is possible; removing one usually breaks the save.
2. Stop Workshop updates surprising you. A mod that updates for one player overnight is a mismatch the next evening. Have the host check for updates before a session and everyone restart Steam so they match. What to do when a mod update breaks covers rolling back.
3. Check compatibility before adding anything. Look up the mod's rating first. A rating of 1 or 2 means it will desync; no amount of matching files will fix that.
4. Size the game to the slowest machine. Use the Lowest wins time control so the slowest player sets the pace, or keep the speed down in big fights.
5. Pause on join and on desync. Both are on by default. Leave them on, so a desync does not run on for several in-game hours before anyone notices.
6. Keep autosaves close together. The host's autosave interval can be set in in-game days or real minutes; every 10-15 real minutes means a desync that corrupts the state costs you very little. The Autosave slots setting (5 by default) controls how many are kept.
7. Use the chat commands. The host has /joinpoint, /kick <username> and /stop. Kicking a player whose game keeps falling behind, and letting them rejoin from a fresh join-point, is often quicker than a full resync.

Is there a dedicated server?#

For most of its life the answer was a flat no: the host's copy of RimWorld was the server, and the colony stopped when the host quit. That is changing. Release 0.11.5 added standalone server bootstrap work, and the project's development ("continuous") builds now ship a Server-beta.zip with Windows and Linux builds. It listens on Direct only - Steam networking and the arbiter are not supported - reads a settings.toml and a save.zip from its own folder, and if they are missing waits for the first player to connect and set the game up from inside RimWorld. The release notes describe it as being for testing, so treat it as experimental and expect it to change.

If you want to try it, it needs a machine that stays on with UDP 30502 open to your players. A VDS is the obvious home - choosing between a VDS and a game panel explains the trade-off - and game server ports explained covers getting the port reachable. Every player still needs the identical mod list; a server does not change that requirement in any way.

If what your group actually wants is a world that keeps going while people come and go, that is the problem RimWorld Together solves, and it is what game hosts sell as RimWorld hosting. RE:NODE's RimWorld line runs that kind of persistent server, with mods uploaded through the file manager or SFTP and backup slots stored off the machine; it does not host the Multiplayer mod.

FAQ#

Why does my friend see "Waiting for host to accept" but I never get a request?

You are not hosting with Steam enabled. The mod only listens for Steam join requests when the Steam option was ticked in the host dialog. Close the server, host again with Steam on, and the Accept pop-up will appear.

Can I turn off the accept step?

Yes. In the Multiplayer mod settings, turn on Auto-accept Steam. Any Steam connection request is then accepted without a click, so set a game password if your game is visible to people outside your group.

Does Try resync lose progress?

It reloads you from the host's current state, so anything that only happened on your diverged copy is gone, but the shared colony is not rolled back. If resync keeps failing, the host should save, everyone should quit, and the session should be rehosted from that save.

We all have the same mods and still desync. Why?

Matching files only rules out one cause. Check every mod's compatibility rating, check that mod settings were synced and nobody changed one mid-session, and look at the ticks-behind numbers in chat during the next fight. The first differing trace in the desync report usually names the mod.

Can GOG or Epic players join a Steam host?

Not through Steam. They have to connect by Direct (UDP 30502 reachable on the host) or LAN, including over a virtual LAN such as Radmin VPN or Hamachi. Everyone still needs the same RimWorld build and mods.

Where are desync reports saved?

In the MpDesyncs folder inside RimWorld's save data folder, as Desync-NN.zip files. The Open info folder button in the desync window opens it directly.