We don't use that info for anything, and it generates unnecessary diffs
every time we bump the minor version (and CI failures if we forget to
sync some files from opt-in modules (mono, text_server_fb).
- RPC configurations are now dictionaries.
- Script.get_rpc_methods renamed to Script.get_rpc_config.
- Node.rpc[_id] and Callable.rpc now return an Error.
- Refactor MultiplayerAPI to allow extension.
- New MultiplayerAPI.rpc method with Array argument (for scripts).
- Move the default MultiplayerAPI implementation to a module.
Removes custom_multiplayer from Node.
MultiplayerAPI overrides are now set at SceneTree level, and apply to
whole branches.
Impact on performance when using only the default multiplayer or
overriding it is minimal, the use of branches can likely be further
optimized by caching nodes and relevant MultiplayerAPI IDs.
This makes it easier to spot syntax errors when editing the
class reference. The schema is referenced locally so validation
can still work offline.
Each class XML's schema conformance is also checked on GitHub Actions.
Now uses two interfaces so it can be overridden in the future, and
core no longer depends on Node.
The interfaces are implements in scene/multiplayer.
Replaces root_node with root_path.
Remove all Node references from MultiplayerAPI.
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.
Removes _networking_ prefix from some methods and members, now that multiplayer has been largely moved out of Node and SceneTree and is seperated into its own set of classes.
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".
This commit completely removes the RPC_MODE_MASTER ("master" keyword),
and renames the RPC_MODE_PUPPET to RPC_MODE_AUTHORITY ("auth" keyword).
This commit also renames the "Node.[get|set]_network_master" methods to
"Node.[get|set]_network_authority".
This commit also renames the RPC_MODE_REMOTE constant to RPC_MODE_ANY.
RPC_MODE_MASTER in Godot 3.x meant that a given RPC would be callable by
any puppet peer on the master, while RPC_MODE_PUPPET meant that it would
be callable by the master on any puppet.
Beside proving to be very confusing to the user (referring to where it
could be called instead of who can call it) the RPC_MODE_MASTER is quite
useless. It is almost the same as RPC_MODE_REMOTE (anyone can call) with
the exception that the network master cannot. While this could be useful
to check in some case, in such a function you would anyway need to check
in code who is the caller via get_rpc_sender_id(), so adding the check
there for those rare cases does not warrants a dedicated mode.
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.
`PackedScene`s can be configured to be spawnable via a new
`MultiplayerAPI.spawnable_config` method.
They can be configured either to be spawned automatically when coming
from the server or to always require verification.
Another method, `MultiplayerAPI.send_spawn` lets you request a spawn on
the remote peers.
When a peer receive a spawn request:
- If it comes from the server and the scene is configured as
`SPAWN_MODE_SERVER`:
- Spawn the scene (instantiate it, add it to tree).
- Emit signal `network_spawn`.
- Else:
- Emit signal `network_spawn_request`.
In a similar way, `despawn`s are handled automatically in
`SPAWN_MODE_SERVER`.
In `SPAWN_MODE_SERVER`, when a new client connects it will also receive,
from the server all the spawned (and not yet despawned) instances.
For the time being we don't support writing a description for those, preferring
having all details in the method's description.
Using self-closing tags saves half the lines, and prevents contributors from
thinking that they should write the argument or return documentation there.
Rémi Verschelde
Hugo Locurcio
Micky
Andrés Botero
Danil Alexeev
Andy Maloney
Yuri Sizov
Fabio Alessandrelli
Aaron Franke
Max Hilbrunner