Project Zomboid Build 42 mods

Build 42 changed how Project Zomboid loads Workshop content. A dedicated server can download every item you asked for, finish startup without a loud error, and still reject the first player who tries to join. That gap between "fetched" and "actually loaded" is the core hosting problem after the Build 42 stable cutover.

This article summarizes what moved from Build 41 to Build 42, how the two server config lists work, and what that means when you run the title on CFTools Architect.

Clean boot, broken joins

SteamCMD and the dedicated process treat Workshop IDs as download targets only. They do not verify that a package contains Build 42 code. So a Build 41 era list can update cleanly, look healthy in Manager, and still leave clients unable to stay connected.

When DoLuaChecksum is enabled (common on dedicated configs), the server compares loaded Lua on the host against what the joining client has. A mismatch drops the player at join time, not during Workshop update and not as a clear boot failure. From the operator side it can look like clients are broken. Often the stack or the branch alignment is wrong instead.

Build 41 versus Build 42

Load list format

Build 41 Mods= entries were bare internal IDs. Build 42 expects each load ID prefixed with a backslash, for example \LGExtendedPlumbing. Paste an old list without those prefixes onto a Build 42 dedicated and the game typically loads nothing from that line. It fails quietly.

Package layout on disk

Build 42 aware mods often ship shared assets under common/ and build-specific code under folders such as 42/ or 42.15/. Older packages may only contain a Build 41 style media/ tree. Those still download. They still appear as installed content. Build 42 may still have nothing usable to run from them.

Authors sometimes set versionMin in mod.info. Presence of that field is a useful signal, not a guarantee. Absence is not automatic proof of incompatibility either. Check for Build 42 folders and test in a small batch.

Saves and branches

Build 41 worlds do not load on Build 42. Groups that want to finish an old save stay on the legacy41 Steam branch for both dedicated and every client. One player left on the wrong branch fails checksum and cannot join.

If you move to Build 42, plan a fresh world and a rebuilt mod list. Do not expect an in-place repair of a long Build 41 stack to be reliable.

Two lists in servertest.ini

Project Zomboid splits Workshop handling across two settings. Mixing them up is the usual cause of "installed but nothing happens."

WorkshopItems= (download)

Semicolon-separated Steam Workshop IDs. This tells the dedicated which items to fetch before it finishes bringing the world up. Example:

WorkshopItems=3779561845

Mods= (load order)

Semicolon-separated internal mod IDs from each package's mod.info id= field, each with a leading backslash. Order is load order. Libraries and frameworks belong before mods that depend on them.

Mods=\LGExtendedPlumbing

Workshop page titles are display names. They are almost never the load ID. Folder names under the Workshop content tree are also not a safe substitute. Open mod.info and use id=.

One Workshop item can contain several mod folders. You still list that Workshop ID once under WorkshopItems=, and you list every internal id= under Mods=.

Downloaded Workshop content for Project Zomboid (Steam app 108600) typically lands under paths like:

steamapps/workshop/content/108600/<workshopId>/mods/

Each folder there is a separate mod with its own mod.info.

Ways the lists go wrong

• Workshop ID present, load ID missing: content sits on disk and never activates.
• Load ID present, Workshop ID missing: nothing downloads, so the load entry is skipped.
• Load entry uses a Workshop title, or loses its backslash: Build 42 loads nothing for that entry.
• Dependents listed before their libraries: load order breaks behavior even when both IDs exist.

Keep the two lists intentional and in a known order. When one Workshop package expands into multiple load IDs, lengths will differ. That is expected. Manage that stack carefully so you do not drop entries while editing.

Hosting on Architect

Prefer Manager for Workshop attach

When the title supports it, attach Workshop mods through Architect mod management on the deployment. That keeps install, cache, and ordering closer to how Architect expects the stack to be maintained.

After the dedicated has run long enough to fetch new Workshop items, verify the load IDs yourself. Confirm each mod.info id= matches what the server will put in Mods=, including the Build 42 backslash prefix. Do not trust Workshop titles copied into the load list.

Edit config safely

If you hand-edit servertest.ini on the deployment:

1. Stop the server process in Manager first. A running dedicated can rewrite the file and discard your changes.
2. Align WorkshopItems= and Mods= as described above.
3. Start again and allow time for large Workshop fetches on the first boot after a list change.
4. Have one staff account join before you open the world to the group.

Rebuild for Build 42 instead of porting blindly

Take an Architect backup before large mod or branch changes. Removing mods that placed objects or buildings can leave gaps in a save that re-adding the mod does not fully heal.

Prefer a clean Build 42 list:

1. Empty both lists (or start a fresh deployment for testing).
2. Add libraries and frameworks only. Boot and join.
3. Add a few content mods at a time. Restart and join after each batch.
4. Drop packages that never gained Build 42 folders or that fail staff joins in isolation.

A long Build 41 collection that "downloaded fine" is not evidence it will run on Build 42.

Updates, restarts, and branch alignment

Project Zomboid checks Workshop updates when the dedicated starts. A scheduled restart can pull author changes without a separate install step. If a previously stable world fails after a restart you did not intend as a mod night, treat a Workshop update as the first suspect and inspect startup logs for the mod IDs you care about.

Operational sequence that keeps groups out of checksum hell:

1. Update the dedicated build in Manager.
2. Confirm branch alignment (Build 42 everywhere, or legacy41 everywhere).
3. Restart clients so Steam Workshop subscriptions refresh.
4. Staff smoke-test one join.
5. Then invite players.

Clients mid-session often still hold an older Workshop snapshot. That alone can produce the same join kick as a broken server list.

Failure checklist

Work through these when players bounce despite a healthy looking process:

1. Dedicated and all clients on the same branch (Build 42 or all on legacy41).
2. Every intended Workshop ID in WorkshopItems=.
3. Every intended internal id= in Mods= with a leading backslash.
4. No Workshop titles used as load IDs.
5. Libraries before dependents.
6. On-disk packages include Build 42 capable folders where required.
7. Staff client fully restarted after Workshop or title updates.
8. Recent backup available before you chase fixes by deleting save data by hand.

Related Architect help

• Modding support
• Backup
• Getting started

If the stack still fails after a rebuilt list and a clean staff join test, open a support request with the current Workshop and load lists plus the relevant startup log section from the deployment.