godotengine/godot
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
244c5ecc64
godot/core/multiplayer/multiplayer_replicator.h

139 lines
6.5 KiB
C++
Raw Normal View History

[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-09 20:46:23 +00:00
/*************************************************************************/
/* multiplayer_replicator.h */
/*************************************************************************/
/* This file is part of: */
/* GODOT ENGINE */
/* https://godotengine.org */
/*************************************************************************/
/* Copyright (c) 2007-2021 Juan Linietsky, Ariel Manzur. */
/* Copyright (c) 2014-2021 Godot Engine contributors (cf. AUTHORS.md). */
/* */
/* Permission is hereby granted, free of charge, to any person obtaining */
/* a copy of this software and associated documentation files (the */
/* "Software"), to deal in the Software without restriction, including */
/* without limitation the rights to use, copy, modify, merge, publish, */
/* distribute, sublicense, and/or sell copies of the Software, and to */
/* permit persons to whom the Software is furnished to do so, subject to */
/* the following conditions: */
/* */
/* The above copyright notice and this permission notice shall be */
/* included in all copies or substantial portions of the Software. */
/* */
/* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, */
/* EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF */
/* MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.*/
/* IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY */
/* CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, */
/* TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE */
/* SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. */
/*************************************************************************/
#ifndef MULTIPLAYER_REPLICATOR_H
#define MULTIPLAYER_REPLICATOR_H
[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-03 17:40:47 +00:00
#include "core/multiplayer/multiplayer_api.h"
Data structure optimizations as per review.
2021-08-26 12:35:33 +00:00
[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-03 17:40:47 +00:00
#include "core/io/resource_uid.h"
Data structure optimizations as per review.
2021-08-26 12:35:33 +00:00
#include "core/templates/hash_map.h"
[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-09 20:46:23 +00:00
#include "core/variant/typed_array.h"
class MultiplayerReplicator : public Object {
GDCLASS(MultiplayerReplicator, Object);
public:
enum {
SPAWN_CMD_OFFSET = 9,
[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-12 19:07:44 +00:00
SYNC_CMD_OFFSET = 9,
[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-09 20:46:23 +00:00
};
enum ReplicationMode {
REPLICATION_MODE_NONE,
REPLICATION_MODE_SERVER,
REPLICATION_MODE_CUSTOM,
};
struct SceneConfig {
ReplicationMode mode;
[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-12 19:07:44 +00:00
uint64_t sync_interval = 0;
uint64_t sync_last = 0;
uint8_t sync_recv = 0;
[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-09 20:46:23 +00:00
List<StringName> properties;
[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-12 19:07:44 +00:00
List<StringName> sync_properties;
[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-09 20:46:23 +00:00
Callable on_spawn_despawn_send;
Callable on_spawn_despawn_receive;
[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-12 19:07:44 +00:00
Callable on_sync_send;
Callable on_sync_receive;
[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-09 20:46:23 +00:00
};
protected:
static void _bind_methods();
private:
[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-03 17:40:47 +00:00
enum {
BYTE_OR_ZERO_SHIFT = MultiplayerAPI::CMD_FLAG_0_SHIFT,
};
enum {
BYTE_OR_ZERO_FLAG = 1 << BYTE_OR_ZERO_SHIFT,
};
[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-09 20:46:23 +00:00
MultiplayerAPI *multiplayer = nullptr;
Vector<uint8_t> packet_cache;
Map<ResourceUID::ID, SceneConfig> replications;
Map<ObjectID, ResourceUID::ID> replicated_nodes;
Data structure optimizations as per review.
2021-08-26 12:35:33 +00:00
HashMap<ResourceUID::ID, List<ObjectID>> tracked_objects;
[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-09 20:46:23 +00:00
[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-12 19:07:44 +00:00
// Encoding
Error _get_state(const List<StringName> &p_properties, const Object *p_obj, List<Variant> &r_variant);
[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-09 20:46:23 +00:00
Error _encode_state(const List<Variant> &p_variants, uint8_t *p_buffer, int &r_len, bool *r_raw = nullptr);
Error _decode_state(const List<StringName> &p_cfg, Object *p_obj, const uint8_t *p_buffer, int p_len, int &r_len, bool p_raw = false);
[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-12 19:07:44 +00:00
// Spawn
[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-09 20:46:23 +00:00
Error _spawn_despawn(ResourceUID::ID p_scene_id, Object *p_obj, int p_peer, bool p_spawn);
Error _send_spawn_despawn(int p_peer_id, const ResourceUID::ID &p_scene_id, const Variant &p_data, bool p_spawn);
void _process_default_spawn_despawn(int p_from, const ResourceUID::ID &p_scene_id, const uint8_t *p_packet, int p_packet_len, bool p_spawn);
Error _send_default_spawn_despawn(int p_peer_id, const ResourceUID::ID &p_scene_id, Object *p_obj, const NodePath &p_path, bool p_spawn);
[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-12 19:07:44 +00:00
// Sync
void _process_default_sync(const ResourceUID::ID &p_id, const uint8_t *p_packet, int p_packet_len);
Error _sync_all_default(const ResourceUID::ID &p_scene_id, int p_peer);
void _track(const ResourceUID::ID &p_scene_id, Object *p_object);
void _untrack(const ResourceUID::ID &p_scene_id, Object *p_object);
[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-09 20:46:23 +00:00
public:
void clear();
[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-12 19:07:44 +00:00
// Encoding
PackedByteArray encode_state(const ResourceUID::ID &p_scene_id, const Object *p_node, bool p_initial);
Error decode_state(const ResourceUID::ID &p_scene_id, Object *p_node, PackedByteArray p_data, bool p_initial);
// Spawn
[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-09 20:46:23 +00:00
Error spawn_config(const ResourceUID::ID &p_id, ReplicationMode p_mode, const TypedArray<StringName> &p_props = TypedArray<StringName>(), const Callable &p_on_send = Callable(), const Callable &p_on_recv = Callable());
Error spawn(ResourceUID::ID p_scene_id, Object *p_obj, int p_peer = 0);
Error despawn(ResourceUID::ID p_scene_id, Object *p_obj, int p_peer = 0);
Error send_despawn(int p_peer_id, const ResourceUID::ID &p_scene_id, const Variant &p_data = Variant(), const NodePath &p_path = NodePath());
Error send_spawn(int p_peer_id, const ResourceUID::ID &p_scene_id, const Variant &p_data = Variant(), const NodePath &p_path = NodePath());
[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-12 19:07:44 +00:00
// Sync
Error sync_config(const ResourceUID::ID &p_id, uint64_t p_interval, const TypedArray<StringName> &p_props = TypedArray<StringName>(), const Callable &p_on_send = Callable(), const Callable &p_on_recv = Callable());
Error sync_all(const ResourceUID::ID &p_scene_id, int p_peer);
[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-03 17:40:47 +00:00
Error send_sync(int p_peer_id, const ResourceUID::ID &p_scene_id, PackedByteArray p_data, Multiplayer::TransferMode p_mode, int p_channel);
[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-12 19:07:44 +00:00
void track(const ResourceUID::ID &p_scene_id, Object *p_object);
void untrack(const ResourceUID::ID &p_scene_id, Object *p_object);
[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-09 20:46:23 +00:00
// Used by MultiplayerAPI
void spawn_all(int p_peer);
void process_spawn_despawn(int p_from, const uint8_t *p_packet, int p_packet_len, bool p_spawn);
[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-12 19:07:44 +00:00
void process_sync(int p_from, const uint8_t *p_packet, int p_packet_len);
[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-09 20:46:23 +00:00
void scene_enter_exit_notify(const String &p_scene, Node *p_node, bool p_enter);
[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-12 19:07:44 +00:00
void poll();
[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-09 20:46:23 +00:00
MultiplayerReplicator(MultiplayerAPI *p_multiplayer) {
multiplayer = p_multiplayer;
}
};
VARIANT_ENUM_CAST(MultiplayerReplicator::ReplicationMode);
#endif // MULTIPLAYER_REPLICATOR_H
Reference in New Issue Copy Permalink