Project Zomboid mid-save sandbox mod troubleshooting checklist

If a sandbox-settings mod produces unexpected results, preserve the valued world and identify the failing layer before trying another edit.

Define the exact failure before changing anything

Turn an unclear configuration complaint into a reproducible test without assuming a cause.

• Record the installed branch and build shown by the current installation.
• Capture the enabled-mod list and its exact load order.
• Write down the displayed sandbox values before the attempted change.
• Describe one expected result and one observed result in plain language.
• Save relevant screenshots, logs, and the time of each test.

Protect the original world

Create a reversible boundary before testing settings or mod combinations.

• Leave the original world untouched while investigating.
• Make a complete copy and label it with the build, mod set, and test date.
• Confirm that the copy opens before attempting the configuration change.
• Stop using that copy if expected world data is missing or altered.

Reproduce the symptom on a controlled copy

Determine whether the reported behavior is repeatable under a recorded setup.

• Repeat only the sandbox-setting action associated with the symptom.
• Keep the build, mod list, load order, and test location fixed.
• Restart and repeat the same observation before calling the result consistent.
• Classify the outcome as reproduced, absent, intermittent, or unsafe to continue.

Compare against a clean disposable baseline

Separate a mod-dependent symptom from behavior that also appears without the suspect setup.

• Create a disposable comparison environment on the same build.
• Keep the test goal and observed setting category consistent.
• Do not use the valued world as the clean comparison.
• If the behavior also appears clean, investigate the baseline before blaming the mod.
• If it appears only with the modded setup, continue isolating configuration and interactions.

Change one factor per test

Identify the smallest condition associated with the failure.

• Hold the build constant while testing mod state or load order.
• Hold the mod set constant while testing one load-order change.
• Re-enter only the setting needed for the current comparison.
• Preserve logs and result labels for every test.
• Revert to the last recorded setup before starting another comparison.

Apply the Build 42.21 evidence boundary

Use the official patch context without turning correlation into a diagnosis.

• The captured official sources identify Build 42.21 as the Stable and Unstable release context.
• The Build 42.21 release says loadstring and loadstream were re-enabled after being disabled in 42.20.4.
• Treat that Lua-method history as a reason to recheck relevant mod behavior, not proof of causation.
• Do not infer compatibility for an individual mod from the release information.

Decision checklist

• Record the installed branch and build.
• Copy the complete valued world before testing.
• Capture the enabled-mod list and exact load order.
• Write down the current values, intended change, and observed result.
• Reproduce the symptom on the copied world.
• Run the same focused comparison in a disposable clean environment.
• Change only one build, mod, load-order, or configuration factor per comparison.
• Keep logs, screenshots, and a result label for every test.

Worked example

Suppose a copied world shows a sandbox value different from the value entered through a mod. The player records the build, mod set, load order, starting value, intended value, and observed value. They repeat the same action on the copy and label the first result intermittent because a restart produces a different observation. They then use a disposable environment on the same build to test the same setting category without the suspect setup. If the clean comparison does not show the symptom but the fixed modded setup reproduces it repeatedly, the evidence points toward the modded configuration path without identifying a specific defect. The player keeps the original world untouched, retains the logs, and either restores the last known setup or tests a maintained alternative in another disposable environment.

Common mistakes

• Testing configuration changes on the only copy of a valued world.
• Changing the build, mod set, load order, and sandbox values in the same comparison.
• Treating one successful load as evidence that the configuration is stable.
• Assuming Build 42.21 caused the problem because it changed Lua-method availability.
• Installing an unverified replacement directly into the valued world.
• Discarding logs or screenshots before the symptom has been reproduced consistently.

Related guides