Quick Answer
Diagnose in order of cheapness, not drama: exact error text first, then branch and build on both sides, then the network path, then the mod fields. The captured 42.21 cases: a launch failure traced to the PZ Optimisation mod, a 127-mod list with menu/inventory/trap symptoms, checksum blocks on vanilla clients (a community workaround, NOT an official fix), and a subscribed mod invisible in the list. On modded sessions, WorkshopItems, Mods IDs, Map entries, and dependencies are four separate comparisons. Server stuck initializing? Console output and first error, before touching the save.
Table of Contents
Diagnosis order
Move from the cheapest explanation to the most expensive one. Keep the exact error and last working state at every step.
| Order | Check | Don't touch yet |
|---|---|---|
| 1 | Client and server branch and build | Mods |
| 2 | Server availability, host method, network path | The save |
| 3 | Workshop items, Mods IDs, dependencies, downloads | The whole profile |
| 4 | Clean profile or default session | The live save |
| 5 | Logs and the smallest failing mod batch | More variables |
The 42.21 case files
Four captured reports from the 42.21 transition. Each is a documented symptom with its community response — none carries an officially verified root cause, and one of the proposed 'fixes' is a security decision in disguise.
| Case | The symptom | The recorded response — and its status |
|---|---|---|
| Launch failure post-update | Game with the PZ Optimisation mod failed to launch after 42.20 to 42.21 | The thread proposed a PowerShell command downloading and executing an install.ps1 from GitHub. Treat as a symptom report with an unverified fix — never run remote scripts without reading them |
| The 127-mod aftermath | Menu, inventory, and trap-state problems after updating; no single cause identified | Thread replies suggested the bisect method: disable half the list, test, halve again. A community method, not an official tool — but the right shape for the problem |
| Checksum verification block | Vanilla 42.21 clients blocked from joining a server | The proposal was manually creating three local files based on server files. Explicitly NOT an official fix or independently reproduced result — label it as such in your notes |
| Invisible subscription | One subscribed mod appears in the list, another doesn't | An opening-post symptom without a verified resolution. Check activation context (save selection, server fields) before assuming corruption |
The field-by-field mod comparison, done properly
Step three of the diagnosis order is where most multiplayer mod errors live — and it fails when done as a vibe check instead of a comparison.
The comparison has four rows, and each is a separate check: WorkshopItems (the numeric Workshop IDs the server downloads), Mods (the internal identifiers the game loads), Map (the map-folder identifiers for map mods), and dependencies (the items your items require). A Steam Support response adds the field rule: server mods must be enabled in BOTH the Workshop and Mods sections — so a mod can pass three of four rows and still be the cause. Write the server's four rows next to one affected client's four rows; the mismatch is usually visible in one glance once it's on paper.
The clean-profile test brackets the comparison. Before declaring the save damaged or the mods broken, launch a default profile with zero mods and join it: if the clean join works, the failure is in your configuration delta, which the field comparison then localizes; if it doesn't, you've saved yourself a mod hunt — the problem is branch, network, or the server itself. That's the cheapest experiment in the whole sequence and it's step four for a reason: it interprets step three's results.
And the logging discipline that closes every one of these cases: the exact error text, timestamp, server build, client build, who's affected, and the last known working state — captured before the first change, not reconstructed after the fifth. The initializing-server variant of the same discipline: read the console output and the first error before changing the save or settings. The captured worldgen 'biomes' report shows why — a specific Lua index on a specific file is a diagnosis; 'it doesn't work' is a mood.
Reference data
These incident records are symptoms collected from official, Steam, and PZFans troubleshooting references — not universal causes. Start with logs and a backup before changing several things at once.
| Symptom | What was reported | Don't jump to |
|---|---|---|
| Stuck initializing | Start with the server console and the first error before changing settings | Deleting the live save |
| Missing mods | Compare WorkshopItems and Mods separately | Assuming a subscription alone activates a mod |
| Map failure | Check Map entries and whether the world was created for the map set | A universal load-order fix |
| WorldGenOverride | A Linux dedicated server report named a biomes null error with multiple mods | A confirmed universal fix |
| 42.20 to 42.21 launch | A user linked launch failure to an optimization mod after updating | "every mod is incompatible" |
| Checksum | A user reported vanilla clients blocked from joining | An official repair procedure |
| Workshop visibility | A user saw one subscribed mod but not another in the mod list | A verified activation diagnosis |
| Large mod list | Community replies suggested disabling half the list and narrowing the failing batch | An official fix or permanent compatibility result |
| User-posted script | A reported PowerShell repair command is not an official solution | Permission to run unverified code |
FAQ
My game won't launch after updating to 42.21 — is it the update?
Maybe, but a mod is the documented suspect: a captured report shows a game using the PZ Optimisation mod failing to launch right after the 42.20 to 42.21 update. Test a clean launch (mods disabled) before blaming the patch — and be wary of the community-proposed fix in that thread, a PowerShell command that downloads and runs a script from GitHub. Read any script before running it.
How do I find the mod breaking my multiplayer server?
The bisect method from the 42.21 threads: disable half the mod list, test, halve the failing half again — roughly seven restarts for a 127-mod list. First compare the four fields (WorkshopItems, Mods, Map, dependencies) between server and one client on paper; the mismatch is often visible without bisecting at all.
Clients get a checksum error on my vanilla 42.21 server — what do I do?
A captured report describes checksum verification blocking vanilla clients, with a community proposal to manually create three local files from server files. That is not an official fix or an independently reproduced result — record it as a symptom, verify branch and build on both sides first (the cheapest explanation), and treat the manual-file workaround as a last resort you test on one client, not all of them.
Server stuck on initializing — is my save corrupted?
Don't touch the save yet. The troubleshooting reference starts this diagnosis with the console output and the first error — a specific line like the captured 'biomes' index error in WorldGenOverride.lua tells you it's world generation (map mods, overrides), not the save. Reproduce, read the first fatal line, bisect the mods; the save is the last thing you change, after a backup exists.
One player can't join but everyone else can — why?
It's client-side by definition. Compare that client's branch and build against the server first, then their downloaded mod set against the server's four fields (WorkshopItems, Mods, Map, dependencies), then their activation context — including the restart-after-enabling clauses some mods carry. One affected client is a comparison problem; a whole server is a server problem.