When a B42 server's mods half-work — Lua errors on boot, items without models, a mod present but inert — the config syntax is usually fine and the load order is wrong. B42 is stricter about it than B41 was. The rules are simple; applying them across a 60-mod list is what hurts, so this guide gives you the rules plus the tooling that automates them.
The three rules
- Libraries load first. Framework mods that other mods build on — tsarslib is the canonical example — must appear before every mod that depends on them, in both
WorkshopItemsandModsorder. - Dependencies before dependents, generally. A patch mod that fixes Mod A + Mod B compatibility loads after both. A mod's Workshop page "Required items" section is its dependency declaration — honor it.
- When two mods touch the same thing, the later one wins. Two rebalance mods editing the same item: whichever loads last takes effect. That makes load order a tuning tool, not just a correctness one.
The order that matters is the order in servertest.ini's lists — semicolon-separated, covered in the Workshop mods guide:
WorkshopItems=<lib-workshop-id>;<mod-a-id>;<mod-b-id>;<patch-id> Mods=tsarslib;ModA;ModB;AB_Patch
Don't hand-sort: use a mod manager
Hand-maintaining order across a real list stops being feasible around 20 mods. The community's answer is mod-manager mods — B42 versions exist of the established mod-manager/load-order tooling that reads declared dependencies and sorts the list for you, flagging circular or missing dependencies as it goes. Workflow most admins settle into:
- Assemble the list in the game client (which has the mod manager installed), let it auto-sort.
- Export/read the resulting order.
- Mirror that order into the server's
servertest.inilists. - Boot the server and read the console: a clean boot logs each mod initialising without Lua errors.
The console on boot is your truth. A red wall of attempted to index a nil value pointing into a mod's Lua right after a list change = the new mod loaded before its dependency.
Symptoms decoded
| Symptom | Usual load-order cause |
|---|---|
| Lua errors on server boot naming a mod | That mod loaded before its library/dependency |
| Items exist but appear as missing-texture/model | Content mod loaded before its framework |
| A mod is in both lists but does nothing | Overridden by a later mod touching the same content — or wrong Mod ID from a multi-mod Workshop item |
| Works in single-player, breaks on the server | Server list order differs from the client list the mod manager sorted |
| Broke after adding one mod | The new mod inserted in the wrong position — move it after its dependencies |
Server vs client: who needs what where
The server's list is authoritative: joining clients are told what to load, in the server's order. But clients still need compatible copies — a player subscribed to a mod's B41 edition, or holding a stale download, errors on join even though the server is correct. When one player breaks after a mod change and others don't: that player resubscribes the mod, verifies files, rejoins. More client-side failure modes in the Workshop mods guide.
Change discipline (learned the hard way)
- One change set at a time. Add five mods in one restart and a breakage bisect costs five times more.
- Back up before list surgery — save folder plus both config files. Mods write into the save; removing a heavily-integrated mod from a live world can strand its objects.
- Update on your schedule, not Steam's. A mod author shipping a broken update takes your server down on next boot. Watch the boot console after any restart that followed Workshop updates.
- Restarts to apply list changes are also just good B42 hygiene — see lag and desync fixes.
Worked example: growing a list from 3 to 30 without chaos
A pattern that scales, using layers instead of a flat list:
- Layer 0 — libraries. tsarslib and any framework your chosen mods declare. Boot, confirm clean. These never move again.
- Layer 1 — infrastructure mods the group agrees are permanent (QoL, UI, mechanics). Add, sort, boot, verify, tag this ini in a backup.
- Layer 2 — content (items, vehicles, maps). Added in small batches, each batch after its dependencies, each batch verified in-game before the next.
- Layer 3 — experiments. Always last in the order (safe: later wins conflicts predictably, and last-added is easiest to pull). Nothing graduates to layer 2 until it's survived two weeks.
The ini's list order literally mirrors the layers, so six months later the structure is still legible — the alternative is the 60-mod alphabetical-ish list nobody dares touch.
Frequently Asked Questions
Does load order really matter in Build 42?
Yes, more than B41. Libraries (tsarslib and friends) must precede dependents or you get boot-time Lua errors and half-loaded content. When two mods edit the same thing, the later one wins.
What is tsarslib and why does every guide mention it?
A widely-used library/framework mod that many content mods build on. It produces the classic load-order failure: put it first (both lists) and a whole class of Lua errors disappears.
Is there an auto-sorter for server mod lists?
Mod-manager mods with B42 support will sort a list by declared dependencies in the client; admins then mirror that order into servertest.ini. There's no server-side auto-sorter as of 42.20 — the ini order is what the server obeys.
Do WorkshopItems and Mods need to be in the same order?
Keep them consistent — Mods order is what actually governs load order, but maintaining both lists in the same sequence is how you stay able to read your own config six months later.
If you'd rather not be the person who mirrors sort orders into an ini at midnight, our managed Zomboid server hosting gives you full ini access with backups taken before you experiment.
