Introduce a MultiplayerEntity node for improved identity and authority management

[JoNax97]

Describe the project you are working on

A server-authoritative multiplayer adventure game

Describe the problem or limitation you are having in your project

Multiplayer in Godot has improved greatly in 4.0, with the addition of the MultiplayerSpawner and MultiplayerSynchronizer nodes making it very accessible to set up basic multiplayer functionality.

However, the system currently lacks some high-level management functionality that makes it challenging to create gameplay that requires interaction between multiple entities across a distributed session:

• Nodes lacks a consistent, network-wide identity, making it difficult to reference them in RPCs and synchronize them effectively.
• Authority management is manual and can can get out of sync easily.
• Scene loading does not support multiplayer very well, requiring custom workarounds that are unintuitive and prone to race conditions.

In addition, networking concepts that are core to the idea of a "networked entity" are scattered around:
- Authority is individually set for every Node and not inherited
- Visibility is split between MultiplayerSpawner and MultiplayerSynchronizer

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Introduce a new MultiplayerEntity node that provides built-in network identity and authority handling, and helps support replication across peers.
Add mechanisms to SceneTree/SceneMultiplayer to allow for easy handing of these entities spawning, syncing and referencing across peers.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

New MultiplayerEntity node

• Inherits from Node
• Provides the following API:

Properties

VisibilityUpdateMode visibility_update_mode

Methods

void _network_ready() virtual
int get_network_id()
int get_authority()
bool has_authority()
void set_authority(peer: int)
void request_authority(peer: int)
bool is_visible_to(peer: int)
void add_visibility_filter(filter: Callable)
void remove_visibility_filter(filter: Callable)

Signals

authority_changed(new_authority: int)
authority_request_denied()
visibility_changed(for_peer: int)

Network Identity

Each MultiplayerEntity will have a unique network_id that will be generated by the authority, using MultiplayerPeer.generate_unique_id() and automatically replicated to all other peers. This id will not depend on the node path and will remain the same for the lifetime of the node.

MultiplayerSynchronizer will support syncing properties of type MultiplayerEntity via their network_id. This replaces reliance on fragile node paths or manual synchronization via RPCs.

RPCs will support passing MultiplayerEntity-derived nodes as parameters and will also use the network ids for sending the target of the RPC. This will improve over the current system, in which each peer has a different id for the same node and broadcasts it to all other peers.

Authority Handling

Authority handling will be made more streamlined and less prone to desyncs and misbehavior from the clients:

• Only MultiplayerEntity instances will handle authority. Children of the MultiplayerEntity will always inherit its authority, so there is no need propagate it manually.
• Authority changes are automatically replicated to all clients.
• Authority can only be changed by the server. set_authority will fail if called by a client.

Instead, clients (even the current authority) must request authority transfers using the new request_authority method.
The server can implement it's request handling logic by using a new method in MultiplayerAPI:

