On Nasdara the radio bunker system (BroadcastedBunker) misbehaves around every server restart. Root cause: at startup the world runs at the world's startTime (10:00 in our case) for a few seconds before the persisted/real server time is applied. The bunker scheduler (BunkerBroadcastScheduler) is created during that window and reads 10:00. A few seconds later real time (night) is applied, and about 40 seconds after start the scheduler performs an EXTRA batch switch on top of the batch it just restored from BunkerBroadcastPersistenceStorage.

This single extra switch causes three linked problems:

1. Code accepted, door won't open. A bunker's state is split across two stores that desync on restart: the codelock PIN is persisted (DigitalCodeLock.OnStoreSave), but the bunker's active flag (Bunker.m_IsActive) is NOT persisted. After the extra switch the old bunkers are deactivated, so m_IsActive is false and the door can't be opened from outside, yet the lock still accepts the old PIN. Players enter the correct code and nothing happens.

2. Broadcast codes no longer match reality. After restart the scheduler re-broadcasts a freshly selected batch with new codes. Players who wrote down codes from before the restart arrive at bunkers that are already deactivated.

3. Storage crates disappear from bunkers. On the batch switch the old bunkers are deactivated; OnBunkerDeactivated calls m_StorageBox.SetLifetime(5.0) but does NOT null m_StorageBox. The crate is then removed by the engine, but not after 5 seconds as the script intends. In our logs it is removed 25 to 80 seconds later, in no fixed order, regardless of whether the crate is full or empty and regardless of a player being within 100m. If the same bunker is re-selected into the new batch (bunker history is empty right after a restart, so repeats are possible), OnBunkerActivated sees m_StorageBox still set and takes result=REUSED_OLD instead of spawning a fresh crate; that reused crate is the one already flagged for deletion, so it is not refilled and then vanishes. Result: a bunker whose code is currently broadcast and whose door opens, but with no storage crate inside.

How we investigated: we wrote a server-side diagnostic mod (in the attachments) that hooks BroadcastedBunker (OnBunkerActivated, OnBunkerDeactivated), StorageBox_Colorbase (EECargoIn, EECargoOut, EEDelete) and a monitor scanning all 23 crate points every 3 seconds. It logs, per bunker: activation with loadedAsActive and IsInitialized, crate presence and item count before and after, the path taken (SPAWNED_NEW, REUSED_OLD, REPLACED, NO_BOX_AFTER), cargo added or removed, crate deletion (BOX_DELETED) with coordinates, and a teleport line with coordinates and code. The mod only reads state; vanilla bunker scripts are unchanged.

Timeline from one controlled run (vanilla scripts, clean wipe, serverTimePersistent on, time acceleration 4 day and 6 night, start time forced to 01:00 night):

1. 13:19:24 server start, game time 10:00.

2. 13:19:42 three bunkers restored from persistence, active, crates present (REUSED_OLD).

3. 13:19:51 our admin connects at the third bunker; code works, door opens, crate present (we had emptied this one before the restart, so items=0).

4. 13:20:22 EXTRA batch switch: those three are deactivated, three new ones activated with fresh crates.

5. 13:20:48, 13:20:49 and 13:21:40 the three old crates are deleted by the engine (BOX_DELETED), 26, 27 and 78 seconds after deactivation.

6. 13:22:46 admin returns to an old bunker; crate already gone.

This matches the ADM position log of the admin for the same run minute by minute.

So the crate is NOT removed in 5 seconds. There is roughly a 40 second window after restart where the restored bunkers are still active and openable with the old code, after which the extra switch deactivates them and their crates are cleaned up 25 to 80 seconds later.

Attachments (Google Drive): https://drive.google.com/drive/folders/1u4usxo2f6ZqfriSh8j93eS9sRA18WPV9?usp=sharing

Contents:

1. @unpleme_BunkerDebug.zip, diagnostic mod (source and pbo), server-side, read-only.

2. BunkerDebug.zip, mod logs with the timeline above (ACTIVATE, DEACTIVATE, BOX_DELETED, TP lines).

3. profiles.zip, server profile logs (script and RPT) for the same runs.

4. storage_1.zip, CE storage snapshot.

5. BunkerBroadcastPersistenceStorage.bin, active batch and codes at the moment of capture.

1. Nasdara, serverTimePersistent on, time acceleration 4 day and 6 night, start time set to night (01:00).

2. Clean wipe, start server, wait for a night batch of 3 bunkers to be selected; crates spawn (items=9).

3. Restart the server while it is night in-game.

4. Within about 40 seconds of start, enter a restored bunker with its old code: door opens, crate present.

5. Wait past the extra batch switch (about 40 seconds after start). Old bunkers deactivate: the lock accepts the code but the door no longer opens, and 25 to 80 seconds later their crates are deleted.

6. If a bunker is re-selected into the new batch, its door opens with the newly broadcast code but the crate is missing.

After a restart the restored batch should stay consistent: broadcast codes match the bunkers that actually open, doors open from outside with the broadcast code, and every active bunker has exactly one freshly stocked crate. Specifically:

1. The temporary startTime (10:00) during startup must not trigger an extra batch switch.

2. Bunker active state and code should be persisted and restored together as one state.

3. OnBunkerDeactivated should clear m_StorageBox and remove the crate deterministically.

4. A bunker re-selected into a new batch should spawn a fresh crate rather than reuse one already flagged for deletion.