Desynchronization

A desynchronization (desync) is when during multiplayer a player's game becomes desynchronised from the Factorio server. Their game has become different from the server's game.

What are desyncs

Desyncs can be caused either by a bug in the core Factorio game code or by a bug in a mod/scenario. They should not occur during regular activity.

Factorio multiplayer architecture

Factorio multiplayer code uses Deterministic Lockstep to synchronize clients, this is a method of synchronizing a game from one computer to another by sending only the user inputs that control that game, rather than networking the state of the objects in the game itself. It means that all players need to simulate every single tick of the game identically. If any computer does something ever-so-slightly different, a desynchronization (desync) occurs. The game includes processes to ensure any issues with network traffic does not cause desyncs.

Player experience of desyncs

Upon a desync between a player and server occurring that player immediately disconnects from the server and starts to reconnect. This reconnection isn't to allow the player to play the game, but to obtain the server's copy of the save game (map and game state) to include in a desync report. After the reconnection is complete the player is offered the options to save the report, quit or reconnect to the server to play.

The desync report can be provided to either the mod/scenario makers or the Factorio game developers to help them resolve the bug. Depending upon the exact cause of the desync the player may be able to reconnect to the player and continue playing, or they may immediately desync on reconnecting.

Desync Report

The desync report contains both the player's and server's copy of the save game (map and game state). The player's copy is from when the desync occurred and titled desynced-level. With the server's copy being from when the automatic reconnection was made and titled reference-level.zip. A copy of the players Factorio log file is included titled log.txt.

The desync report does not state the cause but is a record of the game state at the time of the desync.

Desync investigations with mods/scenarios involved

The desync report is a useful reference for investigating desyncs but it does not state the cause of the desync. Ideally, it is supplemented by an account of what was occurring and being done by players at the point of the desync occurring. In most cases when desyncs occur and mods or scenarios are being used they are the cause. If they are found to not be the cause then it should be reported as a core Factorio desync error.

Code that causes desyncs

There are a number of ways mod code can cause desyncs due to incorrect variable scoping, requiring or API event handling. Examples of these can be found in the Gansir's modding tutorial multiplayer and desyncs section, with the full technical definition of usage constraints for API events in the Factorio API data lifecycle

The code of the mod can be reviewed if you are familiar with these requirements and it isn't too extensive or abstracted. The supporting information about what occurred at the time of the desync can assist with narrowing down the code to review. Any concerns should be raised to the code author.

Comparing game state & save files

The desync report and heavy mode dumps contain a number of files that can be compared to look for differences. These files are generally sequenalized dumps of Lua tables or game information and so are partially human readable. The non-human readable item includes table ids (0x.NUMBER) and magic numbers related to the c++ game state. These ids and references should generally be the same between files as the in-game entity they reference normally won't have changed.

Examining the desync files

Within each save game's zip in the desync report are a number of files that when compared can show data changes, and thus point to areas of the mod to review. However, as the server copy of the save is obtained after the desync there may be genuine differences between the files. So differences aren't hard evidence of the cause of a desync, but a pointer on where to investigate further.

• script.dat - contains the scenario and mods Factorio global tables. Generally, the saves persistent data should be the same between the 2 saves.

Using heavy mode command

Heavy mode is an in-game option that can be enabled to make Factorio save and load the game very tick. This allows Factorio to highlight if there are any changes in the game state between the save and subsequent load. Should a state change occur a message is shown in-game and the game states recorded to a dumps folder in the players Factorio Data folder. Typically this process will trigger for incorrect changing of data as part of the on_load event or local/global variables being changed and not persisted. The recorded game state is a dump of the internal game state and so typically less helpful in identifying the exact nature of the mod's state change, just that one has occured.

Desync reporting of core Factorio game

If no mod or scenario were involved in the desync, the desync report and activity information should be posted to the Factorio forums bug report section.