Bugfix/1467 Missing structures after server crash/restart

[Z1Meme]

Summary

Fixes #1467: players report a shelter — most often an upper shelter — vanishing on a server restart along with all the loot stored inside it, while the foundation, the lower shelter, and the rest of the base remain intact. No decay, no raid, no manual removal; it just disappears after the restart, and it recurs every wipe on fresh data.

This PR fixes the root cause and adds defense-in-depth across the entire construction save/load path so this class of silent data loss cannot recur through any other route.

Root cause

Construction is persisted as one document per top-level foundation, with children (walls, shelters, upper shelters, gates, loot) nested by a recursive serializer that walks each parent's slot maps and freeplace list. This creates a hard invariant:

A construction entity is saved only if it is reachable from a top-level foundation's in-memory slot/freeplace graph at save time. Anything live in memory but unreachable is an orphan, silently dropped from the next save — and gone on the next restart.

ConstructionChildEntity.setSlot() wrote occupiedSlots[slot] = entity unconditionally. When a second entity resolved to a slot already occupied by a different one (an upper shelter is the common real-world case), the incumbent was overwritten out of its parent's occupiedShelterSlots while remaining live in _constructionSimple. It became unreachable from the foundation's save graph and was dropped — with its nested loot — on the next save. The foundation and lower shelter survived because they were still in the graph. This was reproduced end-to-end against the pre-fix code (place → overwrite → save → reload): the orphaned upper and its loot are gone after reload, everything else intact.

The fix

setSlot() now refuses to overwrite an occupied slot with a different entity (re-setting the same entity stays idempotent, so reloads are safe):

const existing = occupiedSlots[slot];
if (existing && existing.characterId !== entity.characterId) {
  return false;
}

setSlot is the single writer to every slot map, so this is a universal chokepoint:

• At placement, a conflicting placement is rejected cleanly instead of silently orphaning the incumbent.
• At load, a conflicting saved entry is re-homed to the parent's freeplaceEntities via the existing load fallback instead of overwriting — so the structure and its loot both survive rather than one being dropped.

Defense-in-depth (the rest of the branch)

Layered so an orphan can't reach the save through any other path:

• Prevent: placement callers now bail (and clean up) on a failed slot assignment instead of leaving a half-placed entity; expansion/ramp load conflicts re-home rather than clobber.
• Tolerate: load loops use ?? {} + per-child try/catch (one corrupt child no longer discards a whole base); the world save isolates per-foundation serialization failures and retains their ids so the prune step can't erase a base whose save momentarily failed; the shutdown save is best-effort; serialization is cycle-safe.
• Detect: an operator-gated, sampled, yielding save-time backstop logs any construction that is live but unreachable from the save graph, turning a future regression into a loud warning instead of silent loss.
• Diagnostic: setSlot logs whenever it blocks an overwrite — i.e. exactly when this bug would have occurred — with the parent, slot, and both entities, so the precise in-game trigger can be identified from server logs after deploy.

Behavior change (decay)

The decay vacancy/grief checks now distinguish structural freeplace from loot: a deck holding a re-homed shelter/gate is no longer wrongly wiped as "vacant," but a deck holding only a storage/loot container is not kept alive by it and decays normally.

Changes by area

Area | Files | What -- | -- | -- Core fix | entities/constructionchildentity.ts | setSlot overwrite guard; broken-parent-chain handling; cascadeDestroyConstructionChild; overwrite diagnostic Placement | managers/constructionmanager.ts | bail-on-slot-failure; expansion/ramp guards; demolish-undo double-action fix Parent destroy | entities/constructionparententity.ts | preserveChildrenOnDestroy re-homes children to a surviving deck Save/load | managers/worlddatamanager.ts | load ?? {}+try/catch; per-foundation save isolation + retain-ids; expansion/ramp re-home; container/cycle hygiene Save graph | zoneserver.ts | best-effort shutdown save; gated/sampled orphan backstop Decay | managers/decaymanager.ts | structural-vs-loot vacancy gating Config | models/config.ts, managers/configmanager.ts, defaultconfig.yaml | construction.constructionOrphanCheck flag Tests | *.test.ts | regression coverage for every layer

