Server hitches when players cross zones in Abiotic Factor
Abiotic Factor's facility is split into discrete zones (Labs, Manufacturing, Office, Flathill, the Pools, and so on). Each zone is loaded on demand when a player walks across the boundary. On a busy multiplayer server this load is constant: someone is always crossing a doorway. When zone load gets behind, you see hitches, container interactions fail, and the server log fills with errors like:
LogActor: Warning: UpdateActorToWorldSave called for object Container_M_C ...
tried to save before Save Data was loadedThis page explains what the error means, what mitigations are in the customer's hands, and where the platform side fits in.
What the error actually means
Each zone has a side-car save record on disk. When the engine loads a zone, it reads the save record into memory before allowing actors (containers, interactables, dropped items) in that zone to write back. If an actor's save request fires before its zone's record has finished loading, the engine logs a warning and skips the write.
The skipped write does not corrupt anything — the engine retries when the record is ready — but each skip is a small piece of work that has to be redone, and a flood of them shows up as periodic stalls and dropped interactions. The root condition is almost always I/O contention: the disk cannot keep up with the rate of zone loads.
Three places the bottleneck can live
- Disk I/O on the node. Shared NVMe under load from a noisy neighbour. This is the most common cause when the same server was fine yesterday and is hitching today.
- Plan tier. Lower tiers cap I/O bandwidth. A modded Abiotic Factor save with a hundred placed containers per zone reads more on each transition.
- Game-side autosave frequency. If the server is asked to write saves more often than the disk can keep up with, every transition gets in line behind a save.
Mitigations you can try first
Reduce autosave frequency
Open the Config tab and look for the autosave interval. The default is aggressive; if your group plays in short bursts where a single rollback of 10-15 minutes is acceptable, raise the interval. Less competition between save writes and zone reads means fewer of the "save before loaded" warnings.
Avoid simultaneous zone crossings
Hitching is worst when several players cross zone boundaries at the same time. If you can keep the group together (or staggered) during expeditions, the disk has time to finish each zone load before the next one starts. This is a behavior change, not a config change, but on shared-disk plans it visibly reduces hitches.
Cap placed-object density per zone
Each placed container, light, decoration, and crafted machine adds to the zone's save size. A heavily-decorated Pools or Labs base loads slower than a sparse one. If a particular zone is the one that hitches every time, walk through it and look for redundant containers.
Restart on a schedule
The engine's actor pool fragments over time. A daily restart (lowest-traffic hour) compacts memory and tightens save-load timings.
When the platform side has to help
If you have done all of the above and the hitches continue, the issue is on the node, not in the save. Symptoms that point at the platform:
- The hitches happen at the same hour each day (a neighbour with scheduled work).
- The Resource Usage graph shows RAM and CPU both well below tier limits, but disk-read latency spikes during the hitches.
- Other Supercraft customers on the same node are also reporting issues.
Open a support ticket. We can look at the node's disk I/O metrics, and either migrate your server to a less congested node or move you to a node with faster local storage. Migration takes about 15 minutes and preserves the save and configuration completely.
Plan-tier guidance
| Players | Placed objects per zone | Recommended plan |
|---|---|---|
| 2 to 4 players, light decoration | under 50 | Plan S |
| 4 to 6 players, normal base | 50 to 150 | Plan M |
| 6 to 8 players, heavy base or modded | 150 to 300 | Plan L |
| 8+ players, ambitious build | 300+ | Plan XL, expect to ask for a fast-disk node |
A plan upgrade gives you more CPU shares and more RAM, both of which help indirectly: less paging, faster save serialisation, more room for the actor pool. It does not give you a faster disk; that is a node-level property.
What this error is not
- Not save corruption. The retry succeeds; data persists.
- Not a player-side issue. Players can do nothing about it from the client.
- Not solved by reinstall. A Wipe and Reinstall throws away your world and replays the same scenario on the same node.
Need a server tier that can keep up with a big expedition group? See Abiotic Factor plans. Higher tiers include faster-disk node placement; migration on request is free.