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
33 lines
1.4 KiB
Lua
33 lines
1.4 KiB
Lua
-- 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 = {
|
|
{ worldX = 40, worldY = 22, posX = 67, posY = 201 }
|
|
}
|
|
}
|
|
end
|