Hornwitser
90dacd98b2
Complete rework of the inventory synchronization to reduce the number of times the inventory has to be downloaded and the possibilities for item loss/duplication. The basic concept is to acquire exclusive access to the player data before downloading the data. This prevents the player from logging in to two servers at the same time and getting the synced inventory twice. The acquisition will in most cases execute faster than the player can provide input to the game on login, and if the player data on the master isn't what was previously uploaded then the player inventory is deleted and the player is turned into a spectator while the updated inventory is being transferred into the game. This model allows for the downloading of the synced inventory to be skipped in the case the player joins the same server they left from. The synced data is expanded to include more than just the character and inventory to properly handle sync of dead players. If the player leaves dead on one server this state will be saved and when the player joins another server they continue off as dead. The ghost, god, and spectator controllers are supported, while the cutscene and editor controllers are not. For players in a cutscene when joining the acquisition will be attempted immediately, but the scenario waits until the player is out of the cutscene before acting upon the response to the acquisition. For players in the editor mode the scenario toggles them out of the mode before syncing data. Since uploads to the master can fail handling of this is also added. The scenario will retry uploading the player data at exponentially increasing intervals until it gets the message back that the upload succeeded. Since it's possible for servers to go down and stay down for a long time the exclusive access held by these servers are released after a timeout. This means that a player could be playing and or have uploaded newer data by the time the instance comes back online and tries to upload the inventory, in this case the master will report the upload succeeded but discard the data. Instances may also upload old data if they load back to an earlier save, which will also be discarded by the master. Other small improvements made by this rework: - Add a retry button to the failed download dialog - Update the existing progress dialog instead of destroying and recreating it every time. - Automatically stuff the items from the temporary inventory into the synced inventory if they fit. - Move player back to the position they started the download from if they were turned into a spectator for the download. - Ensure the player has a character if the stored data is wiped. - Add error checking of the RCON commands sent by the instance.
Clusterio inventory sync plugin
Carry over player inventory between servers
As a player, it mostly just works. Most important to know is that factorio data transfer is slow, which means if you have "big" items (blueprints mostly) in your inventory it will take a long time to transfer when joining servers. For this reason it is recommended to keep blueprints in the blueprint library.
A note on crashing servers:
When a server crashes while you are online there won't be time to immediately upload the inventory. Instead, the inventory is uploaded as soon as the server restarts. This means if you have been playing on a different server from the one that crashed and gathered/consumed items but are offline at the time of the first server coming online again your inventory will reset to the autosave.
Installation
Run the following commands in the folder Clusterio is installed to:
npm install @clusterio/plugin-inventory_sync
npx clusteriomaster plugin add @clusterio/plugin-inventory_sync
Substitute clusteriomaster with clusterioslave or clusterioctl if this a dedicated slave or ctl installation respectively.
Method of operation
This plugin does event based synchronization of inventories. The greatly simplified data flow is as follows:
-
Player joins server.
-
Scenario script asks master for exclusive access to the player.
-
Master grants exclusive access for the player to the instance.
-
Scenario script checks the access response and then acts according to the situation:
- If the player has no inventory on the master then the current inventory becomes the synced inventory and the process is done.
- If the player inventory was previously uploaded and is the same as the one stored on the master then the current inventory becomes the synced inventory and the process is done.
- If the player inventory was previously uploaded but is not the same then the player inventory is deleted and the player is turned into a spectator.
- Otherwise the player inventory is kept.
-
Scenario script asks for the player inventory from the master.
-
Master sends it to the scenario in a stream of chunks.
-
Scenario displays and updates a progress bar as each chunk is received.
-
Once all chunks have loaded the player's synced inventory is recreated from the data and the player can start playing.
When the player leaves the inventory is uploaded if it's a synced inventory and the exclusive access the scenario script holds is released. Should an error occur during this process the player is given the option to use a temporary inventory instead, which will be merged back into the synced inventory the next time the sync succeeds on that instance.
Communication between the server and instance goes over stdout or rcon, depending on the size of the data. Communication between the instance and the master server goes over websockets. Overall, we are able to achieve a latency between 3 and infinite ticks from server join, depending on the size of the inventory. The major limiter is rcon transfer speeds with larger inventories, especially if they contain blueprints.