summaryrefslogtreecommitdiff
path: root/doc/classes/MultiplayerReplicator.xml
AgeCommit message (Collapse)Author
2021-08-18[Net] Add state sync to replicator.Fabio Alessandrelli
Like the spawn/despawn feature, it can be completely overridden with 2 custom callables. The callables will be called with the list of tracked objects. In SERVER mode, objects are automatically tracked, while in CUSTOM mode you can manually track them via `track`/`untrack` (but that's optional). The default sync only happens from server to client, with batch updates, over unreliable channel (but with custom ordering). The default sync will warn you, if your state representation gets too big.
2021-08-18[Net] MultiplayerReplicator with initial state.Fabio Alessandrelli
Move the former "spawnables" functions to a dedicated MultiplayerReplicator class. Support custom overrides in replicator. Spawn/despawn messages can now contain a state. The state can be automatically encoded/decoded by passing the desired object properties to `spawnable_config`. You can use script properties to optimize the state representation. 2 Callables can be also specified to completely override the default implementation for sending and receiving the spawn/despawn event. (9 bytes overhead, and there's room for improvement here). When using a custom implementation `spawn` and `despawn` can be called with any Object, `send_spawn`/`send_despawn` can receive any Variant as a state, and the path is not required. Two new functions, `spawn` and `despawn`, convey the implementation independent method for requesting a spawn/despawn of an Object, while `send_spawn` and `send_despawn` represent the more low-level send event for a Variant to be used by the custom implementations.