Bastian de BylandClaude Opus 5
ba9c4f2bfe
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
Deploy Home
There's no place like home!
Just as Dorothy managed the simple task of clicking her heels together, the desire for an equally simple one-button push deployment was in my heart. Thus, this repository was made.
Ansible
Ansible, along with double encrypted secrets, deploys the necessary configurations to make the home fit for certain needs and desires. Namely, having access to my home from anywhere, securely, and a self-hosted CI server that easily ties into existing workflows.
Makefile
The makefile is primarily used as a wrapper script to ensure that necessary
files, such as the secret vault password file, are provisioned as part of this.
One such addition to the task is utilizing dependency pinning through the
utilization of Python's virtualenv to lock down the specific dependency
versions within the requirements.txt file. This, ideally, prevents any
deployment issues with dependency version woes (e.g. version conflicts, major
updates in newest versions, etc.)
| Target Name | Description |
|---|---|
lint |
(default) Runs yamllint and ansible-lint on all YAML files in ansible/ |
deploy |
Deploys everything, or only tasks specified in TAGS= environment variable |
check |
Runs deploy in a "dry-run", showing diff-style outputs on tasks indicating changes |
vault |
Opens the Ansible vault file for editing |