Files
deploy_home/ansible/roles/podman/templates/zomboid/world-reset.sh.j2
T
Bastian de BylandClaude Opus 5 ba9c4f2bfe fix(zomboid): re-sync the world settings from the live server
The vendored Sophie preset and the running debbzoid world had drifted, and the
repo only held the preset. That is not a restore point: force-pushing it would
have reverted the admins' in-game tuning rather than recovering it, which is
exactly how a Sophie world quietly became an Apocalypse one once already -- 139
values reverted, loot from 0.35 back to 0.9, CharacterFreePoints 0 to 60.

files/zomboid/sophie/SandboxVars.lua is now a snapshot of the live world taken
2026-08-31, not the preset as shipped. The modlist is untouched and still
upstream, which is why zomboid_preset_version now names the two halves and their
separate dates. server.ini.j2 carries the eight keys that had drifted:

  PlayerSafehouse              false -> true
  SafehouseAllowNonResidential false -> true   (the diner/gas-station case)
  SafehouseAllowRespawn        false -> true
  SafehouseAllowLoot           true  -> false
  SafehouseAllowFire           true  -> false
  TrashDeleteAll               false -> true
  MapRemotePlayerVisibility    1     -> 4
  ResetID                      6953472 -> 826046

ResetID is in that list on purpose, and matters most. It is the world's
soft-reset token: a file value that differs from the one the live world was
created with tells every connected client to roll a new character. Carrying the
live value makes a deliberate force-push a no-op instead of a server-wide wipe
prompt.

Spawn config gets its own switch, zomboid_spawn_force. spawnregions.lua and
spawnpoints.lua are the only config a running world re-reads -- at every server
start, where SandboxVars is read once, when the world is created -- so a spawn
edit is deployable on the live world without a wipe. Sharing zomboid_config_force
between them would have meant force-pushing the whole preset to land a one-line
spawn edit, rewriting the INI (hence the ResetID hazard above) and the world's
SandboxVars along with it.

config-template/ now tracks the repo unconditionally. Nothing on the host writes
that directory and the server cannot see it, so it has no hand edits to protect;
if it does not track the repo it is not a restore point, just an older world's
settings.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016QdWYhwUtwM2NQGukiRh12
2026-09-05 09:11:31 -04:00

97 lines
3.8 KiB
Django/Jinja

#!/bin/bash
# Zomboid World Reset Script
# Triggered by systemd path unit when discord bot requests reset
set -e
LOGFILE="{{ podman_home }}/.local/share/volumes/zomboid/logs/world-reset.log"
TRIGGER_FILE="{{ podman_home }}/.local/share/volumes/gregtime/data/zomboid-reset.trigger"
SERVER_NAME="{{ zomboid_server_name }}"
SAVES_PATH="{{ podman_home }}/.local/share/volumes/zomboid/data/Saves/Multiplayer/${SERVER_NAME}"
DB_PATH="{{ podman_home }}/.local/share/volumes/zomboid/data/db/${SERVER_NAME}.db"
log() {
local msg="[$(date '+%Y-%m-%d %H:%M:%S')] $1"
echo "$msg"
# stdout is already captured by the journal; the file is a convenience.
# Never let it be fatal -- an unwritable log used to abort the whole wipe
# on the very first line, under set -e.
echo "$msg" >> "$LOGFILE" 2>/dev/null || true
}
# Ensure XDG_RUNTIME_DIR is set for systemctl --user
export XDG_RUNTIME_DIR="/run/user/$(id -u)"
log "World reset triggered"
# Read requester info from trigger file if available
# Note: Must use podman unshare because file is owned by container's UID (232071)
if podman unshare test -f "$TRIGGER_FILE"; then
REQUESTER=$(podman unshare cat "$TRIGGER_FILE")
log "Requested by: $REQUESTER"
podman unshare rm -f "$TRIGGER_FILE"
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
log "Stopping zomboid service..."
systemctl --user stop zomboid.service || true
sleep 5
# Delete world (using podman unshare to work within user namespace)
log "Deleting world saves at: $SAVES_PATH"
if [[ -d "$SAVES_PATH" ]]; then
podman unshare rm -rf "$SAVES_PATH"
log "World saves deleted"
else
log "No world saves found at $SAVES_PATH"
fi
# Delete player database
log "Deleting player database at: $DB_PATH"
if [[ -f "$DB_PATH" ]]; then
podman unshare rm -f "$DB_PATH"
log "Player database deleted"
else
log "No database found at $DB_PATH"
fi
# 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.
#
# The risk that buys: 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
# every later wipe regenerates from them -- which is how a Sophie world became an
# Apocalypse one. Nothing here corrects that automatically any more, so the
# snapshot above is the way back: config-backup/ holds the settings as they were
# before each wipe, and config-template/ holds what this repo deploys -- since
# 2026-08-31 a snapshot of Greg's live tuning, not the pristine Sophie preset.
# Start server
log "Starting zomboid service..."
systemctl --user start zomboid.service
log "World reset complete - new world will generate on first connection"