Commit graph

5 commits

Author SHA1 Message Date
Fabio Alessandrelli
bf9aae09ba [Net] Move multiplayer to core subdir, split RPCManager.
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-09-07 11:14:30 +02:00
SaracenOne
f09f12ce55 Fix _send_default_spawn_default function sending zero length
PackedByteArray when deriving from a single PackedByteArray
state variant.
2021-09-02 21:36:54 +01:00
Fabio Alessandrelli
2d2855cd53 Data structure optimizations as per review. 2021-08-26 13:35:33 +01:00
Fabio Alessandrelli
b05cb0fd7d [Net] Add state sync to replicator.
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 12:37:45 +01:00
Fabio Alessandrelli
d4dd859991 [Net] MultiplayerReplicator with initial state.
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.
2021-08-18 10:21:29 +01:00