fix: leave world settings alone on a wipe, and snapshot them first

Reverts the restore-from-template behaviour. A wipe now resets the world and the
player database only; Server/<name>_{SandboxVars,spawnregions,spawnpoints}.lua
carry over untouched, so hand tuning survives it. Verified by checksum: all three
files byte-identical either side of a wipe.

That gives up the guarantee the restore bought. PZ writes the running world's
settings back over those files, so if a world is ever created with defaults the
file inherits them and later wipes regenerate from them -- which is how a Sophie
world became an Apocalypse one. Nothing corrects that automatically now, so the
wipe takes a snapshot of the settings before it starts, keeping the last ten
under config-backup/. Greg's edits were lost once because the only record of them
was a file the server had since overwritten; that is the hole this fills.
config-template/ still holds the pristine Sophie preset to copy back from.

The snapshot is best-effort throughout. The first version of it created the
directory with plain mkdir, the parent belongs to the container's subuid rather
than the podman user, and set -e turned that into a failed wipe -- the same shape
as the tee that broke this script before. Ansible owns the directory now and
every step of the snapshot tolerates failure, because a backup that cannot be
written is not a reason to refuse to wipe.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Bastian de Byl
2026-08-26 23:10:37 -04:00
co-authored by Claude Opus 5
parent 1c467b1a76
commit 60d5ec4ae3
2 changed files with 45 additions and 28 deletions
@@ -23,14 +23,17 @@
# than the container's subuid. Getting this wrong silently broke world resets: # than the container's subuid. Getting this wrong silently broke world resets:
# the script's first log line failed with EACCES and set -e killed it before it # the script's first log line failed with EACCES and set -e killed it before it
# stopped the server, so `@bot` resets did nothing at all. # stopped the server, so `@bot` resets did nothing at all.
- name: create zomboid canonical config directory - name: create zomboid host-side config directories
become: true become: true
ansible.builtin.file: ansible.builtin.file:
path: "{{ zomboid_path }}/config-template" path: "{{ zomboid_path }}/{{ item }}"
state: directory state: directory
owner: "{{ podman_user }}" owner: "{{ podman_user }}"
group: "{{ podman_user }}" group: "{{ podman_user }}"
mode: 0755 mode: 0755
loop:
- config-template
- config-backup
- name: create zomboid host-side log directory - name: create zomboid host-side log directory
become: true become: true
@@ -228,18 +231,17 @@
state: started state: started
daemon_reload: true daemon_reload: true
# The intended world settings, kept somewhere the server cannot reach. # A pristine copy of the Sophie preset, kept where the server cannot overwrite it.
# #
# PZ reads Server/<name>_SandboxVars.lua only when it creates a world, and then # Reference only -- nothing applies this automatically. A wipe deliberately leaves
# writes the *running world's* settings back over that same file. So the file in # the live settings alone so hand tuning survives it.
# Server/ is an output, not an input: once any world is created with defaults,
# the server stamps those defaults into it and every later wipe regenerates from
# them. That is how a Sophie world quietly became an Apocalypse one -- 139 values
# reverted, loot rates from 0.35 back to 0.9, CharacterFreePoints from 0 to 60.
# #
# This copy is what a wipe restores from, so settings survive it. Seeded once and # It exists because the live files cannot be trusted as a record of intent: PZ
# then left alone, so it is the file to hand-edit when changing the world: # reads Server/<name>_SandboxVars.lua only when it creates a world, then writes
# edit here, then wipe, and the new world comes up with the edits. # the running world's settings back over it. The file in Server/ is an output as
# much as an input, and that is how a Sophie world quietly became an Apocalypse
# one -- 139 values reverted, loot from 0.35 back to 0.9, CharacterFreePoints
# from 0 to 60. When that happens again, this is what to copy back from.
- name: seed canonical zomboid world settings - name: seed canonical zomboid world settings
become: true become: true
ansible.builtin.copy: ansible.builtin.copy:
@@ -32,6 +32,28 @@ if podman unshare test -f "$TRIGGER_FILE"; then
podman unshare rm -f "$TRIGGER_FILE" podman unshare rm -f "$TRIGGER_FILE"
fi fi
# Snapshot the current settings before touching anything. They are not modified
# by the wipe, but they are the one thing here with no other copy: Greg's edits
# were lost once already because the only record of them was a file the server
# had since overwritten.
# Every step here is best-effort: a wipe must never fail because a backup could
# not be written. An unwritable log aborted this whole script once already.
SNAP_DIR="{{ podman_home }}/.local/share/volumes/zomboid/config-backup/$(date '+%Y-%m-%d_%H-%M-%S')"
if ! mkdir -p "$SNAP_DIR" 2>/dev/null; then
log "WARNING: could not create $SNAP_DIR; skipping settings snapshot"
SNAP_DIR=""
fi
if [[ -n "$SNAP_DIR" ]]; then
for f in SandboxVars spawnregions spawnpoints; do
src="{{ podman_home }}/.local/share/volumes/zomboid/data/Server/${SERVER_NAME}_${f}.lua"
podman unshare cp "$src" "$SNAP_DIR/${f}.lua" 2>/dev/null || true
done
log "Settings snapshotted to ${SNAP_DIR##*/}"
# Keep the last 10 snapshots.
ls -1dt "{{ podman_home }}/.local/share/volumes/zomboid/config-backup"/*/ 2>/dev/null \
| tail -n +11 | xargs -r rm -rf || true
fi
# Stop server # Stop server
log "Stopping zomboid service..." log "Stopping zomboid service..."
systemctl --user stop zomboid.service || true systemctl --user stop zomboid.service || true
@@ -55,23 +77,16 @@ else
log "No database found at $DB_PATH" log "No database found at $DB_PATH"
fi fi
# Restore the intended world settings before the server regenerates. # Settings are deliberately NOT touched here. A wipe resets the world and the
# players; Server/<name>_{SandboxVars,spawnregions,spawnpoints}.lua carry over
# as-is, so hand-tuned settings survive it.
# #
# Without this the wipe silently changes the game. PZ writes the running world's # The risk that buys: PZ writes the running world's settings back over those
# settings back over Server/<name>_SandboxVars.lua, so by the time we delete the # files, so if a world is ever created with defaults the file inherits them and
# save that file already describes the world we are throwing away -- and if that # every later wipe regenerates from them -- which is how a Sophie world became an
# world had defaults, the replacement inherits them. Restoring from the canonical # Apocalypse one. Nothing here corrects that automatically any more, so the
# copy is what makes a wipe reset the world and keep the settings. # snapshot above is the way back: config-backup/ holds the settings as they were
CONFIG_TEMPLATE="{{ podman_home }}/.local/share/volumes/zomboid/config-template" # before each wipe, and config-template/ holds the pristine Sophie preset.
SERVER_DIR="{{ podman_home }}/.local/share/volumes/zomboid/data/Server"
for f in SandboxVars spawnregions spawnpoints; do
if [[ -f "${CONFIG_TEMPLATE}/${f}.lua" ]]; then
podman unshare cp "${CONFIG_TEMPLATE}/${f}.lua" "${SERVER_DIR}/${SERVER_NAME}_${f}.lua"
log "Restored ${SERVER_NAME}_${f}.lua from canonical config"
else
log "WARNING: no canonical ${f}.lua; the new world will inherit whatever the server last wrote"
fi
done
# Start server # Start server
log "Starting zomboid service..." log "Starting zomboid service..."