RE:NODE

Valheim mod version mismatch: why you get kicked on join

By RE:NODE Team
10 min read


When a modded Valheim server kicks you straight after connecting, it is almost always because your mods and the server's do not agree - a mod missing on one side, or the same mod at a different version. The message on the disconnect screen usually names the mod. Read it, make your set identical to the server's, and you are in. The time-consuming cases are the ones where the message is vague, comes from the game rather than a mod, or where two people swear they have "the same mods" and do not. This post walks through what each kind of message means, which system produced it, how to compare the two sets exactly, and how to stop it happening every time somebody updates.

If you are not running any mods and still get "Incompatible version", that is the game version, not mods - see updating the server and version mismatch.

Three checks, three different messages#

A modded Valheim connection passes through up to three independent version checks. Knowing which one stopped you tells you where to look.

CheckWho runs itWhat it comparesWhat you see
VanillaThe gameGame and network version"Incompatible version"
JotunnJotunn on both sidesMods that declare a compatibility levelA window listing mods and versions
ServerSyncEach mod that bundles itThat mod's version and its required minimumExtra lines naming the mod

They run at different points. The vanilla check happens first, during the handshake: if the game versions differ, nothing else is compared. The Jotunn and ServerSync checks happen once the connection is accepted and the mods exchange their information, which is why a mod mismatch can look like a connection that succeeded for a second and then dropped.

Reading the message#

"Incompatible version" with no mod names

The game version differs. Either the client updated and the server did not, or the reverse. On a modded server the usual cause is a player whose Steam client updated Valheim overnight while the server is deliberately held back until the mods catch up. The fix is on the timing side, not the mod side. Some ServerSync versions add their mod lines underneath this same message, so if there is more text below it, read that first.

A Jotunn window listing mods

Jotunn produces a separate window after the disconnect, listing each mod that failed its check and why: missing on your side, missing on the server's side, or present on both at versions that are too far apart, with both versions shown. The strictness - whether 1.4.2 against 1.4.3 is a problem - is declared by each mod. Jotunn explained has the full table of levels.

This is the easy case. Every line tells you what to install, remove or change to which version.

ServerSync lines naming a mod

ServerSync is a library many popular mods (a large share of the Smoothbrain, Azumatt and blaxxun families, among others) compile directly into their own .dll, so it is usually not installed separately and does not appear as its own entry in a mod list. It lets a mod declare its current version and a minimum version it will accept from the other side, and whether the other side is required to have the mod at all. When a check fails, it adds lines to the disconnect message saying which mod failed and with which versions.

Because each mod carries its own copy, ServerSync checks fail one mod at a time. You fix one, reconnect, and may be told about the next. Fix them all at once by comparing the full lists as described below rather than playing whack-a-mole.

Kicked with no useful message at all

Look at the logs. The player's side writes BepInEx output to BepInEx/LogOutput.log inside their mod profile folder, and Unity's own log to:

code
%USERPROFILE%\AppData\LocalLow\IronGate\Valheim\Player.log

The server's side writes BepInEx/LogOutput.log in the server root, and the console shows the same output live. Search both for the moment of the connection and for the words version, incompatible or the player's name. Logs worth keeping makes the case for downloading the server log before a restart overwrites it.

Comparing the two sets exactly#

"We have the same mods" is a statement nobody can verify by looking at a mod manager screen. Compare the actual loaded versions instead. BepInEx prints one line per plugin at start-up, with the version it actually loaded:

bash
# On the server, from the server root$ grep -o 'Loading \[[^]]*\]' BepInEx/LogOutput.log | sort > server-mods.txt

On a Windows client, after one modded start, run the same thing in PowerShell from the profile folder:

code
PS> Select-String -Path BepInEx\LogOutput.log -Pattern 'Loading \[[^\]]*\]' |      ForEach-Object { $_.Matches.Value } | Sort-Object > client-mods.txt

Put the two files side by side, or diff them:

bash
$ diff server-mods.txt client-mods.txt< Loading [EpicLoot 0.x.y]> Loading [EpicLoot 0.x.z]

Every line in the diff is a problem, though not every problem kicks. Client-only mods will show up on the client side and are fine. Server-only mods will show up on the server side and are fine. Everything else should be identical.

The log tells you what loaded, which is what matters; a mod sitting in plugins that failed to load does not appear. If you want what is installed rather than what loaded, mods installed through a mod manager have a manifest.json in their folder with a version_number field:

