Mod Load Order Diagnosis | Project Zomboid Guide

Quick Answer

Load-order problems are solved by bisecting, not reshuffling. The community method from the 42.21 failure threads: disable half your mod list, test, split the failing half again, repeat until one item fails alone. Before that: frameworks and explicit dependencies load first (Hug the Plushie loads after other affected mods; True Cargo is the rare 'order doesn't matter' item), save your last working list, and keep the exact error text with the failing Workshop IDs. On servers, compare WorkshopItems and Mods entries on both sides — one half-enabled field looks exactly like a load-order bug.

Table of Contents

Bisect workflow

Load-order problems are solved by returning to the last working set and adding small batches — not by reshuffling a big list on guesswork.

Stage	Do	Write down
Baseline	Reload the last working mod and map order	The exact list and its result
Frameworks	Fix missing frameworks and explicit dependencies first	Which item each framework belongs to
Batch	Add a small group, test once	The batch contents and pass or fail
Narrow	Split a failing batch until one item fails alone	The single failing Workshop ID
Restore	Return to the last working set after each failure	A known-good list kept on hand

The bisect, with the numbers attached

The method comes from the 42.21 failure threads: a user with 127 installed mods hit menu, inventory, and trap-state problems, and the suggested community method was disabling half the list at a time. Here is what that actually costs and yields.

Step	Do exactly this	Why it works / what it costs
0. Freeze the scene	Capture the exact symptom, the full error text, and the complete mod list with Workshop IDs before changing anything	Without the baseline, a 'fix' can't be told apart from luck — the 127-mod report has no verified root cause for exactly this reason
1. Halve the list	Disable half the mods (keep frameworks and their dependents together), restart, test once	One test eliminates half the search space; with ~127 mods that's 7 restarts to a single item instead of 127 one-at-a-time tests
2. Keep halves intact	Never split a framework from the items that require it — pz3d and ZombieBuddy, Belgian Malinois and Companion Dogs travel together	A framework disabled alone produces dependency errors that mask the real failure
3. Split the failing half	Halve again, test, repeat	Each cycle halves the remaining suspects; stop when one item fails alone
4. Confirm and record	Re-enable everything except the culprit, test, and write down the failing Workshop ID with the error text	The record is the payoff: next patch, you start from a known map of what broke and when

Order rules the authors actually wrote down

Load order is mostly documented per-item, by authors, in Workshop descriptions. The captured sample shows the three shapes it takes.

The explicit rule: Hug the Plushie's author says it should load after other affected mods — that's an ordering instruction attached to a dependency (item 3749026793), and it belongs in your notes at subscribe time. The implicit rule: frameworks before the items that require them (ZombieBuddy before pz3d, Companion Dogs before Belgian Malinois), which most load-order tools handle but a manual list doesn't unless you write it down.

The non-rule: True Cargo's author states outright that load order does not matter for their item. That's worth knowing too — a mod that genuinely doesn't care about order shouldn't be dragged into reordering sessions. The way to tell the shapes apart is the author's own description, captured at subscribe time, not community folklore.

And the server caveat: on a dedicated or hosted server, 'load order problems' are often field problems in disguise — WorkshopItems= and Mods= are separate configuration fields, and a mod enabled in one but not the other looks exactly like a load-order failure. Compare the server's two fields with one client's downloaded set before you start bisecting the list itself; it's the cheapest explanation and the most commonly missed.

Reference data

This page captures what you need to reproduce a load-order problem, instead of handing you a universal list order.

What to note	Capture	Why it matters
Framework	Workshop ID and required dependencies	A missing framework fails every dependent mod
Content batch	The small group added after the last working set	Makes the first failing change identifiable
Map batch	Cell conflicts, map order, and new-world requirement	World generation failures need a separate test
Server/client	Workshop IDs and Mods IDs on both sides	A downloaded item may still be missing from the active list

FAQ

How do I find which mod is breaking my game?

Bisect: disable half the list, test once, halve the failing half again. With a 127-mod list that's about seven restarts to a single item instead of 127 one-at-a-time tests. Keep frameworks with their dependents (ZombieBuddy with pz3d, Companion Dogs with Belgian Malinois), and capture the exact error text and Workshop IDs at every step — it's a community method from the 42.21 threads, not an official tool.

Does mod load order actually matter?

Per item, and the author tells you. Hug the Plushie says it must load after other affected mods; True Cargo says order doesn't matter for it; frameworks implicitly load before the items that require them. Capture the author's note at subscribe time instead of relying on community folklore.

My server looks like it has a load-order problem — is it?

Check the fields before the order. WorkshopItems= and Mods= are separate server settings, and a Steam Support response says server mods must be enabled in both — a mod half-enabled across the two fields produces symptoms identical to a load-order failure. Compare both server fields with one client's downloaded set before bisecting.

How many mods can I run before things break?

There's no recorded hard limit, but risk scales with count: a user with 127 mods reported menu, inventory, and trap-state problems after the 42.21 update with no single verified cause. The practical answer is bookkeeping — a written list with Workshop IDs, versions, and dependency notes makes any list size diagnosable; an unrecorded pile makes even twenty mods a mystery.