Cooldude2606andClaude Fable 5.1
a80b035a0a
* Send only recipe notification changes on inventory download Lua includes its current cleared recipe list in the download request. The instance plugin diffs it against the stored list and sends back the names to add and remove instead of the full list. Lua rebuilds the full list from the snapshot kept in the download record and runs the existing deserializer, so the end state is unchanged. Also stop the serializer from appending to the stored failed recipe list in place, which grew the list on every upload without a download in between. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * Test the inventory sync download handler Covers the empty response, the full list without a snapshot, the delta with a snapshot, and the IPC registration. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * Apply recipe notification deltas directly in Lua Review feedback: the download field now always carries the delta and the deserializer applies it against the current state instead of rebuilding the full list first. The previous failed recipe names are passed in so they survive the round trip. The version check moved to the call site. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * Fix failed not being cleared * Send only the local state on download init The current state sent with the download request no longer includes the failed names from the previous deserialization. Stored names unknown on this instance always end up in the add list, so the deserializer recomputes the failed list from that on every download and needs no previous state. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * Convert inventory sync test to ES module Master migrated to ESM after this branch was created, so the CommonJS test failed to load on the merge commit. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com> Co-authored-by: Cooldude2606 <25043174+Cooldude2606@users.noreply.github.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, including its current recipe notification state.
-
Controller sends it to the scenario in a stream of chunks, with only the recipe notifications that differ from the current state.
-
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.