void set_authority_request_handler(handler: Callable)`

and passing a method like this:

bool can_take_authority(entity: MultiplayerEntity, int peer)

If the authority request is approved, all clients will receive the authority_changed signal. Else, the client that requested the change will receive the authority_request_denied signal.

Spawning and Scene Integration

There are two ways in which MultiplayerEntity nodes may be introduced into a the scene tree:

1. Spawned via MultiplayerSpawner

• The peer with authority over the spawner will be responsible for assigning a network id. This will be done automatically as long as the root of the spawned scene is a MultiplayerEntity.
• Other peers will receive the network id as part of the spawn command, and automatically assign it.
• The network id cannot be changed by using a custom spawn_command. Even if the client decides to spawn a different scene, the id will remain the same. If the node passed to the spawner via spawn_command is not a MultiplayerEntity, the spawning will fail.

2. Placed manually in Scenes

• Scenes containing static MultiplayerEntity instances (e.g. environment props) will undergo special handling:
  • When exporting a scene, any MultiplayerEntities will be replaced by an InstancePlaceholder.
    • If it's an instanced scene, a reference is stored.
    • If not, the tree branch is extracted and exported to a new .scn file.
  • On the server, placeholders are immediately instantiated and assigned a network_id.
  • The server will send spawn commands to tell the clients which placeholders to instantiate and what their most up-to-date state is (based on the data saved on the placeholder's stored values).
  • If the entity is not visible to a specific client, the spawn command will be omitted. If the visibility changes later, the entity will be spawned at that time.

This mechanism ensures the client does not spawn nodes at incorrect locations, nodes that have been destroyed server-side, or nodes that are not visible to the client.

Scene Loading Support

A new API method will be added to MultiplayerAPI:

void change_scene_to_file(path: String)

This is intended to replace the use of SceneTree for multiplayer game, and will work as follows:

• The server will load the scene as normal. MultiplayerEntity nodes will be loaded from their placeholders and given an id.
• The server will send a load command containing the uid of the scene along with a list of entities to instantiate.
• Clients will send a confirmation to the server upon loading the scene and all placeholders.
• When all clients have loaded the scene, the Server will call a new _network_ready() method on all entities of the loaded scene, and also send a command to all clients players to do the same. Other nodes will not have this virtual method to avoid bloat, but they can still react by listening to a new notification NOTIFICATION_NETWORK_READY
• For late-joining clients, the server will automatically send the load command and _network_ready() will be called immediately.

This will allow for the following:

• Avoids pop-in for instantiated entities
• All clients can rely on entities having a valid id upon startup.
• Late-joining clients will load the correct scene with the correct state.

Visibility

The visibility management responsibility is moved from MultiplayerSynchronizer and its API is simplified: instead of having both filters and individual setters for each peer, only filters are used. This is to make the API simpler (the old behavior can be easily replicated by a filter that checks against a list).
The MultiplayerSynchronizer and MultiplayerSpawner nodes will both consume the visibility information from the Entity to perform their own logic.

Deprecations and Compatibility

• The Node.multiplayer property will be deprecated (not MultiplayerAPI itself).
• Developers must transition to using MultiplayerEntity for authority-aware networking.

Future Considerations

• Debug utilities may be introduced to visualize network ID assignments and authority ownership.
• Potential support for assigning network groups to MultiplayerEntity nodes to manage visibility and interest culling.

If this enhancement will not be used often, can it be worked around with a few lines of script?

The network identity part I think it's not feasible to implement in scripts, specially not in a way that RPCs and MultiplayerSynchronizer can benefit from.

Other parts of this proposal can probably be worked around, but not easily. It would probably require implementing a custom MultiplayerAPIExtension, alongside a custom node type. I think this improvements are general and useful enough to guarantee implementing in core.

Is there a reason why this should be core and not an add-on in the asset library?

See above.

[josefalanga]

I like this. Seems like this high-level approach could be beneficial as a core feature. Handles a lot of concepts that popular networking libraries do, so it's easier to transfer knowledge. I also think this could be implemented as an add-on, but solves many problems that are common to any project that goes beyond basic p2p multiplayer functionality.

In general looks good to me. I'm not a fan of your idea of altering how _ready() works on scene loading, maybe it's better to add another callback, let's say _network_ready() to inform everyone that the scene is loaded. More callbacks like this could be added to represent network wide synchronization changes.

Also set_authority failing on the client would mean as you pointed out that every client needs to request authority to the server, and that could then be handled by a built-in request_authority instead of making everyone write their own RPC. You would respond to the requester with a denial, or replicate to everyone the change.

Parenting changes should also have a way of synchronizing explicitly. You need to keep consistency between server and clients, maybe to the same as with authority, make the players request for parenting changes and have the server confirm or deny it, and replicate it to everyone.

Also, I would keep initial complexity at a minimum. Current approach is easy to pick up and there is value to that. If someone doesn't want to deal with identity or authority, it should be able to do so.

[JoNax97]

@josefalanga thanks for your comment!

I'm not a fan of your idea of altering how _ready() works on scene loading, maybe it's better to add another callback, let's say _network_ready() to inform everyone that the scene is loaded.

I think this is a fair point. My original line of thinking was to avoid adding more complexity and try to avoid single-player and multiplayer code diverging too much. However I recognize this change might be too intrusive.

could then be handled by a built-in request_authority instead of making everyone write their own RPC.

Totally agree on this one!
I've updated my proposal to reflect these changes.

Parenting changes should also have a way of synchronizing explicitly. You need to keep consistency between server and clients.

I'm not sure how I feel about this. Syncing the full tree across peers probably isn’t a good idea, because parts of it are not relevant to multiplayer (for example UI). The internals of MultiplayerEntity scenes can also differ between peers (think different scenes for the local and remote player characters).

Maybe each MultiplayerEntity could replicate its name and its position within a known multiplayer root. We might define this root similarly to how MultiplayerSpawner works, either automatically (e.g., when loading a level via MultiplayerAPI.change_scene_to_file) or manually (by setting a root node on the server that defines the sync boundary).

What do you think?

@Ryan-000 @elementbound I'd love to hear your opinions on this, what do you think doesn't work or could be improved?

[Ryan-000]

TLDR: Instead of reworking how the entire multiplayer API works, the pain points should be addressed and fixed instead.

Network Identity

Each MultiplayerEntity will have a unique network_id that will be generated by the authority, using MultiplayerPeer.generate_unique_id()

MultiplayerPeer.generate_unique_id() is designed for peer IDs in its implementation, so its probably better to use something else to generate unique ids.

MultiplayerSynchronizer will support syncing properties of type MultiplayerEntity via their network_id. This replaces reliance on fragile node paths or manual synchronization via RPCs.

RPCs will support passing MultiplayerEntity-derived nodes as parameters and will also use the network ids for sending the target of the RPC. This will improve over the current system, in which each peer has a different id for the same node and broadcasts it to all other peers.

I know how painful it is to reference nodes over the network both via RPC and via MultiplayerSynchonizers. I think instead of doing this only for MultiplayerEntity-derived nodes, we should multiplayer serialization middleware that allows to automatically serialize/deserialize references to nodes.

So if you pass in a node into an rpc, or use MultiplayerSynchronizer it will convert it to the NodePath or networkid accordingly when sending it to the peers. And on the deserialization it will get the node accordingly. (Maybe later even do it for Resource via resource_path)

Only MultiplayerEntity instances will handle authority. Children of the MultiplayerEntity will always inherit its authority, so there is no need propagate it manually.

In my game each peer has a CharacterBody3D node that they have multiplayer authority on. Under the characters I have a MultiplayerSynchonizer that the server has authority over to send the state to other clients.

So if It's done like this, then you cannot have mixed authority.

When exporting a scene, any MultiplayerEntities will be replaced by an InstancePlaceholder.
If it's an instanced scene, a reference is stored.

InstancePlaceholder and Editable Children are incompatible, but its pretty common for users to want to put down environmental objects and change a little bit of the insides, so this would need to be fixed either in InstancePlaceholder or use another approach.

Also when you use InstancePlaceholder the dependencies of those instances aren't loaded which can cause lag spikes in game once it is time to instantiate them.

If not, the tree branch is extracted and exported to a new .scn file.

I don't think there is any other part of the engine that does automatic saving like this, and it brings a lot of other issues like; does the file get automatically deleted when removed from the scene? Also it would be pretty annoying for the user that once they launch their game, they have to go to a sub-scene to edit the node that were previously in their current scene.

In general the support for static/built-in instances in MultiplayerSpawner is pretty bad, but it can still be worked around. What I do for my game is I unparent the built-in instances and reparent them on the server (to register them for replication), and on the client using SpawnFunction I then return the unparented node so that it "just works". Ideally MultiplayerSpawner should just be fixed to support this instead of users having to code their own solution.

Scene Loading Support
A new API method will be added to MultiplayerAPI:
void change_scene_to_file(path: String)
This is intended to replace the use of SceneTree for multiplayer game

In a SceneTree there can be different MultiplayerAPIs for each branch (see set_multiplayer). This is useful when you want to run a client and server in the same process, or even multiple. So it wouldn't be possible to change the current scene when there are multiple MultiplayerAPI's at play.

I know that there is an issue of loading/instantiation times if there is a big scene that needs to be added, so maybe there can be a feature in MultiplayerSpawner that waits for all peers to load it before actually adding it to the tree instead.

Deprecations and Compatibility
The Node.multiplayer property will be deprecated (not MultiplayerAPI itself).
Developers must transition to using MultiplayerEntity for authority-aware networking.

Look I've been working on a game for a few years now, and I'm pretty sure there are other developers that wouldn't be too thrilled that they would have to refactor their entire game for basically no beneficial reason.

Realistically speaking, this would never be added unless it was done in a non-breaking way.

[elementbound]

I think @Ryan-000 summarized it perfectly. Let me add my own points as well.

In short, I think this proposal would be a huge overhaul that would limit the types of games Godot would support compared to what can be done with it today. I feel like this proposal is geared towards a specific type of game, and would make more sense as an addon or as a template project.

I can see how this proposal is born from multiple pain points, but as @Ryan-000 said, I think it would be better to address those individually and specifically.

---

Nodes lacks a consistent, network-wide identity, making it difficult to reference them in RPCs and synchronize them effectively.

I'm ready to be proven wrong, but I don't see why nodes not having a network-wide ID is an issue. We already have a working system with RPCs, I don't see why that couldn't be extended / reused to send Node references over the wire.

---

• Authority is individually set for every Node and not inherited

set_multiplayer_authority() already has a recursive parameter that is true by default. What's the benefit of forcing inherited authority? Godot would lose support for nested nodes with different authorities. One example where this is needed is with netfox where player nodes are owned by the server, but there's a separate input node owned by the player.

---

New MultiplayerEntity node

I think a network_ready() signal would be useful. I think it might be a bit awkward to implement things on top of this node, since you wouldn't be able to build much logic on top of it - e.g. you can't extend both MultiplayerEntity and CharacterController3D to build a character controller. Instead you would have to either add a CharacterController3D under the MultiplayerEntity and subscribe to its signals ( contrary to what Godot recommends ), or you'd have to implement a script extending MultiplayerEntity whose sole job is to proxy calls downwards.

---

Each MultiplayerEntity will have a unique network_id that will be generated by the authority, using MultiplayerPeer.generate_unique_id() and automatically replicated to all other peers.

Sure, but who would be the authority here? If it's the server, you now don't support mesh setups. If it's a predetermined peer, you now don't support mixed authority. If it's the node's owner, you now rely on something that can be changed at any time, or you could even end up with situations where a node gets an ID before its ownership is set.

As proposed, we could say that only the server is allowed to manage node ownership. Which would lead to the same issue of not supporting mesh setups and mixed authority setups.

Also, in case the ID generation logic is not centralized on a single peer, you know have a lot more complexity to handle for generating IDs that are unique among all peers - past, present, and future.

You could also approach it by hashing or generating random numbers, but the issue is that you'd either have to use large IDs ( 12 or more bytes ), or put a restrictive cap on how many Nodes could have their own ID due to potential collisions.

---

Authority changes are automatically replicated to all clients.

Authority can only be changed by the server. set_authority will fail if called by a client.

Instead, clients (even the current authority) must request authority transfers using the new request_authority method.

I think this sounds simple and approachable on the surface but glances over a lot of complexity.

So let's say client A wants to call an authority-only RPC on node N. Client A owns N, so the call succeeds.

Now client A calls the RPC, then requests the authority to be transferred to client B. If the messages arrive in a different order ( e.g. they are sent on different channels ), the server transmits ownership to client B, then denies A's RPC call.

All right, let's work around this by keeping a history of ownership and timestamping RPC calls. So in this case the server transfers ownership to B, sees an RPC call with an earlier timestamp from A, and permits the RPC call. Keep in mind that timestamping would mean that each peers' clock should be synchronized to eachother, otherwise the timestamps are not very useful - the issues would be similar to trying to schedule an international call where everyone specifies time in their local timezone. Time syncing is not trivial.

Let's take a different case - client B requests ownership, and then calls an RPC. The server first receives the RPC call, which it denies, and then grants the ownership transfer.

So now either client B waits for the ownership transfer to complete ( which it may or may not be aware that it's even happening ), or the server buffers the RPC calls for a bit of time instead of declining them instantly. And even then, the configured waiting time might not be enough depending on network conditions, let alone the complexity in the game code trying to manage the fact that RPCs may or may not go through with the extra delay.

The above workarounds would introduce significant complexity, while not supporting mesh setups or mixed authority.

Also, what happens if I know in advance when I want to transfer authority, and I need it to happen on the right time? The right peer could request the ownership transfer on time, but would have no way to tell when it would actually happen, due to network conditions.

---

This will improve over the current system, in which each peer has a different id for the same node and broadcasts it to all other peers.

Once again, feel free to prove me wrong, but I don't see how this is an issue we need to solve given the wide variety of situations Godot current solution handles.

---

2. Placed manually in Scenes

On the server, placeholders are immediately instantiated and assigned a network_id.

Why not just save a hardcoded network id in the scene?

The server will send spawn commands to tell the clients which placeholders to instantiate and what their most up-to-date state is (based on the data saved on the placeholder's stored values).

I think it would make more sense to use whatever's configured in a MultiplayerSynchronizer - there's usually more @export-ed properties than properties that need to be synchronized.

Also, I think the whole placeholder logic could be simplified by removing the statically placed nodes from the node tree on load - they would still be kept in memory, just not in the node tree. Then the server can add them instantly, clients only add them if the server tells them to.

---

Visibility

MultiplayerSynchronizer and its API is simplified: instead of having both filters and individual setters for each peer, only filters are used. This is to make the API simpler

The API would be "simpler" in the sense that there's less methods, but I don't think it would be "simpler" to have users implement methods just to be able to say "don't send data to peer C".

---

Deprecations and Compatibility

The Node.multiplayer property will be deprecated (not MultiplayerAPI itself).

What's the benefit here? This sounds like a major change.

[JoNax97]

Thanks a lot for your through and very insightful comments! There's quite a bit to unpack here so I'll try to group this in categories. I will sometimes quote both of you since the answers overlap:

General

You now don't support mesh setups.

Please correct me if I'm wrong, but Godot's architecture already doesn't support mesh setups, right? One peer needs to start in server mode (peer id 1). And it has authority over all nodes by default. So I don't think this would be changing the status quo much.

Realistically speaking, this would never be added unless it was done in a non-breaking way.

100% agree with you here. I wrote this proposal with a 'clean slate' mindset, and I will work on adapting it to be compatbility-friendly.

The Node.multiplayer property will be deprecated (not MultiplayerAPI itself).

What's the benefit here? This sounds like a major change.

Actually you're right. I must've left that by mistake after one of the many drafts I made. The current proposal doesn't require that at all.

The only API in Node that would be deprecated is set_multiplayer_authority

Identity

Each MultiplayerEntity will have a unique network_id that will be generated by the authority and automatically replicated to all other peers.
Sure, but who would be the authority here? (...)

It would be the peer that sends the spawn command to the others. If using a MultiplayerSpawner, it's the client that locally spawns the node. If using MultiplayerAPI.change_scene_to_file, it will be the server.

MultiplayerPeer.generate_unique_id() is designed for peer IDs in its implementation, so its probably better to use something else to generate unique ids.

Yeah, this implementation is bound to generate collisions if 2 ids are requested in the same microsecond. I guess the easiest way forward is to simply reuse the node's own instance_id from the peer that creates the object in the first place.

 I don't see why nodes not having a network-wide ID is an issue. We already have a working system with RPCs, I don't see why that couldn't be extended / reused to send Node references over the wire.

You're right that the current RPC system works, but it’s built around matching nodes by path, which can easily break when peers have different scene structures—or if nodes are added/removed dynamically. What I'm aiming for is a model where certain nodes can be reliably referenced across peers, regardless of how their scene trees differ.

MultiplayerSynchronizer will support syncing properties of type MultiplayerEntity via their network_id. This replaces reliance on fragile node paths or manual synchronization via RPCs.

I think instead of doing this only for MultiplayerEntity-derived nodes, we should multiplayer serialization middleware that allows to automatically serialize/deserialize references to nodes.

The current system assumes that any node can just exist independently on each peer, and you can hope their paths line up when sending RPCs. That breaks down fast in more complex setups (e.g., late joins, dynamic loading, or asymmetric scenes for local vs remote players). A network ID gives us a shared reference point that doesn't rely on fragile paths or assumptions about the tree.

This goal in turn requires having a defined, coordinated mechanism for creating and assigning authority to them. The current system assumes that any and all tree nodes can be created independently across peers and then, at some arbitrary point in time, be (hopefully) matched based on their path.

The reality is that only a handful of game-specific entities are usually relevant to peer-to-peer communication, and those in turn make local changes to other nodes. Having an more orderly model for a restricted set of top-level entities (think players, vehicles, items, etc) I think is more scalable.

Authority

In my game each peer has a CharacterBody3D node that they have multiplayer authority on. Under the characters I have a MultiplayerSynchonizer that the server has authority over to send the state to other clients.

So if It's done like this, then you cannot have mixed authority.

set_multiplayer_authority() already has a recursive parameter that is true by default. What's the benefit of forcing inherited authority? Godot would lose support for nested nodes with different authorities.

I can see a few ways to remedy this while improving authority management:

1. Using nested MultiplayerEntity nodes. I think this is kind of awkward as it goes counter the idea of what an entity is meant to be.
2. Having the authority auto-management be opt-out. If disabled on the MultiplayerEntity, the user has full control and responsibility over it, just as today.
3. Letting the other Multiplayer nodes have their own authority, as they are:
   1. not always coupled to an entity
   2. as you said, used as part of a mixed-authority entity setup

I think a combination of 2 and 3 (but only when not a child of an entity) would work best. It will provide users with an easier and more robust way of managing authority for the majority of cases, while allowing advanced users to take control over it.

Authority changes are automatically replicated to all clients.
Authority can only be changed by the server. set_authority will fail if called by a client.
Instead, clients (even the current authority) must request authority transfers using the new request_authority method.>

I think this sounds simple and approachable on the surface but glances over a lot of complexity.

Yes it's true that eventual consistency would have to be solved. However I want to point out that the cases you described are things that happen today when manually syncing authority, So I think it's even more reason to provide a robust solution out of the box instead of leavnig every user to figure it out.

Spawning

InstancePlaceholder and Editable Children are incompatible, but its pretty common for users to want to put down environmental objects and change a little bit of the insides, so this would need to be fixed either in InstancePlaceholder or use another approach.

I did not know this. I will make a note of it in the proposal.

If not, the tree branch is extracted and exported to a new .scn file.
I don't think there is any other part of the engine that does automatic saving like this, and it brings a lot of other issues (...)

I think I worded this part of the proposal poorly, sorry. My idea is not to save a new .tscn file in the user's res:// directory, but instead splitting the exported scene (.scn file in .godot/exported). This would be transparent to the user. They would not see any new files or InstancePlaceholder nodes in their scenes.

In a SceneTree there can be different MultiplayerAPIs for each branch (...) So it wouldn't be possible to change the current scene when there are multiple MultiplayerAPI's at play.

I think it would still be possible by having the MultiplayerAPI load the scene under the its root node. If the default setup is used, it would behave the same as the SceneTree.change_scene methods, but if a different API is set for a branch, only that branch will be affected.

I think a network_ready() signal would be useful. I think it might be a bit awkward to implement things on top of this node, since you wouldn't be able to build much logic on top of it (...)

I don't know what the performance overhead of adding a new _network_ready() method and/or a network_ready signal to Node would be. I completely agree that usability wise it would be the best. My proposition came from trying to be conservative when adding new stuff to core nodes.

On the server, placeholders are immediately instantiated and assigned a network_id.
Why not just save a hardcoded network id in the scene?

Because the same scene can be instantiated multiple times.

 I think the whole placeholder logic could be simplified by removing the statically placed nodes from the node tree on load - they would still be kept in memory, just not in the node tree. Then the server can add them instantly, clients only add them if the server tells them to.

If the PackedScene structure allows for removing them before any callbacks are called, yes I think this is a better idea!

Visibility

MultiplayerSynchronizer and its API is simplified: instead of having both filters and individual setters for each peer, only filters are used. This is to make the API simpler

The API would be "simpler" in the sense that there's less methods, but I don't think it would be "simpler" to have users implement methods just to be able to say "don't send data to peer C".

Fair enough!

I will try to gather all this feedback and update the proposal accordingly as soon as I can. Thanks guys!

[elementbound]

Please correct me if I'm wrong, but Godot's architecture already doesn't support mesh setups, right? One peer needs to start in server mode (peer id 1). And it has authority over all nodes by default.

As far as I'm aware, you are right that the multiplayer authority for each node is 1 by default. However, mesh setups are supported both by ENetMultiplayerPeer and WebRTCMultiplayerPeer.

So I think it's even more reason to provide a robust solution out of the box instead of leavnig every user to figure it out.

Sounds reasonable, though I'm wondering how often do people need to change node ownerships on the go in their multiplayer games. In my opinion, you either need some simple and robust mechanism for syncing ownership changes ( like node IDs for RPCs ), or if that's not possible, a robust solution that needs more high-level systems. The latter might be better off as an addon, at least before being incorporated into core.

On the server, placeholders are immediately instantiated and assigned a network_id.
Why not just save a hardcoded network id in the scene?

Because the same scene can be instantiated multiple times.

That makes sense. I'm still wondering whether we could get away with something like this, e.g. allocate some IDs when spawning and adjust them in the spawned nodes, to avoid the placeholder logic. This is optional though, I don't insist on solving it this way.

[josefalanga]

I think someone already pointed out that this proposal is a mix of some improvements to the existing system (mostly exposing information or APIs) and a complete overhaul of the system. Part of the reason for this is that the current state of things doesn’t allow for a more authoritative or consistent implementation, even as an addon.

I want to take a step back and ask: what is the minimal set of changes that would allow us to develop the overhaul part as an addon? Would stable node IDs (instead of paths) and the ability to expose and set those node IDs be enough? Authority as exists now needs some changes? Something else?

[JoNax97]

I believe the bare minimum that would be needed to implement most of this as an addon would be:

Core

• Allow for overriding the logic of Node.set_multiplayer_authority() (probably via MultiplayerAPIExtension, not sure)

• If the InstancePlaceholdder approach is to be used for spawning scene entities, then this needs to be fixed:

InstancePlaceholder and Editable Children are incompatible, but its pretty common for users to want to put down environmental objects and change a little bit of the insides.

But I think I need to investigate the feasibility of stripping the entities from the (paacked) scene before adding it to the tree. If that works it's a considerably simpler approach.

MultiplayerAPIExtension

• Add a way to process both rpc sending and receiving. So basically replace the existing func _rpc(...) with something like this

func _rpc_send(peers: Array[int], object: Object, method: StringName, args: Array) -> Error
func _rpc_receive(object: Object, method: StringName, args: Array) -> void

• Expose network_id (in progress in Expose node network IDs to GDScript godot#105217)

 func get_network_id(node: Node) -> int
 func instance_from_netowrk_id(id: int) -> Node

Use the same network_id to allow syncing nodes with MultiplayerSynchronizer

A new netowrk_id mechanism will also need to be implemented in core but I don't think is strictly necessary, the high level functionality can start being worked on with the current one.

I'm probably missing some things but those are the ones that come to mind right now.