Hornwitser
bfe119eaa3
Move all functions and classes currently available through lib/name and libName to be under a single flat namespace in lib. This make reorganising the lib namespace much simpler as the location of symbols can move without breaking the consumers of lib. The multi-entrypoint design was already problematic for the web plugin system which couldn't effectively use it due to how webpack's shared module system is awkward to set up with multiple entrypoints per package.
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.