Project Zomboid Build 42 mod shortlist comparison worksheet

Turn a crowded list of Build 42 mod suggestions into a small, documented shortlist you can test without treating popularity as proof of compatibility.

Define the job before comparing mods

Turn a broad request for recommendations into a bounded playstyle goal.

• Describe the specific experience or problem the stack should change.
• Separate required changes from optional variety.
• Set a complexity limit for the first test stack.
• Exclude candidates that do not serve the stated goal.

Create one evidence card per candidate

Expose missing compatibility information without filling gaps by assumption.

• Record the installed branch and exact build shown by the game.
• Write down each candidate's stated purpose and build support.
• List every stated dependency, conflict, load-order instruction, and configuration requirement.
• Mark absent, outdated, or contradictory information as unresolved.

Map dependencies and remove overlap

Produce a smaller shortlist whose test results can be interpreted.

• Treat a candidate and its required dependencies as one testable group.
• Compare candidates that appear to change the same part of the experience.
• Keep only the candidate that more directly matches the stated goal when two entries duplicate a job.
• Place any group with an unresolved dependency or instruction on hold.

Assign a test-readiness status

Separate promising candidates from those that are not ready for a valued world.

• Use ready only when the purpose, stated support, dependencies, and instructions are documented.
• Use hold when a material question remains unanswered.
• Use remove when the candidate duplicates another choice or conflicts with the intended experience.
• Reset the status to unverified after a relevant game or mod update.

Run a staged verification

Test the shortlist while preserving a reproducible baseline.

• Confirm that a disposable unmodded profile opens on the recorded build.
• Add one dependency-complete group while keeping other variables fixed.
• Repeat the intended activity after a restart and record the observed result.
• Try an acceptable stack only on a copy of a valued save.
• Stop if expected data is missing, the result is inconsistent, or the cause cannot be isolated.

Interpret the Build 42.21 patch boundary

Use the supplied official evidence without turning a platform change into a compatibility claim.

• Record that Build 42.21 was the captured Stable and Unstable context.
• Note that loadstring and loadstream were re-enabled in 42.21 after being disabled in 42.20.4.
• Treat the Lua-method change as a reason to recheck relevant setups.
• Do not infer compatibility for an individual mod, dependency, server, or stack from that change.

Decision checklist

• State one playstyle change the mod stack should deliver.
• Record the installed branch and exact build.
• Create a comparison card for every candidate.
• List each candidate's stated dependencies and instructions.
• Remove candidates that duplicate the same job.
• Put candidates with unresolved support information on hold.
• Test one dependency-complete group in a disposable profile.
• Use only a copied valued save for the next test stage.

Worked example

Suppose the goal is better item organization and two unnamed candidates appear to address it. Candidate A has current stated support and requires Dependency D; Candidate B has unclear build information. Mark B as hold instead of guessing. Treat D plus A as one dependency-complete group, establish a disposable baseline, add D and A, restart, and repeat the same organization task. Record the build, load order, expected result, observed result, and any errors. If the result is acceptable, repeat the test on a copy of the valued save. If the build or mod set changes, return the group to unverified status.

Common mistakes

• Choosing candidates because they are popular without defining the desired change.
• Treating a missing compatibility statement as confirmation.
• Testing a mod without all of its stated dependencies.
• Changing the build, load order, and candidate set in the same comparison.
• Using the only copy of a valued save as the first test environment.
• Assuming the Build 42.21 Lua-method change verifies a particular mod.

Related guides