bbassieandClaude Fable 5
a25f8c8611
The largest source was compat.lua returning the setmetatable call directly, which made emmylua infer the module type from the metatable rather than the LibCompat class, hiding every field from consumers. The remaining fixes are nil guards on gui element and character accesses, type annotations for research_sync's script data and player_auth's rcon arguments, casts where the api's read/write union types are wider than the values at runtime, and scoped diagnostic disables for the vendored json.lua and the version fallback code that touches apis removed from the current typedefs. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
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.