Testing

Type-check clean (TS 6.0.3); construction + decay + utils suites green, including new regressions: setSlot overwrite-rejection, missing-slot-map load, unplaceable-expansion re-home, orphan backstop, loot-only deck decays, and a full save→reload round-trip with re-homed structures + nested loot.

Important deployment note

The setSlot guard is not on dev today, so live servers keep losing structures every wipe until this merges. Merging this PR is what ships the fix.

Known / follow-up (transparent)

The outcome (overwrite → orphan → drop) is reproduced and fixed. The exact in-game event that creates the slot collision on an intact base is not yet named — naive double-placement is already blocked by the overlap gate, so the trigger lives in the client→placement packet path. The added setSlot diagnostic is designed to capture it from production logs within one wipe cycle (and confirm the fix is catching it). One unrelated latent wart was also fixed: demolishConstructionEntity fell through after an undo-placement destroy() and re-hit the removed entity.

Summary Fixes [#1467](https://github.com//issues/1467): players report a shelter — most often an upper shelter — vanishing on a server restart along with all the loot stored inside it, while the foundation, the lower shelter, and the rest of the base remain intact. No decay, no raid, no manual removal; it just disappears after the restart, and it recurs every wipe on fresh data.

This PR fixes the root cause and adds defense-in-depth across the entire construction save/load path so this class of silent data loss cannot recur through any other route.

Root cause
Construction is persisted as one document per top-level foundation, with children (walls, shelters, upper shelters, gates, loot) nested by a recursive serializer that walks each parent's slot maps and freeplace list. This creates a hard invariant:

A construction entity is saved only if it is reachable from a top-level foundation's in-memory slot/freeplace graph at save time. Anything live in memory but unreachable is an orphan, silently dropped from the next save — and gone on the next restart.

ConstructionChildEntity.setSlot() wrote occupiedSlots[slot] = entity unconditionally. When a second entity resolved to a slot already occupied by a different one (an upper shelter is the common real-world case), the incumbent was overwritten out of its parent's occupiedShelterSlots while remaining live in _constructionSimple. It became unreachable from the foundation's save graph and was dropped — with its nested loot — on the next save. The foundation and lower shelter survived because they were still in the graph. This was reproduced end-to-end against the pre-fix code (place → overwrite → save → reload): the orphaned upper and its loot are gone after reload, everything else intact.

The fix
setSlot() now refuses to overwrite an occupied slot with a different entity (re-setting the same entity stays idempotent, so reloads are safe):

const existing = occupiedSlots[slot];
if (existing && existing.characterId !== entity.characterId) {
return false;
}
setSlot is the single writer to every slot map, so this is a universal chokepoint:

At placement, a conflicting placement is rejected cleanly instead of silently orphaning the incumbent.
At load, a conflicting saved entry is re-homed to the parent's freeplaceEntities via the existing load fallback instead of overwriting — so the structure and its loot both survive rather than one being dropped.
Defense-in-depth (the rest of the branch)
Layered so an orphan can't reach the save through any other path:

Prevent: placement callers now bail (and clean up) on a failed slot assignment instead of leaving a half-placed entity; expansion/ramp load conflicts re-home rather than clobber.
Tolerate: load loops use ?? {} + per-child try/catch (one corrupt child no longer discards a whole base); the world save isolates per-foundation serialization failures and retains their ids so the prune step can't erase a base whose save momentarily failed; the shutdown save is best-effort; serialization is cycle-safe.
Detect: an operator-gated, sampled, yielding save-time backstop logs any construction that is live but unreachable from the save graph, turning a future regression into a loud warning instead of silent loss.
Diagnostic: setSlot logs whenever it blocks an overwrite — i.e. exactly when this bug would have occurred — with the parent, slot, and both entities, so the precise in-game trigger can be identified from server logs after deploy.
Behavior change (decay)
The decay vacancy/grief checks now distinguish structural freeplace from loot: a deck holding a re-homed shelter/gate is no longer wrongly wiped as "vacant," but a deck holding only a storage/loot container is not kept alive by it and decays normally.

Changes by area
Area Files What
Core fix entities/constructionchildentity.ts setSlot overwrite guard; broken-parent-chain handling; cascadeDestroyConstructionChild; overwrite diagnostic
Placement managers/constructionmanager.ts bail-on-slot-failure; expansion/ramp guards; demolish-undo double-action fix
Parent destroy entities/constructionparententity.ts preserveChildrenOnDestroy re-homes children to a surviving deck
Save/load managers/worlddatamanager.ts load ?? {}+try/catch; per-foundation save isolation + retain-ids; expansion/ramp re-home; container/cycle hygiene
Save graph zoneserver.ts best-effort shutdown save; gated/sampled orphan backstop
Decay managers/decaymanager.ts structural-vs-loot vacancy gating
Config models/config.ts, managers/configmanager.ts, defaultconfig.yaml construction.constructionOrphanCheck flag
Tests *.test.ts regression coverage for every layer
Testing
Type-check clean (TS 6.0.3); construction + decay + utils suites green, including new regressions: setSlot overwrite-rejection, missing-slot-map load, unplaceable-expansion re-home, orphan backstop, loot-only deck decays, and a full save→reload round-trip with re-homed structures + nested loot.

Important deployment note
The setSlot guard is not on dev today, so live servers keep losing structures every wipe until this merges. Merging this PR is what ships the fix.

Known / follow-up (transparent)
The outcome (overwrite → orphan → drop) is reproduced and fixed. The exact in-game event that creates the slot collision on an intact base is not yet named — naive double-placement is already blocked by the overlap gate, so the trigger lives in the client→placement packet path. The added setSlot diagnostic is designed to capture it from production logs within one wipe cycle (and confirm the fix is catching it). One unrelated latent wart was also fixed: demolishConstructionEntity fell through after an undo-placement destroy() and re-hit the removed entity.

[Z1Meme]

Rewritten player-facing patch notes (hedged — work done, needs further testing)
(Lead-in note + sections in the project's release style.)

Note: This release contains a large amount of work targeting the long-standing issue of shelters and their stored items disappearing after a server restart. We've identified and fixed a root cause and significantly hardened the construction save/load system against this kind of data loss, but the exact in-game trigger hasn't been fully confirmed yet, so this needs further live testing. Please keep reporting any structures or loot that go missing — diagnostic logging has been added to help pinpoint it.

Fixed Issues

Addressed the issue where shelters, gates, and the items stored inside them could disappear after a server restart — stacked (upper) shelters in particular should no longer be dropped from the world save (continued reports welcome while we confirm)
A single damaged or corrupted structure can no longer cause the rest of a base to roll back to an older state on save
Structures whose attachment point is unavailable when the world loads are now kept as free-placed objects instead of being deleted
Undoing a structure placement no longer applies a second, erroneous hit to the structure being removed
Gameplay Adjustments

A deck holding only a storage box or other loose item is no longer treated as occupied and will decay and despawn like any other empty deck
A deck still holding a shelter or gate left behind after a supporting piece was removed is now correctly preserved and will no longer be wiped by decay

[Z1Meme]

NOTE: This PR has not yet been in-game tested. Serverside simulations have been run in order to try to reproduce this bug, and for testing the "hardening" fixes specifically with the construction system. Further testing is required, as well as careful code review since this PR was written by agents. The first few commits were targeting a false-positive for the #1467 bug, and some things were corrected in further commits. The actual root-cause in-game that caused shelters to become "orphans" is still unknown, however the preventative measures added in this PR should fully address it, prevent it from happening in the future, and document in the console on instances where it could occur again.