Project Zomboid Build 42.21 post-update verification checklist

Build 42.21 addresses several disruptive problems, but its release notes also describe some work as incomplete. Verify the behaviors that matter to your world before treating the update as settled.

What Build 42.21 changes—and what it does not settle

Establish the official patch boundary before presenting the verification workflow.

• The official news listing identifies Build 42.21 as both the Stable and Unstable build at capture time.
• The release addresses prominent zombie duplication in multiplayer and zombie disappearance after leaving and re-entering an area in single-player and multiplayer.
• The publisher says some zombie-related cases remain on its radar, so local verification is still warranted.
• XXL tree cutaway and transparency behavior changed to improve visibility, especially while driving, but the publisher describes that work as ongoing.
• The Lua methods loadstring and loadstream were re-enabled in 42.21 after being disabled in 42.20.4; the evidence does not establish compatibility for any individual mod or server.

Preserve a useful comparison baseline

Make the test reversible and ensure that observed differences can be tied to a recorded setup.

• Keep the previously working environment available and test only with a copied world.
• Record the branch, exact build, single-player or multiplayer mode, population setup, mod list, load order, and relevant server configuration.
• Avoid changing unrelated settings during the patch check.
• Define the behaviors that would make the updated environment acceptable before beginning.

Test zombie persistence after area re-entry

Check the specific persistence symptoms discussed in the official release without claiming universal resolution.

• Choose a repeatable area in the copied world and record the initial observed state.
• Leave the area and return using the same procedure on more than one pass.
• Watch for duplication or disappearance rather than treating unrelated population differences as the same symptom.
• For multiplayer, record which players left or re-entered and when the symptom appeared.
• Preserve logs and reproduction notes if the result is inconsistent.

Check driving visibility around XXL trees

Evaluate whether the changed cutaway and transparency behavior is acceptable for the player's routes and display setup.

• Select a repeatable driving route where large trees overlap the view of roads, houses, or nearby objects.
• Drive the route under comparable conditions and note where visibility becomes difficult.
• Check whether tree cutaway, transparency, and visibility of overhung structures are acceptable in the current setup.
• Treat the result as a local usability test because the publisher says further work is planned.

Revalidate relevant mod and server behavior

Separate the documented Lua-method reversal from unsupported assumptions about individual compatibility.

• Identify whether any relevant component is known by its maintainer or configuration to depend on loadstring or loadstream.
• Keep the build, mod list, load order, and server configuration fixed during each comparison.
• Test the dependent function directly in a disposable environment and retain available logs.
• If dependence is unknown, report the symptom and configuration without assigning the cause to the Lua change.
• Do not infer broad compatibility from a successful launch alone.

Decide whether to continue, investigate, or roll back

Turn test observations into a bounded decision without promising a universal outcome.

• Continue with the copied environment only when the tested behaviors meet the acceptance conditions defined at the start.
• Investigate when a symptom is reproducible but its cause remains unclear.
• Return to the preserved environment when the copied world produces unacceptable behavior or loses expected data.
• Retain the test notes because later updates may require the same comparisons.

Decision checklist

• Confirm that the selected branch reports Build 42.21 before testing.
• Preserve the previously working environment and duplicate the world.
• Record the game mode, population setup, mods, load order, and relevant server configuration.
• Repeat an area-exit and re-entry test while checking for zombie duplication or disappearance.
• Drive a repeatable route near XXL trees and record visibility problems.
• Test relevant Lua-dependent mod or server functions separately when dependence is established.
• Save logs and exact reproduction steps for inconsistent behavior.
• Use the updated environment only if the copied-world results meet the predefined acceptance conditions.

Worked example

A multiplayer administrator preserves the prior environment, copies the world, and records Build 42.21, the population setup, enabled mods, load order, and server configuration. The group observes a chosen area, leaves it, and returns several times while recording any zombie duplication or disappearance. One player then drives the same tree-lined route and notes where trees obstruct roads or buildings. Because one server component is documented by its maintainer as depending on a re-enabled Lua method, the administrator tests that function separately and retains its logs. The copied environment is accepted only if these bounded checks meet the group's stated tolerance; otherwise, the prior environment and evidence remain available for investigation.

Common mistakes

• Opening the only valuable world before preserving the prior environment.
• Changing the patch, mods, load order, and settings in the same comparison.
• Treating one clean area re-entry as proof that no zombie persistence cases remain.
• Assuming the XXL tree changes make every driving route equally visible.
• Attributing a mod or server symptom to the Lua-method change without establishing dependence.
• Treating a successful launch as evidence that all relevant functions work.

Related guides