Project Zomboid Multiplayer Desync: Build a Useful Report

If two Project Zomboid players report different positions or world actions, you have a possible synchronization issue, not yet a diagnosis. First record the same event from both clients, note the exact game build and session setup, and preserve the relevant logs; this guide helps you prepare evidence without guessing at a fix.

The distinction matters because rubber-banding, slow rendering, delayed responses, missing map chunks, and audio that travels too far can feel related while describing different symptoms. The Indie Stone’s Stable 42.21 notes list specific multiplayer fixes and say some zombie duplication or disappearance cases remain under investigation. Those release notes do not establish a general remedy for every player-reported desync. Read the official 42.21 release notes and keep your report tied to what your group observed.

Desync, lag, or a different symptom?#

Start by describing what the players disagree about. A candidate shared-state divergence is when two players compare the same event and report incompatible gameplay state, such as one player seeing a character in a different place after the same action. A delayed response or local stutter may look alarming, but it does not by itself show that the server and clients stored different state.

Write down the visible symptom before labeling it. Note whether a character moved, an action completed, an item changed, a zombie appeared, or only the screen or sound differed. If the main problem is a long wait, hitching, or a server that struggles to keep up, treat it as a performance observation. If terrain is missing or a cell stops loading, describe that separately as a map-transfer symptom. If only sound seems to travel unusually far, report the audio behavior rather than calling it proof of a world-state mismatch.

Official 42.21 notes name fixes for particular multiplayer cases, including zombie duplication and disappearance after chunk re-entry, and acknowledge that some cases remain. They also list changes related to driving around map loading and player-coordinate synchronization on different Z levels. These are version-specific notes, not a checklist that can identify the cause of a new incident. Capture your own case before applying a category or remedy.

Record one event from both players#

Choose a short event that both players can describe, then compare notes while it is still fresh. Use the same clock reference if possible and record the time zone. Do not ask one player to reconstruct the other player’s view from memory.

Keep the first comparison simple: one action, two perspectives, and the state immediately afterward. Mark anything uncertain as “not observed.” If players did not watch the same event or cannot agree on the sequence, say that in the notes rather than filling gaps with a theory.

Do not treat a rejoin as a universal fix or a test that proves data is safe. If you choose to observe what happens after a reconnect, record it as another event and note whether both players returned to the same world state. Never reset, overwrite, or move a live save just to make a symptom easier to reproduce.

Write down the exact build and session#

Record the version and branch shown by each client and the server, including any build identifier the game displays. Stable and Unstable can change on different schedules, and a historical forum report may describe behavior from a build that is no longer current. The official Stable 42.21 release was published September 28, 2026; record your own current values instead of assuming every group is on that build.

Also note how the session is hosted: an in-game Host session or a dedicated server, and whether the world is new or already in use. Write down the player platforms and storefronts as reported by the participants. This guide does not certify cross-store, cross-platform, or branch compatibility; it records the details needed to investigate the particular session.

When the server and clients show different versions, stop treating the incident as a clean comparison. Capture the mismatch and resolve the supported version pairing using current official instructions before testing a different theory. Do not switch branches or attempt to convert a save based on an old report; back up important world data before any version change and check the current game guidance first.

Capture the setup without changing it#

Record the session as it was when the event happened. For a modded world, include each mod’s identifier, the installed revision or version when available, and the load order shown by the game or server configuration. Note relevant settings and whether all participants had the expected setup. A mod list is context for a report, not evidence that a mod caused the symptom.

Capture connection details at the time of the event if they are already available: which player hosted, whether the server was dedicated, the approximate time of any disconnect, and any network or resource reading the host can provide. Label these as observations. A high ping reading, busy CPU, or memory figure may be worth including, but a single reading does not establish a cause or prove that upgrading hardware will solve the issue.

Keep the production setup unchanged while collecting the initial report. Avoid changing several settings, removing a mod, or restarting immediately if doing so would erase useful context. If an administrator needs to collect server logs or settings, ask them to preserve the relevant time window and avoid sharing credentials, public IPs, account names, or unrelated player data.

Use a safe, controlled comparison#

If the group wants to investigate a hypothesis, do it on a separate test copy or disposable world with permission from the world owner. Back up the production save first, keep client and server builds matched, and record the test setup. A comparison is only useful when you change one factor at a time and note what stayed the same.

For example, if a mod is suspected, compare the current setup with a reduced or clean setup only on that isolated test world. If the symptom does not recur, record that result as “not reproduced in this test,” not proof that the mod was the cause or that the production issue is fixed. If the same event happens again, capture the new observations and logs. A controlled test can narrow a question; it does not automatically explain every incident.

Do not use a live world as the control, delete save files, reset player data, or make a broad “optimization” change as a generic fix. If you cannot create a safe copy or do not know how your host backs up and restores the world, stop before experimenting and ask the world owner or administrator how to protect it.

Prepare a privacy-safe bug report#

The Indie Stone’s 42.21 announcement points players to its bug-report guidance and Bug Report forums. Follow the current instructions there and submit a concise reproduction rather than a list of untested causes. The team’s reporting route can change, so check the official guidance linked from the 42.21 announcement before posting.

Use a structure like this:

Build and branch (each client and server):
Session type (Host or dedicated):
World type (new or existing):
Platforms/storefronts as observed:
Mods and revisions (or none):
Time and time zone:
Location and short reproduction steps:
Player A: expected state / actual observation:
Player B: expected state / actual observation:
What happened next:
Relevant client/server log excerpts:
What is uncertain or was not observed:

Before sharing logs, remove passwords, tokens, account names, public addresses, and unrelated personal information. Keep enough surrounding lines to explain the event and preserve timestamps and error text. If you are unsure whether a detail is sensitive, ask the server owner before posting it publicly. Use this Project Zomboid server log privacy checklist to review the copied excerpt before sending it.

Separate what you saw from what you suspect. “Both clients showed different positions after the same action at 21:14 UTC” is a useful observation if it is accurate; “low RAM caused desync” is a conclusion that needs evidence. A report with exact versions, one repeatable sequence, two perspectives, and relevant redacted logs gives other players or developers something concrete to evaluate.

When to investigate another issue#

If the report is mainly about slow startup, persistent stuttering, or general server performance, keep it with those observations rather than calling it a proven synchronization defect. If the question is specifically how to measure connection latency, use a latency test designed for the players’ locations. If terrain or a map cell fails to load, document that as a map-transfer issue. These symptoms can happen around the same time as a disagreement, but one does not prove the other caused it.

The next useful action is to compare the event notes and decide whether they support a repeatable shared-state discrepancy. If they do, submit the report with the exact setup and privacy-safe evidence. If they do not, preserve the uncertainty and collect a clearer event. Changing hosts, increasing RAM, removing every mod, or switching game branches is not a substitute for that evidence.