Project Zomboid zombie population reset: a copied-save test plan

A settings change and a population reset are different test goals. Protect the valued world, define the expected result, and accept only what you can reproduce on a copy.

Define what “reset” must accomplish

Separate the requested result from a general change to future zombie behavior.

• Write an observable success condition without assuming how the game implements it.
• Distinguish the current population from behavior observed after the change.
• List any world data or established progress that must remain intact.
• Mark population mechanics not established by the supplied official evidence as unresolved.

Capture the branch, build, and world boundary

Make every result specific to the tested installation and save.

• Record the branch and exact build displayed by the installation.
• Record the active sandbox values, enabled mods, and mod order.
• Note that the captured official evidence places Build 42.21 on Stable and Build 42.22 in the publisher’s Pre-Release testing flow.
• Do not move an unbacked long-term single-player save to Pre-Release.

Protect the valued world

Create a recoverable test boundary before attempting any change.

• Leave the original world untouched during the experiment.
• Make a complete, separately labeled copy and confirm that it opens before editing anything.
• Keep the original branch and configuration available as the rollback reference.
• Stop if expected characters, locations, settings, or other world data are missing from the copy.

Build a one-change observation matrix

Test a proposed method without confusing unrelated variables with the result.

• Select recorded locations that were previously visited and locations not yet visited.
• Capture the population observations needed for the written success condition before changing the copy.
• Apply only one settings or mod change for the current comparison.
• Revisit the recorded locations, restart the copied world, and repeat the observations.

Handle mod claims separately

Avoid treating an unverified mod description as evidence of compatibility or save safety.

• Check whether the mod documentation explicitly addresses the installed branch and build.
• Record dependencies, conflicts, configuration steps, and removal guidance.
• Test the mod outside the original world and keep other variables fixed.
• Classify compatibility only for the exact recorded setup.

Choose keep, revise, or rollback

Turn observations into a bounded decision without overstating what the test proves.

• Keep the copied result only when the defined condition repeats and expected world data remains present.
• Revise the test when the result is ambiguous or more than one variable changed.
• Roll back when the copy loses data, produces inconsistent observations, or affects unrelated behavior.
• Start a fresh world only when preserving the current world is less important than obtaining a clean configuration boundary.

Decision checklist

• Write an observable definition of the intended population reset.
• Record the displayed branch, build, sandbox values, mods, and mod order.
• Preserve the original world and create a separately labeled complete copy.
• Confirm that the copy opens with expected world data before making changes.
• Choose previously visited and not-yet-visited locations for comparison.
• Apply one proposed settings or mod change to the copy.
• Restart and repeat the same observations before classifying the result.
• Roll back if data is missing, unrelated behavior changes, or results remain inconsistent.

Worked example

A player wants fewer lingering zombies in an established world but does not know whether a settings edit would change the current population. They record the displayed branch and build, relevant sandbox values, enabled mods, and several observation locations. After preserving the original, they open a complete copy and confirm that expected world data is present. They write a success condition based on repeatable observations rather than an assumed internal mechanic, apply one proposed change, revisit the recorded locations, inspect locations not previously visited, restart, and repeat. If observations differ between runs or unrelated world data changes, they classify the method as unresolved or unsafe for that setup and return to the untouched original.

Common mistakes

• Treating a change to future population behavior as proof that the current population was reset.
• Testing on the only copy of a valued world.
• Changing several sandbox or mod variables in one comparison.
• Assuming a mod supports the installed build without documentation and controlled testing.
• Promoting a copied-world result after one observation without a restart and repeat test.

Related guides