Desynchronization: Difference between revisions
Muppet9010 (talk | contribs) No edit summary |
Muppet9010 (talk | contribs) No edit summary |
||
Line 33: | Line 33: | ||
Within each save game's zip in the desync report are a number of files that when compared can help to highlight the desync cause. 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. | Within each save game's zip in the desync report are a number of files that when compared can help to highlight the desync cause. 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 [https://lua-api.factorio.com/latest/Global.html Factorio global tables]. Generally, | * script.dat - contains the scenario and mods [https://lua-api.factorio.com/latest/Global.html Factorio global tables]. Generally, the saves persistent data should be the same between the 2 saves. The file contents when viewed are a dump of the Lua table and so are partially human readable. The non-human readable item includes table ids and ''magic'' numbers related to the c++ game state. These ids and references should generally be the same between saves as the in-game entity they reference normally won't have changed. | ||
=== Using heavy mode command === | === Using heavy mode command === | ||
[[Console#Normal_commands|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 [[Application directory#User_data_directory|Factorio Data folder]]. | [[Console#Normal_commands|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 [[Application directory#User_data_directory|Factorio Data folder]]. | ||
Typically this process will trigger for any incorrect changing of data as part of the on_load event or local/global variables being changed and not persisted. | Typically this process will trigger for any 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 in many places isn't human readable. | ||
== Desync reporting of core Factorio game == | == Desync reporting of core Factorio game == |
Revision as of 20:28, 21 February 2019
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.
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.
Examining the desync files
Within each save game's zip in the desync report are a number of files that when compared can help to highlight the desync cause. 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. The file contents when viewed are a dump of the Lua table and so are partially human readable. The non-human readable item includes table ids and magic numbers related to the c++ game state. These ids and references should generally be the same between saves as the in-game entity they reference normally won't have changed.
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 any 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 in many places isn't human readable.
Desync reporting of core Factorio game
If no mod or scenario was involved in the desync, the desync report and activity information should be posted to the Factorio forums bug report section.