Quick Answer
Compatibility is a dated record, not a yes/no. The 42.21 rollout proved it: a game using the PZ Optimisation mod failed to launch after updating from 42.20, and a 127-mod setup hit menu, inventory, and trap-state problems with no verified cause. Check six things per item: exact patch, Workshop ID, dependencies, author notes, recent reports, and a clean-save runtime test. On servers add a seventh: WorkshopItems and Mods are separate fields — both must be enabled. Author wording matters: 'tested on 42.21' (Over the Shoulder) outranks 'designed for MP, untested on servers' (True Cargo).
Table of Contents
Compatibility record
A compatibility entry is a dated record, not a permanent yes or no. Separate the Workshop identity, the server fields, dependencies, and the clean-save runtime result before you recommend anything.
| Record | Capture | Passes when |
|---|---|---|
| Patch | Exact branch and patch | The item is judged on the same branch you play |
| Workshop identity | Item ID, update date, author note, tags | The item can be reopened and rechecked |
| Server fields | WorkshopItems, Mods, and Map entries | Each field recorded separately |
| Dependencies | Every required item and framework | The smallest complete chain is installed |
| Runtime | Clean-save runtime result | Launch and failure output recorded separately |
What the 42.21 rollout actually broke
Four captured user reports from the 42.21 transition, each a documented symptom — none with an officially verified root cause. They map the failure surface of a patch day.
| The report | The symptom | What it teaches |
|---|---|---|
| PZ Optimisation mod after 42.20 to 42.21 | Game failed to launch after the update; the thread proposed downloading and running an install.ps1 from GitHub via PowerShell | A patch can break a launch entirely — and the suggested community fix (run a remote script) is a security decision, not a troubleshooting step. Verify any script before running it |
| 127 installed mods after 42.21 | Menu, inventory, and trap-state problems; user asked how to identify incompatible subscribed mods | Scale turns a patch into a haystack — the bisect method (disable half, test, halve again) exists for exactly this, and the thread excerpt establishes no verified root cause |
| Checksum verification blocking vanilla 42.21 clients | Clients blocked from joining a server; the proposal was manually creating three local files from server files | Not an official fix or an independently reproduced result — record it as a symptom-led workaround, clearly labeled |
| One subscribed mod visible, another missing | A mod appears in the list while another subscription doesn't | List visibility is not activation — a classic subscribe/enable/field confusion, cheap to check before any deep diagnosis |
Reference data
PZFans separates the three server-side mod fields before compatibility is judged. Compatibility is a record with a patch boundary, not a permanent yes or no.
| Field | What to capture | What it's for |
|---|---|---|
| WorkshopItems | Numeric Steam Workshop item IDs | Server-side downloads |
| Mods | Internal mod IDs used by the active mod list | Activation after download |
| Map | Map folder IDs, separate from ordinary Mods entries | Map-world loading |
| Patch | Exact game branch and patch | Required on every listing |
| Workshop | Item ID, last update, author notes, and tags | Required before ranking anything |
| Dependencies | The complete Workshop dependency chain | Required before enabling |
| Runtime | Clean-save or small-batch result | Separate from author compatibility claims |
FAQ
Why did my mods break after the 42.21 update?
Patch-day breakage is documented: a user's game with the PZ Optimisation mod failed to launch after updating from 42.20 to 42.21, and a 127-mod setup hit menu, inventory, and trap-state problems. Compatibility claims are dated snapshots — an author's 'works on 42.20' doesn't travel with the update. Recheck the live Workshop page, then bisect your list (disable half, test, halve again).
Is 'compatible with Build 42' enough to trust a mod?
No — read the exact wording. 'Tested on 42.21' (Over the Shoulder) is the strongest claim in the captured sample; 'built for 42.20+' (Heart Health Meter) is a range that implies but doesn't re-test; 'requires 42.15+' (True Cargo) is a floor claim, and its multiplayer mode is called ready while explicitly untested on a server. Judge the wording, then run your own clean-save test.
Someone posted a script to fix my broken install — should I run it?
Verify it first, line by line. The captured 42.21 launch-failure thread proposed a PowerShell command that downloads and executes an install.ps1 from GitHub — running remote scripts on the machine that holds your saves and Steam account is a security decision, not a troubleshooting step. A symptom report with a script attached is not an official fix or an independently reproduced result.
The server says a mod is installed but clients don't have it — why?
WorkshopItems= and Mods= are separate server fields, and a Steam Support response says server mods must be enabled in both. 'The server has the mod' is two checks, not one — compare both fields against one affected client's downloaded set before touching anything else.