Project Zomboid Build 42.21 multiplayer mod-stack readiness scorecard

Turn a proposed private-server mod collection into a small, documented stack that must pass multiplayer-specific test gates before it reaches a valued world.

Set the multiplayer target before choosing mods

Define what the server should change so popularity does not replace a testable requirement.

• Describe the intended private-server experience and the activities every participant expects to repeat.
• Separate required changes from optional variety and set a complexity limit for the first stack.
• Write acceptance conditions for joining, performing the intended activity, restarting the server, and re-entering the world.
• Keep candidates that do not serve the stated target out of the initial test.

Capture the Build 42.21 test boundary

Tie every result to a reproducible game and server context.

• Record the branch and exact build shown by the server and every participating installation.
• Record the complete enabled-mod order, server configuration, candidate versions, and test date.
• At capture time, official sources identified Build 42.21 as both the Stable and Unstable build.
• Treat every result as specific to the recorded setup and reset its status after a relevant game or mod update.

Create one evidence card per candidate

Expose missing information before combining mods.

• Record each candidate’s stated purpose and whether its documentation addresses the installed build.
• List all stated dependencies, conflicts, load-order instructions, and configuration requirements.
• Mark absent, outdated, or contradictory information as unresolved instead of filling the gap by assumption.
• Treat a candidate and its required dependencies as one testable group.

Compare overlapping NPC options

Choose between alternatives without endorsing an unsupported universal winner.

• Describe the server role each NPC candidate is meant to fill using only its available documentation.
• Compare both candidates against the same desired activities, dependencies, configuration burden, conflicts, and unresolved questions.
• Test alternatives separately when they appear to change the same part of the experience.
• Select a provisional candidate only when its documented fit and controlled results better match the stated server goal.

Build the smallest interpretable stack

Reduce combination uncertainty before multiplayer testing begins.

• Remove candidates that duplicate an already-covered server goal.
• Place groups with unresolved dependencies or material instructions on hold.
• Document why every remaining group belongs in the stack.
• Keep the unmodded baseline and each accepted stage available for comparison.

Run multiplayer combination gates

Verify the recorded stack through repeatable server checks rather than a single successful launch.

• Confirm that the disposable unmodded server and world open and accept the intended participants.
• Add one dependency-complete group while keeping the build, configuration, and existing load order fixed.
• Repeat joining, the intended activity, server restart, and re-entry checks at every stage.
• Record observed behavior, participant reports, logs, and the exact stage at which an inconsistency first appears.
• Classify each stage as acceptable, inconsistent, unsuitable, or unresolved.

Decision checklist

• Write down the private server experience the stack must support.
• Record the branch and exact build used by the server and every participant.
• Create a documentation card for every candidate and required dependency.
• Compare overlapping NPC candidates against the same server requirements.
• Remove duplicate candidates and place unresolved groups on hold.
• Confirm a disposable unmodded multiplayer baseline before adding mods.
• Add one dependency-complete group per controlled test stage.
• Repeat join, activity, restart, and re-entry checks before accepting a stage.

Worked example

A private group wants one NPC-focused addition plus a separate quality-of-life candidate. Label the alternatives NPC A and NPC B rather than assuming either is preferable. The group records Build 42.21, the server configuration, each participant’s build, both candidates’ stated support, dependencies, conflicts, load-order instructions, and configuration needs. NPC A has a complete documentation card, while NPC B has an unresolved configuration requirement, so NPC B remains on hold. The group first confirms a disposable unmodded multiplayer baseline, then tests NPC A with its dependency-complete group. Everyone joins, performs the agreed NPC-focused activity, leaves, returns after a server restart, and records observations and logs. The quality-of-life group is added only after the NPC stage remains acceptable under the same checks. The conclusion applies only to that recorded setup; a relevant update returns the stack to unverified status.

Common mistakes

• Treating stated Build 42 support as proof that the complete stack works together.
• Testing two overlapping NPC candidates in the same first-stage stack.
• Changing the build, load order, configuration, and candidate set in one comparison.
• Using a valued world as the initial multiplayer test environment.
• Accepting one successful connection without repeating restart and re-entry checks.

Related guides