Hornwitser
e74065a493
Refactor away the config group concept and simplyfy the way config fields are defined. Fields are defined directly as properties of the static field fieldDefinitions on the class itself with a separate interface to declare the types of fields. This makes it possible to easily make accessing the config fields type checked in a way that lets plugins extend the interfaces with their own config options by adding additional fields to the interface via declation merging.
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 clusteriocontroller plugin add @clusterio/plugin-inventory_sync
Substitute clusteriocontroller with clusteriohost or clusterioctl if this a dedicated host 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 controller for exclusive access to the player.
-
Controller 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 controller 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 controller 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 controller.
-
Controller 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 controller 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.