mirror/godot
2
0
Fork 0
mirror of https://github.com/godotengine/godot.git synced 2024-12-21 10:25:24 +08:00
Code Issues Packages Projects Releases Wiki Activity
b0b30aaf41
godot/doc/classes/MultiplayerReplicator.xml

192 lines
12 KiB
XML
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-10 04:46:23 +08:00
<?xml version="1.0" encoding="UTF-8" ?>
<class name="MultiplayerReplicator" inherits="Object" version="4.0">
<brief_description>
</brief_description>
<description>
</description>
<tutorials>
</tutorials>
<methods>
<method name="decode_state">
<return type="int" enum="Error" />
<argument index="0" name="scene_id" type="int" />
<argument index="1" name="object" type="Object" />
<argument index="2" name="data" type="PackedByteArray" />
[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-13 03:07:44 +08:00
<argument index="3" name="initial" type="bool" default="true" />
[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-10 04:46:23 +08:00
<description>
Decode the given [code]data[/code] representing a spawnable state into [code]object[/code] using the configuration associated with the provided [code]scene_id[/code]. This function is called automatically when a client receives a server spawn for a scene with [constant REPLICATION_MODE_SERVER]. See [method spawn_config].
Tip: You may find this function useful in servers when parsing spawn requests from clients, or when implementing your own logic with [constant REPLICATION_MODE_CUSTOM].
</description>
</method>
<method name="despawn">
<return type="int" enum="Error" />
<argument index="0" name="scene_id" type="int" />
<argument index="1" name="object" type="Object" />
<argument index="2" name="peer_id" type="int" default="0" />
<description>
[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-13 03:07:44 +08:00
Request a despawn for the scene identified by [code]scene_id[/code] to the given [code]peer_id[/code]. This will either trigger the default behaviour, or invoke the custom spawn/despawn callables specified in [method spawn_config]. See [method send_despawn] for the default behavior.
[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-10 04:46:23 +08:00
</description>
</method>
<method name="encode_state">
<return type="PackedByteArray" />
<argument index="0" name="scene_id" type="int" />
<argument index="1" name="object" type="Object" />
[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-13 03:07:44 +08:00
<argument index="2" name="initial" type="bool" default="true" />
[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-10 04:46:23 +08:00
<description>
Encode the given [code]object[/code] using the configuration associated with the provided [code]scene_id[/code]. This function is called automatically when the server spawns scenes with [constant REPLICATION_MODE_SERVER]. See [method spawn_config].
Tip: You may find this function useful when requesting spawns from clients to server, or when implementing your own logic with [constant REPLICATION_MODE_CUSTOM].
</description>
</method>
<method name="send_despawn">
<return type="int" enum="Error" />
<argument index="0" name="peer_id" type="int" />
<argument index="1" name="scene_id" type="int" />
<argument index="2" name="data" type="Variant" default="null" />
<argument index="3" name="path" type="NodePath" default="NodePath(&quot;&quot;)" />
<description>
Sends a despawn request for the scene identified by [code]scene_id[/code] to the given [code]peer_id[/code] (see [method MultiplayerPeer.set_target_peer]). If the scene is configured as [constant REPLICATION_MODE_SERVER] (see [method spawn_config]) and the request is sent by the server (see [method MultiplayerAPI.is_network_server]), the receiving peer(s) will automatically queue for deletion the node at [code]path[/code] and emit the signal [signal despawned]. In all other cases no deletion happens, and the signal [signal despawn_requested] is emitted instead.
</description>
</method>
<method name="send_spawn">
<return type="int" enum="Error" />
<argument index="0" name="peer_id" type="int" />
<argument index="1" name="scene_id" type="int" />
<argument index="2" name="data" type="Variant" default="null" />
<argument index="3" name="path" type="NodePath" default="NodePath(&quot;&quot;)" />
<description>
Sends a spawn request for the scene identified by [code]scene_id[/code] to the given [code]peer_id[/code] (see [method MultiplayerPeer.set_target_peer]). If the scene is configured as [constant REPLICATION_MODE_SERVER] (see [method spawn_config]) and the request is sent by the server (see [method MultiplayerAPI.is_network_server]), the receiving peer(s) will automatically instantiate that scene, add it to the [SceneTree] at the given [code]path[/code] and emit the signal [signal spawned]. In all other cases no instantiation happens, and the signal [signal spawn_requested] is emitted instead.
</description>
</method>
[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-13 03:07:44 +08:00
<method name="send_sync">
<return type="int" enum="Error" />
<argument index="0" name="peer_id" type="int" />
<argument index="1" name="scene_id" type="int" />
<argument index="2" name="data" type="PackedByteArray" />
<argument index="3" name="transfer_mode" type="int" enum="MultiplayerPeer.TransferMode" default="2" />
<argument index="4" name="channel" type="int" default="0" />
<description>
Sends a sync request for the instances of the scene identified by [code]scene_id[/code] to the given [code]peer_id[/code] (see [method MultiplayerPeer.set_target_peer]). This function can only be called manually when overriding the send and receive sync functions (see [method sync_config]).
</description>
</method>
[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-10 04:46:23 +08:00
<method name="spawn">
<return type="int" enum="Error" />
<argument index="0" name="scene_id" type="int" />
<argument index="1" name="object" type="Object" />
<argument index="2" name="peer_id" type="int" default="0" />
<description>
[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-13 03:07:44 +08:00
Request a spawn for the scene identified by [code]scene_id[/code] to the given [code]peer_id[/code]. This will either trigger the default behaviour, or invoke the custom spawn/despawn callables specified in [method spawn_config]. See [method send_spawn] for the default behavior.
[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-10 04:46:23 +08:00
</description>
</method>
<method name="spawn_config">
<return type="int" enum="Error" />
<argument index="0" name="scene_id" type="int" />
<argument index="1" name="spawn_mode" type="int" enum="MultiplayerReplicator.ReplicationMode" />
<argument index="2" name="properties" type="StringName[]" default="[]" />
<argument index="3" name="custom_send" type="Callable" />
<argument index="4" name="custom_receive" type="Callable" />
<description>
[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-13 03:07:44 +08:00
Configures the MultiplayerReplicator to track instances of the [PackedScene] identified by [code]scene_id[/code] (see [method ResourceLoader.get_resource_uid]) for the purpose of network replication. When [code]mode[/code] is [constant REPLICATION_MODE_SERVER], the specified [code]properties[/code] will also be replicated to clients during the initial spawn. You can optionally specify a [code]custom_send[/code] and a [code]custom_receive[/code] to override the default behaviour and customize the spawn/despawn proecess.
[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-10 04:46:23 +08:00
Tip: You can use a custom property in the scene main script to return a customly optimized state representation.
</description>
</method>
[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-13 03:07:44 +08:00
<method name="sync_all">
<return type="int" enum="Error" />
<argument index="0" name="scene_id" type="int" />
<argument index="1" name="peer_id" type="int" default="0" />
<description>
Manually request a sync for all the instances of the scene identified by [code]scene_id[/code]. This function will trigger the default sync behaviour, or call your send custom send callable if specified in [method sync_config].
Note: The default implementation only allow syncing from server to clients.
</description>
</method>
<method name="sync_config">
<return type="int" enum="Error" />
<argument index="0" name="scene_id" type="int" />
<argument index="1" name="interval" type="int" />
<argument index="2" name="properties" type="StringName[]" default="[]" />
<argument index="3" name="custom_send" type="Callable" />
<argument index="4" name="custom_receive" type="Callable" />
<description>
Configures the MultiplayerReplicator to sync instances of the [PackedScene] identified by [code]scene_id[/code] (see [method ResourceLoader.get_resource_uid]) for the purpose of network replication at the desired [code]interval[/code] (in milliseconds). The specified [code]properties[/code] will be part of the state sync. You can optionally specify a [code]custom_send[/code] and a [code]custom_receive[/code] to override the default behaviour and customize the syncronization proecess.
Tip: You can use a custom property in the scene main script to return a customly optimized state representation (having a single property that returns a PackedByteArray is higly recommended when dealing with many instances).
</description>
</method>
<method name="track">
<return type="void" />
<argument index="0" name="scene_id" type="int" />
<argument index="1" name="object" type="Object" />
<description>
Track the given [code]object[/code] as an instance of the scene identified by [code]scene_id[/code]. This object will be passed to your custom sync callables (see [method sync_config]). Tracking and untracking is automatic in [constant REPLICATION_MODE_SERVER].
</description>
</method>
<method name="untrack">
<return type="void" />
<argument index="0" name="scene_id" type="int" />
<argument index="1" name="object" type="Object" />
<description>
Untrack the given [code]object[/code]. This object will no longer be passed to your custom sync callables (see [method sync_config]). Tracking and untracking is automatic in [constant REPLICATION_MODE_SERVER].
</description>
</method>
[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-10 04:46:23 +08:00
</methods>
<signals>
<signal name="despawn_requested">
<argument index="0" name="id" type="int" />
<argument index="1" name="scene_id" type="int" />
<argument index="2" name="parent" type="Node" />
<argument index="3" name="name" type="String" />
<argument index="4" name="data" type="PackedByteArray" />
<description>
Emitted when a network despawn request has been received from a client, or for a [PackedScene] that has been configured as [constant REPLICATION_MODE_CUSTOM].
</description>
</signal>
<signal name="despawned">
<argument index="0" name="scene_id" type="int" />
<argument index="1" name="node" type="Node" />
<description>
Emitted on a client before deleting a local Node upon receiving a despawn request from the server.
</description>
</signal>
<signal name="replicated_instance_added">
<argument index="0" name="scene_id" type="int" />
<argument index="1" name="node" type="Node" />
<description>
Emitted when an instance of a [PackedScene] that has been configured for networking enters the [SceneTree]. See [method spawn_config].
</description>
</signal>
<signal name="replicated_instance_removed">
<argument index="0" name="scene_id" type="int" />
<argument index="1" name="node" type="Node" />
<description>
Emitted when an instance of a [PackedScene] that has been configured for networking leaves the [SceneTree]. See [method spawn_config].
</description>
</signal>
<signal name="spawn_requested">
<argument index="0" name="id" type="int" />
<argument index="1" name="scene_id" type="int" />
<argument index="2" name="parent" type="Node" />
<argument index="3" name="name" type="String" />
<argument index="4" name="data" type="PackedByteArray" />
<description>
Emitted when a network spawn request has been received from a client, or for a [PackedScene] that has been configured as [constant REPLICATION_MODE_CUSTOM].
</description>
</signal>
<signal name="spawned">
<argument index="0" name="scene_id" type="int" />
<argument index="1" name="node" type="Node" />
<description>
Emitted on a client after a new Node is instantiated locally and added to the SceneTree upon receiving a spawn request from the server.
</description>
</signal>
</signals>
<constants>
<constant name="REPLICATION_MODE_NONE" value="0" enum="ReplicationMode">
Used with [method spawn_config] to identify a [PackedScene] that should not be replicated.
</constant>
<constant name="REPLICATION_MODE_SERVER" value="1" enum="ReplicationMode">
Used with [method spawn_config] to identify a [PackedScene] that should be automatically replicated from server to clients.
</constant>
<constant name="REPLICATION_MODE_CUSTOM" value="2" enum="ReplicationMode">
Used with [method spawn_config] to identify a [PackedScene] that can be manually replicated among peers.
</constant>
</constants>
</class>
Reference in New Issue Copy Permalink