summaryrefslogtreecommitdiff
path: root/doc/classes/MultiplayerReplicator.xml
AgeCommit message (Collapse)Author
2021-10-05doc: Fix style inconsistencies for `[b]Note:[/b]` paragraphsRĂ©mi Verschelde
And fix up formatting not supported by makerst.
2021-09-08Multiplayer networking renames/simplificationMax Hilbrunner
Removes _networking_ prefix from some methods and members, now that multiplayer has been largely moved out of Node and SceneTree and is seperated into its own set of classes.
2021-09-07[Net] Move multiplayer to core subdir, split RPCManager.Fabio Alessandrelli
Move multiplayer classes to "core/multiplayer" subdir. Move the RPCConfig and enums (TransferMode, RPCMode) to a separate file (multiplayer.h), and bind them to the global namespace. Move the RPC handling code to its own class (RPCManager). Renames "get_rpc_sender_id" to "get_remote_sender_id".
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.