bash
$ grep -H '"version_number"' BepInEx/plugins/*/manifest.json

Note that the plugin version a mod reports at load and its Thunderstore package version are usually the same, but not always. When they disagree, the load line is what the version checks see.

Common causes, in the order they happen#

Most kicks have one of a handful of causes:

  1. Someone pressed "Update all". Their mod manager updated every mod to the latest release. Now they are ahead of the server. This is the most common cause by a distance, and the reason group profiles should be pinned - r2modman for Valheim groups shows how.
  2. The server was updated and the group profile was not. The admin updated mods on the server and forgot to share a new profile, so everyone is now behind.
  3. A dependency drifted. The content mods match but Jotunn, or a library one mod depends on, does not. Dependencies are part of the list.
  4. Wrong profile. The player has two profiles and launched the old one, or clicked Play in Steam and started vanilla. Vanilla against a server that requires mods gets the Jotunn window with every mod listed as missing.
  5. A duplicate mod. Two copies of the same plugin in plugins, often an old loose .dll and a newer one in its own folder. BepInEx loads one and skips the other, not necessarily the one you expected.
  6. A config-only difference. Rare, but some mods include a config value in their sync check. Copying the server's BepInEx/config files for that mod resolves it.

Matching client and server sets#

Pick the server as the reference. The server is what everyone connects to, it changes least often, and its set is the one already tested against the world.

  1. Get the list from the server. Use the log extract above, and write it down somewhere the group can read.
  2. Make one profile that matches it. One person builds or updates a mod manager profile to exactly those versions, including Jotunn, HookGenPatcher and BepInExPack Valheim. In r2modman the download dialog on a mod lets you choose an older version.
  3. Export the profile as a file and share it. Everybody imports it as a new profile rather than repairing their old one.
  4. Copy the server's configs into the profile for synced mods if any mod includes config in its check, or skip that step if none do.
  5. Test with one player before announcing. If they connect cleanly, the profile is right.

If the server is the one that is wrong - for example, it is running an older mod version with a known bug and you want everybody on the newer one - update the server first, confirm it starts cleanly with the world, then follow the same steps with the new list. Never update the clients first and the server second; for the hours in between, nobody can play.

Back upworld + BepInExUpdate servermods, then gameTest joinone playerExport profilenew file nameGroup importsas a new profile
Update order that avoids a day of kicks

A worked example#

A group of six runs a server with twelve mods. On Tuesday evening two players can join and four are kicked on connect. Here is how that resolves in about ten minutes rather than an evening.

The first kicked player sends a screenshot. It shows the vanilla "Incompatible version" message with nothing beneath it. That points at the game, not the mods: their Steam client updated Valheim that afternoon. The two players who can still join have not restarted Steam since. The server is deliberately held on the previous patch because three of the mods have not been updated yet.

The admin has two choices. Either wait for the mods and update everything together, or let the kicked players roll their own game back. Steam does not offer a simple rollback for most players, so waiting is the realistic option. The admin posts in the group chat that the server stays on the old patch until the mods are ready, and that the two players still connected should not restart Steam tonight.

On Thursday the mods are updated. The admin backs up the world and BepInEx, updates the server's game and mods, starts it, checks the log for exceptions and for every Loading [...] line, and joins once to check a chest of modded items is still intact. Then they export a new profile file with a new name and post it. The fourth player still gets kicked: the Jotunn window shows one mod at an older version. They imported the new profile but launched the old one. Switching profiles fixes it.

Nothing in that sequence needed anyone to guess. Each step read a message or a log line and acted on it.

Stopping it happening again#

The kicks come back every time the mod list moves unless the group has a habit around updates. What works:

  • One owner for the mod list. One person decides what is installed and at what version. Everybody else imports.
  • No in-place updates on clients. The rule is "import the new profile", never "update your mods".
  • Pin the server's game version until mods are ready. A Valheim patch breaks most BepInEx mods, and the first kick of patch day is the client's game version being newer than the server's. Game server version pinning and rollbacks covers holding a server back deliberately.
  • Keep the last working set. Back up BepInEx before every change. On RE:NODE backup slots come with every Valheim plan and a backup can be locked against rotation, so the last known-good mod set is not pushed out by nightly backups while you are fixing the new one.
  • Write the versions down. A pinned message with the profile file, the date and the Jotunn version saves the next person a diff.

The general habits for a modded group server are in running a modded server for friends.

FAQ#

Why am I kicked when I have exactly the same mods as my friend?

Because "the same mods" usually means the same names, not the same versions or dependencies. Compare the Loading [...] lines from both logs. One different Jotunn or library version is enough.

Can I join a modded server with fewer mods than the server?

Only if the missing mods are server-only or do not enforce a check. Any mod that declares that everyone must have it will refuse you, and a content mod you lack will at best leave you unable to see things other players can.

Can I disable the version check on the server?

There is no general switch, and you should not look for one. Each mod declares its own check because a mismatched version breaks items, recipes or world objects in ways that can damage the world. Match the versions instead.

The message says Incompatible version but we all updated. What now?

Check whether the server updated too. If it did, check whether the text below the message names a mod - ServerSync adds its lines there. If nothing is named, compare game versions on the main menu of each client against the version in the server's startup log.

Do config files need to match as well?

Usually not for the check itself. Mods that sync their config send the server's values on connect, so clients' own files do not matter. A few mods include config in what they compare, and copying the server's file for that mod resolves it.