Nasdara: lock slot lists on rebuildable houses grow on every world load → building_001.bin bloats to ~1.8 GB → server freezes, write failures, loss of player-built structures

Version: 1.30.164078 (Steam Stable), dedicated Windows server, map Nasdara
Server mods: @CF, @GameLabs (no mods that touch base building or locks)
Related: DZG-1404 (same issue, additional data below)

Summary
On Nasdara, rebuildable houses (Land_House_*) with locks attached cause storage_1\data\building_001.bin to grow rapidly on every restart, until saving breaks and player-built structures are lost.

Timeline / measurements

• 11:41: building_001.bin = 472,862 KB, 20,476 entries

• 12:37: 1,882,175 KB

• 13:44: 1,882,176 KB (growth stops here; probably the size limit was reached)

• The number of entries stayed at exactly 20,476 the whole time. Only the size per entry grew.

• Load time for building_001 went from 31 s (12:02) to 53 s (14:02).

Symptoms

1. Server froze for 10–20 s roughly every 70 s. Server FPS dropped from ~1,500 to 8–20, with nothing logged during the freezes. Players were rubber-banded and inventory actions failed.

2. Repeated write errors, 4 retries 0.5 s apart:
   !!! Failed to write [Storage] data to file "...storage_1\data\building_001.bin" - failed to open the file.

3. After a restart, all three copies were unreadable:
   !!! [CE][Storage] Failed to read [Storage] data file "building_001.bin / .001 / .002" → valid:NO

4. The server started without building_001 data. All rebuilt walls and doors on the map were gone. The next saves overwrote the remaining copies with the state without the bases.

Analysis of the bloated file (backup from 11:41, 462 MB)

• The file structure itself is intact: _EOF marker present, the top-level record chain is consistent, 20,476 records.

• The size comes almost entirely from attachment slot name lists on 5 houses. Each list is a u32 count followed by length-prefixed strings:

  • Att_CombinationLock2_Wood × 3,145,728

  • Att_CombinationLock1_Wood × 1,032,192

  • Att_CombinationLock3_Metal / _CombinationLock1_Metal / _CombinationLock3_Wood, mixed, × 262,144

  • Att_CombinationLock1_Metal × 4,096

  • Att_CombinationLock4_Wood / _CombinationLock2_Wood, alternating, × 96

• Each list contains only 1–3 unique names. The rest are duplicates, mostly exact repetitions or power-of-two counts.

• Every affected house record exists 4 times with identical content: same hash, position and data. This also applies to all other building records: 20,476 = 4 × 5,119.

Expected behavior

• Lock slot lists should not grow on load or save.

• Each building object should be saved once per save.

• The storage writer should never produce a file that can’t be read, and should have a size or sanity check.

Additional notes

• Restoring an affected backup does not help on its own. The duplicates are already in the file and keep doubling on the next load.

• I can provide the bloated file (zipped ~2 MB) and the repaired version if needed.

Nasdara: lock slot lists on rebuildable houses grow on every world load → building_001.bin bloats to ~1.8 GB → server freezes, write failures, loss of player-built structures

Version: 1.30.164078 (Steam Stable), dedicated Windows server, map Nasdara
Server mods: @CF, @GameLabs (no mods that touch base building or locks)
Related: DZG-1404 (same issue, additional data below)

Summary
On Nasdara, rebuildable houses (Land_House_*) with locks attached cause storage_1\data\building_001.bin to grow rapidly on every restart, until saving breaks and player-built structures are lost.

Timeline / measurements

• 11:41: building_001.bin = 472,862 KB, 20,476 entries

• 12:37: 1,882,175 KB

• 13:44: 1,882,176 KB (growth stops here; probably the size limit was reached)

• The number of entries stayed at exactly 20,476 the whole time. Only the size per entry grew.

• Load time for building_001 went from 31 s (12:02) to 53 s (14:02).

Symptoms

1. Server froze for 10–20 s roughly every 70 s. Server FPS dropped from ~1,500 to 8–20, with nothing logged during the freezes. Players were rubber-banded and inventory actions failed.

2. Repeated write errors, 4 retries 0.5 s apart:
   !!! Failed to write [Storage] data to file "...storage_1\data\building_001.bin" - failed to open the file.

3. After a restart, all three copies were unreadable:
   !!! [CE][Storage] Failed to read [Storage] data file "building_001.bin / .001 / .002" → valid:NO

4. The server started without building_001 data. All rebuilt walls and doors on the map were gone. The next saves overwrote the remaining copies with the state without the bases.

Analysis of the bloated file (backup from 11:41, 462 MB)

• The file structure itself is intact: _EOF marker present, the top-level record chain is consistent, 20,476 records.

• The size comes almost entirely from attachment slot name lists on 5 houses. Each list is a u32 count followed by length-prefixed strings:

  • Att_CombinationLock2_Wood × 3,145,728

  • Att_CombinationLock1_Wood × 1,032,192

  • Att_CombinationLock3_Metal / _CombinationLock1_Metal / _CombinationLock3_Wood, mixed, × 262,144

  • Att_CombinationLock1_Metal × 4,096

  • Att_CombinationLock4_Wood / _CombinationLock2_Wood, alternating, × 96

• Each list contains only 1–3 unique names. The rest are duplicates, mostly exact repetitions or power-of-two counts.

• Every affected house record exists 4 times with identical content: same hash, position and data. This also applies to all other building records: 20,476 = 4 × 5,119.

Additional notes

• Restoring an affected backup does not help on its own. The duplicates are already in the file and keep doubling on the next load.

• I can provide the bloated file (zipped ~2 MB) and the repaired version if needed.

Manual repair (worked)

• Reduced each list to its unique entries, set the u32 count to match, and recalculated all absolute offset/pointer fields after the removed data.

• Result: 462 MB → 3.1 MB. The server loaded it with 20476 items loaded. (0 failed), and all structures were restored.

Workaround that stopped the growth

• Removed all locks from rebuilt houses in-game: 8 houses, 12 locks, mostly digital code locks plus 2 combination locks.

• After the next restart, building_001 contains 5,119 entries instead of 20,476. Each building is now saved once instead of four times. All copies (.bin/.001/.002) are valid, there are no write errors, and server FPS is stable at ~7,000.

• This strongly suggests that locks on rebuildable houses cause both the duplicated slot lists and the quadruple saving of building records.

Expected behavior

• Lock slot lists should not grow on load or save.

• Each building object should be saved once per save.

• The storage writer should never produce a file that can’t be read, and should have a size or sanity check.