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
parent 9954d774e7
commit ba9c4f2bfe
7 changed files with 456 additions and 226 deletions
@@ -1,3 +1,28 @@
+-- Deployed as Server/debbzoid_spawnpoints.lua, and currently unused: nothing
+-- reads it, because no entry in spawnregions.lua names it with
+-- serverfile = "debbzoid_spawnpoints.lua". The contents below are the stock
+-- sample and mean nothing until such an entry exists.
+--
+-- This is the file to use if a spawn point has to move rather than disappear.
+-- Point a region at it by serverfile instead of file, and put that region's
+-- whole spawn table here -- the serverfile replaces the map's list, it does not
+-- merge with it, so anything left out is gone.
+--
+-- Keeping "Echo Creek, KY" as a spawn choice while freeing the diner would look
+-- like this, with an outdoor square -- the parking lot or the road, not another
+-- building, or that building becomes the unclaimable one instead:
+--
+--     unemployed = {
+--         { posX = <outdoor X>, posY = <outdoor Y>, posZ = 0 },
+--     }
+--
+-- Coordinates are absolute world tiles when worldX/worldY are omitted; with
+-- them, the world position is worldX * 300 + posX (same for Y).
+--
+-- The filename is not free-form: serverfile resolves inside the server's
+-- Server/ directory, and the deploy names this copy after zomboid_server_name.
+-- Rename the server and the serverfile reference has to follow, or the region
+-- loses its points and drops out of the list.
 function SpawnPoints()
 	return {
 		unemployed = {
@@ -1,7 +1,35 @@
+-- Spawn regions offered to new characters, deployed as
+-- Server/debbzoid_spawnregions.lua. PZ reads it at every server start, so a
+-- change here takes effect on the live world after a restart -- no wipe.
+--
+-- Each entry either points at a map's own list (file = ...) or at a file in the
+-- server's Server/ directory (serverfile = ...). Both are loaded by
+-- media/lua/shared/SpawnRegions.lua; a region whose file is missing logs
+-- "spawn points may be broken" to the server console and is dropped from the
+-- list, taking its spawn choices with it.
+--
+-- This list is also what makes buildings unclaimable. SafeHouse.canBeSafehouse
+-- walks every point of every region here, resolves each to a grid square, and
+-- refuses the claim with "Spawn location. Cannot be claimed." if the square
+-- being claimed is inside that square's building. It does not care which
+-- profession the point belongs to, whether the region is reachable, or whether
+-- the player is an admin. A point on an outdoor square blocks nothing, because
+-- an outdoor square has no building.
+--
+-- 2026-08-31: "Echo Creek, KY" is commented out below. Its spawn list holds
+-- exactly one point -- posX 3573, posY 10899, unemployed only -- and that point
+-- sits inside the Echo Creek gas station/diner, which is why the diner cannot
+-- be claimed as a safehouse. There is no server option that lifts the
+-- restriction, so removing the region is the only way to free the building
+-- short of moving the point somewhere else (see spawnpoints.lua).
+--
+-- The cost of removing it: unemployed characters lose Echo Creek as a spawn
+-- choice. Nothing else changes -- the town, its loot and its buildings stay in
+-- the world, and no existing character is affected.
 function SpawnRegions()
 	return {
 		{ name = "Brandenburg, KY", file = "media/maps/Brandenburg, KY/spawnpoints.lua" },
-		{ name = "Echo Creek, KY", file = "media/maps/Echo Creek, KY/spawnpoints.lua" },
+--		{ name = "Echo Creek, KY", file = "media/maps/Echo Creek, KY/spawnpoints.lua" },
 		{ name = "Ekron, KY", file = "media/maps/Ekron, KY/spawnpoints.lua" },
 		{ name = "Fallas Lake, KY", file = "media/maps/Fallas Lake, KY/spawnpoints.lua" },
 		{ name = "Irvington, KY", file = "media/maps/Irvington, KY/spawnpoints.lua" },