asgardius/virtualx-engine
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
virtualx-engine/modules/multiplayer/doc_classes/MultiplayerSynchronizer.xml

105 lines
5.8 KiB
XML
Raw Normal View History

[Net] New replication interface, spawner and synchronizer nodes. Initial implementation of the MultiplayerReplicationInterface and its default implementation (SceneReplicationInterface). New MultiplayerSpawner node helps dealing with instantiation of scenes on remote peers (e.g. clients). It supports both custom spawns via a `_spawn_custom` virtual function, and optional auto-spawn of known scenes via a TypedArray<PackedScenes> property. New MultiplayerSynchornizer helps synchronizing states between the local and remote peers, supports both sync and spawn properties and is configured via a `SceneReplicationConfig` resource. It can also sync via path (i.e. without being spawned by a MultiplayerSpawner if both peers has it in tree, but will not send the spawn state in that case, only the sync one.
2021-10-08 14:13:06 +02:00
<?xml version="1.0" encoding="UTF-8" ?>
Add keywords to improve search in the class reference
2024-02-21 18:51:08 +01:00
<class name="MultiplayerSynchronizer" inherits="Node" keywords="network" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="../../../doc/class.xsd">
[Net] New replication interface, spawner and synchronizer nodes. Initial implementation of the MultiplayerReplicationInterface and its default implementation (SceneReplicationInterface). New MultiplayerSpawner node helps dealing with instantiation of scenes on remote peers (e.g. clients). It supports both custom spawns via a `_spawn_custom` virtual function, and optional auto-spawn of known scenes via a TypedArray<PackedScenes> property. New MultiplayerSynchornizer helps synchronizing states between the local and remote peers, supports both sync and spawn properties and is configured via a `SceneReplicationConfig` resource. It can also sync via path (i.e. without being spawned by a MultiplayerSpawner if both peers has it in tree, but will not send the spawn state in that case, only the sync one.
2021-10-08 14:13:06 +02:00
<brief_description>
document multiplayer replication classes, small changes to multiplayer spawner
2022-07-29 01:30:30 +02:00
Synchronizes properties from the multiplayer authority to the remote peers.
[Net] New replication interface, spawner and synchronizer nodes. Initial implementation of the MultiplayerReplicationInterface and its default implementation (SceneReplicationInterface). New MultiplayerSpawner node helps dealing with instantiation of scenes on remote peers (e.g. clients). It supports both custom spawns via a `_spawn_custom` virtual function, and optional auto-spawn of known scenes via a TypedArray<PackedScenes> property. New MultiplayerSynchornizer helps synchronizing states between the local and remote peers, supports both sync and spawn properties and is configured via a `SceneReplicationConfig` resource. It can also sync via path (i.e. without being spawned by a MultiplayerSpawner if both peers has it in tree, but will not send the spawn state in that case, only the sync one.
2021-10-08 14:13:06 +02:00
</brief_description>
<description>
document multiplayer replication classes, small changes to multiplayer spawner
2022-07-29 01:30:30 +02:00
By default, [MultiplayerSynchronizer] synchronizes configured properties to all peers.
Fix typos with codespell Using codespell 2.3-dev from current git. And fix typo in `methods.py` for `vsproj=yes` option (still won't work though).
2022-09-30 14:23:36 +02:00
Visibility can be handled directly with [method set_visibility_for] or as-needed with [method add_visibility_filter] and [method update_visibility].
document multiplayer replication classes, small changes to multiplayer spawner
2022-07-29 01:30:30 +02:00
[MultiplayerSpawner]s will handle nodes according to visibility of synchronizers as long as the node at [member root_path] was spawned by one.
Internally, [MultiplayerSynchronizer] uses [method MultiplayerAPI.object_configuration_add] to notify synchronization start passing the [Node] at [member root_path] as the [code]object[/code] and itself as the [code]configuration[/code], and uses [method MultiplayerAPI.object_configuration_remove] to notify synchronization end in a similar way.
Add restrictions to MultiplayerSynchronizer editor and documentation
2023-03-04 11:37:02 +01:00
[b]Note:[/b] Synchronization is not supported for [Object] type properties, like [Resource]. Properties that are unique to each peer, like the instance IDs of [Object]s (see [method Object.get_instance_id]) or [RID]s, will also not work in synchronization.
[Net] New replication interface, spawner and synchronizer nodes. Initial implementation of the MultiplayerReplicationInterface and its default implementation (SceneReplicationInterface). New MultiplayerSpawner node helps dealing with instantiation of scenes on remote peers (e.g. clients). It supports both custom spawns via a `_spawn_custom` virtual function, and optional auto-spawn of known scenes via a TypedArray<PackedScenes> property. New MultiplayerSynchornizer helps synchronizing states between the local and remote peers, supports both sync and spawn properties and is configured via a `SceneReplicationConfig` resource. It can also sync via path (i.e. without being spawned by a MultiplayerSpawner if both peers has it in tree, but will not send the spawn state in that case, only the sync one.
2021-10-08 14:13:06 +02:00
</description>
<tutorials>
</tutorials>
Add peer visibility to MultiplayerSynchronizer. MultiplayerSynchronizers can now be configured to limit their visibility to a subset of the connected peers, if the synchronized node was spawned by a MultiplayerSpawner (either automatically or via custom spawn) the given node will also be despawned remotely. The replication system doesn't have the logic to handle subspawn directly, but it is possible to handle them appropriately by manually updating the visibility of the parent before changing the one of the nested spawns via the "update_visibility" function. The visibility of each MultiplayerSynchronizer can be controlled by adding or remove filters via "[add|remove]_visibility_filter(callable)". To further optimize the network code, visibility filters can be configured to be automatically updated during idle or physics frame, or set to always require manual update (via the "update_visibility" function).
2022-07-09 20:45:30 +02:00
<methods>
<method name="add_visibility_filter">
<return type="void" />
Rename the argument tag to param in XML documentation
2022-08-06 20:11:48 +02:00
<param index="0" name="filter" type="Callable" />
Add peer visibility to MultiplayerSynchronizer. MultiplayerSynchronizers can now be configured to limit their visibility to a subset of the connected peers, if the synchronized node was spawned by a MultiplayerSpawner (either automatically or via custom spawn) the given node will also be despawned remotely. The replication system doesn't have the logic to handle subspawn directly, but it is possible to handle them appropriately by manually updating the visibility of the parent before changing the one of the nested spawns via the "update_visibility" function. The visibility of each MultiplayerSynchronizer can be controlled by adding or remove filters via "[add|remove]_visibility_filter(callable)". To further optimize the network code, visibility filters can be configured to be automatically updated during idle or physics frame, or set to always require manual update (via the "update_visibility" function).
2022-07-09 20:45:30 +02:00
<description>
document multiplayer replication classes, small changes to multiplayer spawner
2022-07-29 01:30:30 +02:00
Adds a peer visibility filter for this synchronizer.
Validate code tags in documentation for potential params Adds a check to make_rst to look for matches between the text inside of the [code][/code] tag and known param identifiers. Fixes most of what was revealed.
2023-04-26 21:36:04 +02:00
[param filter] should take a peer ID [int] and return a [bool].
Add peer visibility to MultiplayerSynchronizer. MultiplayerSynchronizers can now be configured to limit their visibility to a subset of the connected peers, if the synchronized node was spawned by a MultiplayerSpawner (either automatically or via custom spawn) the given node will also be despawned remotely. The replication system doesn't have the logic to handle subspawn directly, but it is possible to handle them appropriately by manually updating the visibility of the parent before changing the one of the nested spawns via the "update_visibility" function. The visibility of each MultiplayerSynchronizer can be controlled by adding or remove filters via "[add|remove]_visibility_filter(callable)". To further optimize the network code, visibility filters can be configured to be automatically updated during idle or physics frame, or set to always require manual update (via the "update_visibility" function).
2022-07-09 20:45:30 +02:00
</description>
</method>
<method name="get_visibility_for" qualifiers="const">
<return type="bool" />
Rename the argument tag to param in XML documentation
2022-08-06 20:11:48 +02:00
<param index="0" name="peer" type="int" />
Add peer visibility to MultiplayerSynchronizer. MultiplayerSynchronizers can now be configured to limit their visibility to a subset of the connected peers, if the synchronized node was spawned by a MultiplayerSpawner (either automatically or via custom spawn) the given node will also be despawned remotely. The replication system doesn't have the logic to handle subspawn directly, but it is possible to handle them appropriately by manually updating the visibility of the parent before changing the one of the nested spawns via the "update_visibility" function. The visibility of each MultiplayerSynchronizer can be controlled by adding or remove filters via "[add|remove]_visibility_filter(callable)". To further optimize the network code, visibility filters can be configured to be automatically updated during idle or physics frame, or set to always require manual update (via the "update_visibility" function).
2022-07-09 20:45:30 +02:00
<description>
Validate code tags in documentation for potential params Adds a check to make_rst to look for matches between the text inside of the [code][/code] tag and known param identifiers. Fixes most of what was revealed.
2023-04-26 21:36:04 +02:00
Queries the current visibility for peer [param peer].
Add peer visibility to MultiplayerSynchronizer. MultiplayerSynchronizers can now be configured to limit their visibility to a subset of the connected peers, if the synchronized node was spawned by a MultiplayerSpawner (either automatically or via custom spawn) the given node will also be despawned remotely. The replication system doesn't have the logic to handle subspawn directly, but it is possible to handle them appropriately by manually updating the visibility of the parent before changing the one of the nested spawns via the "update_visibility" function. The visibility of each MultiplayerSynchronizer can be controlled by adding or remove filters via "[add|remove]_visibility_filter(callable)". To further optimize the network code, visibility filters can be configured to be automatically updated during idle or physics frame, or set to always require manual update (via the "update_visibility" function).
2022-07-09 20:45:30 +02:00
</description>
</method>
<method name="remove_visibility_filter">
<return type="void" />
Rename the argument tag to param in XML documentation
2022-08-06 20:11:48 +02:00
<param index="0" name="filter" type="Callable" />
Add peer visibility to MultiplayerSynchronizer. MultiplayerSynchronizers can now be configured to limit their visibility to a subset of the connected peers, if the synchronized node was spawned by a MultiplayerSpawner (either automatically or via custom spawn) the given node will also be despawned remotely. The replication system doesn't have the logic to handle subspawn directly, but it is possible to handle them appropriately by manually updating the visibility of the parent before changing the one of the nested spawns via the "update_visibility" function. The visibility of each MultiplayerSynchronizer can be controlled by adding or remove filters via "[add|remove]_visibility_filter(callable)". To further optimize the network code, visibility filters can be configured to be automatically updated during idle or physics frame, or set to always require manual update (via the "update_visibility" function).
2022-07-09 20:45:30 +02:00
<description>
Fix typos with codespell Using codespell 2.3-dev from current git. And fix typo in `methods.py` for `vsproj=yes` option (still won't work though).
2022-09-30 14:23:36 +02:00
Removes a peer visibility filter from this synchronizer.
Add peer visibility to MultiplayerSynchronizer. MultiplayerSynchronizers can now be configured to limit their visibility to a subset of the connected peers, if the synchronized node was spawned by a MultiplayerSpawner (either automatically or via custom spawn) the given node will also be despawned remotely. The replication system doesn't have the logic to handle subspawn directly, but it is possible to handle them appropriately by manually updating the visibility of the parent before changing the one of the nested spawns via the "update_visibility" function. The visibility of each MultiplayerSynchronizer can be controlled by adding or remove filters via "[add|remove]_visibility_filter(callable)". To further optimize the network code, visibility filters can be configured to be automatically updated during idle or physics frame, or set to always require manual update (via the "update_visibility" function).
2022-07-09 20:45:30 +02:00
</description>
</method>
<method name="set_visibility_for">
<return type="void" />
Rename the argument tag to param in XML documentation
2022-08-06 20:11:48 +02:00
<param index="0" name="peer" type="int" />
<param index="1" name="visible" type="bool" />
Add peer visibility to MultiplayerSynchronizer. MultiplayerSynchronizers can now be configured to limit their visibility to a subset of the connected peers, if the synchronized node was spawned by a MultiplayerSpawner (either automatically or via custom spawn) the given node will also be despawned remotely. The replication system doesn't have the logic to handle subspawn directly, but it is possible to handle them appropriately by manually updating the visibility of the parent before changing the one of the nested spawns via the "update_visibility" function. The visibility of each MultiplayerSynchronizer can be controlled by adding or remove filters via "[add|remove]_visibility_filter(callable)". To further optimize the network code, visibility filters can be configured to be automatically updated during idle or physics frame, or set to always require manual update (via the "update_visibility" function).
2022-07-09 20:45:30 +02:00
<description>
Validate code tags in documentation for potential params Adds a check to make_rst to look for matches between the text inside of the [code][/code] tag and known param identifiers. Fixes most of what was revealed.
2023-04-26 21:36:04 +02:00
Sets the visibility of [param peer] to [param visible]. If [param peer] is [code]0[/code], the value of [member public_visibility] will be updated instead.
Add peer visibility to MultiplayerSynchronizer. MultiplayerSynchronizers can now be configured to limit their visibility to a subset of the connected peers, if the synchronized node was spawned by a MultiplayerSpawner (either automatically or via custom spawn) the given node will also be despawned remotely. The replication system doesn't have the logic to handle subspawn directly, but it is possible to handle them appropriately by manually updating the visibility of the parent before changing the one of the nested spawns via the "update_visibility" function. The visibility of each MultiplayerSynchronizer can be controlled by adding or remove filters via "[add|remove]_visibility_filter(callable)". To further optimize the network code, visibility filters can be configured to be automatically updated during idle or physics frame, or set to always require manual update (via the "update_visibility" function).
2022-07-09 20:45:30 +02:00
</description>
</method>
<method name="update_visibility">
<return type="void" />
Rename the argument tag to param in XML documentation
2022-08-06 20:11:48 +02:00
<param index="0" name="for_peer" type="int" default="0" />
Add peer visibility to MultiplayerSynchronizer. MultiplayerSynchronizers can now be configured to limit their visibility to a subset of the connected peers, if the synchronized node was spawned by a MultiplayerSpawner (either automatically or via custom spawn) the given node will also be despawned remotely. The replication system doesn't have the logic to handle subspawn directly, but it is possible to handle them appropriately by manually updating the visibility of the parent before changing the one of the nested spawns via the "update_visibility" function. The visibility of each MultiplayerSynchronizer can be controlled by adding or remove filters via "[add|remove]_visibility_filter(callable)". To further optimize the network code, visibility filters can be configured to be automatically updated during idle or physics frame, or set to always require manual update (via the "update_visibility" function).
2022-07-09 20:45:30 +02:00
<description>
Validate code tags in documentation for potential params Adds a check to make_rst to look for matches between the text inside of the [code][/code] tag and known param identifiers. Fixes most of what was revealed.
2023-04-26 21:36:04 +02:00
Updates the visibility of [param for_peer] according to visibility filters. If [param for_peer] is [code]0[/code] (the default), all peers' visibilties are updated.
Add peer visibility to MultiplayerSynchronizer. MultiplayerSynchronizers can now be configured to limit their visibility to a subset of the connected peers, if the synchronized node was spawned by a MultiplayerSpawner (either automatically or via custom spawn) the given node will also be despawned remotely. The replication system doesn't have the logic to handle subspawn directly, but it is possible to handle them appropriately by manually updating the visibility of the parent before changing the one of the nested spawns via the "update_visibility" function. The visibility of each MultiplayerSynchronizer can be controlled by adding or remove filters via "[add|remove]_visibility_filter(callable)". To further optimize the network code, visibility filters can be configured to be automatically updated during idle or physics frame, or set to always require manual update (via the "update_visibility" function).
2022-07-09 20:45:30 +02:00
</description>
</method>
</methods>
[Net] New replication interface, spawner and synchronizer nodes. Initial implementation of the MultiplayerReplicationInterface and its default implementation (SceneReplicationInterface). New MultiplayerSpawner node helps dealing with instantiation of scenes on remote peers (e.g. clients). It supports both custom spawns via a `_spawn_custom` virtual function, and optional auto-spawn of known scenes via a TypedArray<PackedScenes> property. New MultiplayerSynchornizer helps synchronizing states between the local and remote peers, supports both sync and spawn properties and is configured via a `SceneReplicationConfig` resource. It can also sync via path (i.e. without being spawned by a MultiplayerSpawner if both peers has it in tree, but will not send the spawn state in that case, only the sync one.
2021-10-08 14:13:06 +02:00
<members>
[MP] Implement "watched" properties. Checked at "delta_interval" (default = every frame), synchronized (reliably) if changes are detected.
2023-03-28 09:30:58 +02:00
<member name="delta_interval" type="float" setter="set_delta_interval" getter="get_delta_interval" default="0.0">
Time interval between delta synchronizations. When set to [code]0.0[/code] (the default), delta synchronizations happen every network process frame.
</member>
Add peer visibility to MultiplayerSynchronizer. MultiplayerSynchronizers can now be configured to limit their visibility to a subset of the connected peers, if the synchronized node was spawned by a MultiplayerSpawner (either automatically or via custom spawn) the given node will also be despawned remotely. The replication system doesn't have the logic to handle subspawn directly, but it is possible to handle them appropriately by manually updating the visibility of the parent before changing the one of the nested spawns via the "update_visibility" function. The visibility of each MultiplayerSynchronizer can be controlled by adding or remove filters via "[add|remove]_visibility_filter(callable)". To further optimize the network code, visibility filters can be configured to be automatically updated during idle or physics frame, or set to always require manual update (via the "update_visibility" function).
2022-07-09 20:45:30 +02:00
<member name="public_visibility" type="bool" setter="set_visibility_public" getter="is_visibility_public" default="true">
document multiplayer replication classes, small changes to multiplayer spawner
2022-07-29 01:30:30 +02:00
Whether synchronization should be visible to all peers by default. See [method set_visibility_for] and [method add_visibility_filter] for ways of configuring fine-grained visibility options.
Add peer visibility to MultiplayerSynchronizer. MultiplayerSynchronizers can now be configured to limit their visibility to a subset of the connected peers, if the synchronized node was spawned by a MultiplayerSpawner (either automatically or via custom spawn) the given node will also be despawned remotely. The replication system doesn't have the logic to handle subspawn directly, but it is possible to handle them appropriately by manually updating the visibility of the parent before changing the one of the nested spawns via the "update_visibility" function. The visibility of each MultiplayerSynchronizer can be controlled by adding or remove filters via "[add|remove]_visibility_filter(callable)". To further optimize the network code, visibility filters can be configured to be automatically updated during idle or physics frame, or set to always require manual update (via the "update_visibility" function).
2022-07-09 20:45:30 +02:00
</member>
rename 'configuration' to 'replication_config' in MultiplayerSynchronizer
2022-05-24 08:31:44 +02:00
<member name="replication_config" type="SceneReplicationConfig" setter="set_replication_config" getter="get_replication_config">
document multiplayer replication classes, small changes to multiplayer spawner
2022-07-29 01:30:30 +02:00
Resource containing which properties to synchronize.
[Net] New replication interface, spawner and synchronizer nodes. Initial implementation of the MultiplayerReplicationInterface and its default implementation (SceneReplicationInterface). New MultiplayerSpawner node helps dealing with instantiation of scenes on remote peers (e.g. clients). It supports both custom spawns via a `_spawn_custom` virtual function, and optional auto-spawn of known scenes via a TypedArray<PackedScenes> property. New MultiplayerSynchornizer helps synchronizing states between the local and remote peers, supports both sync and spawn properties and is configured via a `SceneReplicationConfig` resource. It can also sync via path (i.e. without being spawned by a MultiplayerSpawner if both peers has it in tree, but will not send the spawn state in that case, only the sync one.
2021-10-08 14:13:06 +02:00
</member>
Improve MultiplayerSynchronizer editor usability * Add a button to add properties (which lets you select node and property) * Add ability to drag properties and drop them to the editor. * Made the editor transient (not always visible on the bottom) since its not needed most of the time. * Added the ability to pin the editor, in case dragging properties from other nodes is desired.
2022-05-23 02:24:14 +02:00
<member name="replication_interval" type="float" setter="set_replication_interval" getter="get_replication_interval" default="0.0">
[MP] Implement "watched" properties. Checked at "delta_interval" (default = every frame), synchronized (reliably) if changes are detected.
2023-03-28 09:30:58 +02:00
Time interval between synchronizations. When set to [code]0.0[/code] (the default), synchronizations happen every network process frame.
[Net] New replication interface, spawner and synchronizer nodes. Initial implementation of the MultiplayerReplicationInterface and its default implementation (SceneReplicationInterface). New MultiplayerSpawner node helps dealing with instantiation of scenes on remote peers (e.g. clients). It supports both custom spawns via a `_spawn_custom` virtual function, and optional auto-spawn of known scenes via a TypedArray<PackedScenes> property. New MultiplayerSynchornizer helps synchronizing states between the local and remote peers, supports both sync and spawn properties and is configured via a `SceneReplicationConfig` resource. It can also sync via path (i.e. without being spawned by a MultiplayerSpawner if both peers has it in tree, but will not send the spawn state in that case, only the sync one.
2021-10-08 14:13:06 +02:00
</member>
Improve MultiplayerSynchronizer editor usability * Add a button to add properties (which lets you select node and property) * Add ability to drag properties and drop them to the editor. * Made the editor transient (not always visible on the bottom) since its not needed most of the time. * Added the ability to pin the editor, in case dragging properties from other nodes is desired.
2022-05-23 02:24:14 +02:00
<member name="root_path" type="NodePath" setter="set_root_path" getter="get_root_path" default="NodePath(&quot;..&quot;)">
document multiplayer replication classes, small changes to multiplayer spawner
2022-07-29 01:30:30 +02:00
Node path that replicated properties are relative to.
If [member root_path] was spawned by a [MultiplayerSpawner], the node will be also be spawned and despawned based on this synchronizer visibility options.
[Net] New replication interface, spawner and synchronizer nodes. Initial implementation of the MultiplayerReplicationInterface and its default implementation (SceneReplicationInterface). New MultiplayerSpawner node helps dealing with instantiation of scenes on remote peers (e.g. clients). It supports both custom spawns via a `_spawn_custom` virtual function, and optional auto-spawn of known scenes via a TypedArray<PackedScenes> property. New MultiplayerSynchornizer helps synchronizing states between the local and remote peers, supports both sync and spawn properties and is configured via a `SceneReplicationConfig` resource. It can also sync via path (i.e. without being spawned by a MultiplayerSpawner if both peers has it in tree, but will not send the spawn state in that case, only the sync one.
2021-10-08 14:13:06 +02:00
</member>
Add peer visibility to MultiplayerSynchronizer. MultiplayerSynchronizers can now be configured to limit their visibility to a subset of the connected peers, if the synchronized node was spawned by a MultiplayerSpawner (either automatically or via custom spawn) the given node will also be despawned remotely. The replication system doesn't have the logic to handle subspawn directly, but it is possible to handle them appropriately by manually updating the visibility of the parent before changing the one of the nested spawns via the "update_visibility" function. The visibility of each MultiplayerSynchronizer can be controlled by adding or remove filters via "[add|remove]_visibility_filter(callable)". To further optimize the network code, visibility filters can be configured to be automatically updated during idle or physics frame, or set to always require manual update (via the "update_visibility" function).
2022-07-09 20:45:30 +02:00
<member name="visibility_update_mode" type="int" setter="set_visibility_update_mode" getter="get_visibility_update_mode" enum="MultiplayerSynchronizer.VisibilityUpdateMode" default="0">
document multiplayer replication classes, small changes to multiplayer spawner
2022-07-29 01:30:30 +02:00
Specifies when visibility filters are updated (see [enum VisibilityUpdateMode] for options).
Add peer visibility to MultiplayerSynchronizer. MultiplayerSynchronizers can now be configured to limit their visibility to a subset of the connected peers, if the synchronized node was spawned by a MultiplayerSpawner (either automatically or via custom spawn) the given node will also be despawned remotely. The replication system doesn't have the logic to handle subspawn directly, but it is possible to handle them appropriately by manually updating the visibility of the parent before changing the one of the nested spawns via the "update_visibility" function. The visibility of each MultiplayerSynchronizer can be controlled by adding or remove filters via "[add|remove]_visibility_filter(callable)". To further optimize the network code, visibility filters can be configured to be automatically updated during idle or physics frame, or set to always require manual update (via the "update_visibility" function).
2022-07-09 20:45:30 +02:00
</member>
[Net] New replication interface, spawner and synchronizer nodes. Initial implementation of the MultiplayerReplicationInterface and its default implementation (SceneReplicationInterface). New MultiplayerSpawner node helps dealing with instantiation of scenes on remote peers (e.g. clients). It supports both custom spawns via a `_spawn_custom` virtual function, and optional auto-spawn of known scenes via a TypedArray<PackedScenes> property. New MultiplayerSynchornizer helps synchronizing states between the local and remote peers, supports both sync and spawn properties and is configured via a `SceneReplicationConfig` resource. It can also sync via path (i.e. without being spawned by a MultiplayerSpawner if both peers has it in tree, but will not send the spawn state in that case, only the sync one.
2021-10-08 14:13:06 +02:00
</members>
Add peer visibility to MultiplayerSynchronizer. MultiplayerSynchronizers can now be configured to limit their visibility to a subset of the connected peers, if the synchronized node was spawned by a MultiplayerSpawner (either automatically or via custom spawn) the given node will also be despawned remotely. The replication system doesn't have the logic to handle subspawn directly, but it is possible to handle them appropriately by manually updating the visibility of the parent before changing the one of the nested spawns via the "update_visibility" function. The visibility of each MultiplayerSynchronizer can be controlled by adding or remove filters via "[add|remove]_visibility_filter(callable)". To further optimize the network code, visibility filters can be configured to be automatically updated during idle or physics frame, or set to always require manual update (via the "update_visibility" function).
2022-07-09 20:45:30 +02:00
<signals>
[MP] Implement "watched" properties. Checked at "delta_interval" (default = every frame), synchronized (reliably) if changes are detected.
2023-03-28 09:30:58 +02:00
<signal name="delta_synchronized">
<description>
Emitted when a new delta synchronization state is received by this synchronizer after the properties have been updated.
</description>
</signal>
[MP] Add a "synchronized" signal to MultiplayerSynchronized. Emitted upon receiving a valid sync packet after setting the variables state.
2023-02-20 14:46:39 +01:00
<signal name="synchronized">
<description>
[MP] Implement "watched" properties. Checked at "delta_interval" (default = every frame), synchronized (reliably) if changes are detected.
2023-03-28 09:30:58 +02:00
Emitted when a new synchronization state is received by this synchronizer after the properties have been updated.
[MP] Add a "synchronized" signal to MultiplayerSynchronized. Emitted upon receiving a valid sync packet after setting the variables state.
2023-02-20 14:46:39 +01:00
</description>
</signal>
Add peer visibility to MultiplayerSynchronizer. MultiplayerSynchronizers can now be configured to limit their visibility to a subset of the connected peers, if the synchronized node was spawned by a MultiplayerSpawner (either automatically or via custom spawn) the given node will also be despawned remotely. The replication system doesn't have the logic to handle subspawn directly, but it is possible to handle them appropriately by manually updating the visibility of the parent before changing the one of the nested spawns via the "update_visibility" function. The visibility of each MultiplayerSynchronizer can be controlled by adding or remove filters via "[add|remove]_visibility_filter(callable)". To further optimize the network code, visibility filters can be configured to be automatically updated during idle or physics frame, or set to always require manual update (via the "update_visibility" function).
2022-07-09 20:45:30 +02:00
<signal name="visibility_changed">
Rename the argument tag to param in XML documentation
2022-08-06 20:11:48 +02:00
<param index="0" name="for_peer" type="int" />
Add peer visibility to MultiplayerSynchronizer. MultiplayerSynchronizers can now be configured to limit their visibility to a subset of the connected peers, if the synchronized node was spawned by a MultiplayerSpawner (either automatically or via custom spawn) the given node will also be despawned remotely. The replication system doesn't have the logic to handle subspawn directly, but it is possible to handle them appropriately by manually updating the visibility of the parent before changing the one of the nested spawns via the "update_visibility" function. The visibility of each MultiplayerSynchronizer can be controlled by adding or remove filters via "[add|remove]_visibility_filter(callable)". To further optimize the network code, visibility filters can be configured to be automatically updated during idle or physics frame, or set to always require manual update (via the "update_visibility" function).
2022-07-09 20:45:30 +02:00
<description>
Validate code tags in documentation for potential params Adds a check to make_rst to look for matches between the text inside of the [code][/code] tag and known param identifiers. Fixes most of what was revealed.
2023-04-26 21:36:04 +02:00
Emitted when visibility of [param for_peer] is updated. See [method update_visibility].
Add peer visibility to MultiplayerSynchronizer. MultiplayerSynchronizers can now be configured to limit their visibility to a subset of the connected peers, if the synchronized node was spawned by a MultiplayerSpawner (either automatically or via custom spawn) the given node will also be despawned remotely. The replication system doesn't have the logic to handle subspawn directly, but it is possible to handle them appropriately by manually updating the visibility of the parent before changing the one of the nested spawns via the "update_visibility" function. The visibility of each MultiplayerSynchronizer can be controlled by adding or remove filters via "[add|remove]_visibility_filter(callable)". To further optimize the network code, visibility filters can be configured to be automatically updated during idle or physics frame, or set to always require manual update (via the "update_visibility" function).
2022-07-09 20:45:30 +02:00
</description>
</signal>
</signals>
<constants>
<constant name="VISIBILITY_PROCESS_IDLE" value="0" enum="VisibilityUpdateMode">
Clarify when things with _IDLE and _PHYSICS enums will run
2023-06-01 01:38:19 +02:00
Visibility filters are updated during process frames (see [constant Node.NOTIFICATION_INTERNAL_PROCESS]).
Add peer visibility to MultiplayerSynchronizer. MultiplayerSynchronizers can now be configured to limit their visibility to a subset of the connected peers, if the synchronized node was spawned by a MultiplayerSpawner (either automatically or via custom spawn) the given node will also be despawned remotely. The replication system doesn't have the logic to handle subspawn directly, but it is possible to handle them appropriately by manually updating the visibility of the parent before changing the one of the nested spawns via the "update_visibility" function. The visibility of each MultiplayerSynchronizer can be controlled by adding or remove filters via "[add|remove]_visibility_filter(callable)". To further optimize the network code, visibility filters can be configured to be automatically updated during idle or physics frame, or set to always require manual update (via the "update_visibility" function).
2022-07-09 20:45:30 +02:00
</constant>
<constant name="VISIBILITY_PROCESS_PHYSICS" value="1" enum="VisibilityUpdateMode">
Clarify when things with _IDLE and _PHYSICS enums will run
2023-06-01 01:38:19 +02:00
Visibility filters are updated during physics frames (see [constant Node.NOTIFICATION_INTERNAL_PHYSICS_PROCESS]).
Add peer visibility to MultiplayerSynchronizer. MultiplayerSynchronizers can now be configured to limit their visibility to a subset of the connected peers, if the synchronized node was spawned by a MultiplayerSpawner (either automatically or via custom spawn) the given node will also be despawned remotely. The replication system doesn't have the logic to handle subspawn directly, but it is possible to handle them appropriately by manually updating the visibility of the parent before changing the one of the nested spawns via the "update_visibility" function. The visibility of each MultiplayerSynchronizer can be controlled by adding or remove filters via "[add|remove]_visibility_filter(callable)". To further optimize the network code, visibility filters can be configured to be automatically updated during idle or physics frame, or set to always require manual update (via the "update_visibility" function).
2022-07-09 20:45:30 +02:00
</constant>
<constant name="VISIBILITY_PROCESS_NONE" value="2" enum="VisibilityUpdateMode">
document multiplayer replication classes, small changes to multiplayer spawner
2022-07-29 01:30:30 +02:00
Visibility filters are not updated automatically, and must be updated manually by calling [method update_visibility].
Add peer visibility to MultiplayerSynchronizer. MultiplayerSynchronizers can now be configured to limit their visibility to a subset of the connected peers, if the synchronized node was spawned by a MultiplayerSpawner (either automatically or via custom spawn) the given node will also be despawned remotely. The replication system doesn't have the logic to handle subspawn directly, but it is possible to handle them appropriately by manually updating the visibility of the parent before changing the one of the nested spawns via the "update_visibility" function. The visibility of each MultiplayerSynchronizer can be controlled by adding or remove filters via "[add|remove]_visibility_filter(callable)". To further optimize the network code, visibility filters can be configured to be automatically updated during idle or physics frame, or set to always require manual update (via the "update_visibility" function).
2022-07-09 20:45:30 +02:00
</constant>
</constants>
[Net] New replication interface, spawner and synchronizer nodes. Initial implementation of the MultiplayerReplicationInterface and its default implementation (SceneReplicationInterface). New MultiplayerSpawner node helps dealing with instantiation of scenes on remote peers (e.g. clients). It supports both custom spawns via a `_spawn_custom` virtual function, and optional auto-spawn of known scenes via a TypedArray<PackedScenes> property. New MultiplayerSynchornizer helps synchronizing states between the local and remote peers, supports both sync and spawn properties and is configured via a `SceneReplicationConfig` resource. It can also sync via path (i.e. without being spawned by a MultiplayerSpawner if both peers has it in tree, but will not send the spawn state in that case, only the sync one.
2021-10-08 14:13:06 +02:00
</class>
Reference in a new issue Copy permalink