godotengine / godotengine/godot

RPC doesn't correctly reach node according to node path after rename

Open
#116,222 0 comments 0 reactions 0 assignees View on GitHub
bug topic:multiplayer
Dominant language
C++
Stars
117k
Forks
26.8k
PR merge metrics
PR metrics pending

Description

### Tested versions

Godot 4.6 stable

### System information

Godot v4.6.stable.mono - Windows 11 (build 26200) - Multi-window, 2 monitors - Direct3D 12 (Forward+) - dedicated NVIDIA GeForce RTX 4070 Ti (NVIDIA; 32.0.15.8088) - AMD Ryzen 5 3600 6-Core Processor (12 threads) - 31.92 GiB memory

### Issue description

After renaming nodes on both server and client, RPCs from the server to the client reach the client's node which originally had the same name, rather than the one currently has the same name.

Even though the NodePath of both nodes should be identical, it seems like the engine "remembers" what each node was named originally and uses that name to decide on which node the RPC is called.

The following is taken from the output of the MRP:

```
Id 1: Received RPC on node 'Spawnable' with expected name 'Spawnable'
Id 1: Received RPC on node 'Spawnable2' with expected name 'Spawnable2'
Id 960065584: Received RPC on node 'Spawnable' with expected name 'Spawnable'
Id 960065584: Received RPC on node 'Spawnable2' with expected name 'Spawnable2'
Id 960065584: reordering node order
Id 1: renaming Spawnable to 0_11908807
Id 1: renaming Spawnable2 to 1_11909011
Id 960065584: renaming Spawnable2 to 0_11908807
Id 960065584: renaming Spawnable to 1_11909011
Id 1: Received RPC on node '0_11908807' with expected name '0_11908807'
Id 1: Received RPC on node '1_11909011' with expected name '1_11909011'
Id 960065584: Received RPC on node '1_11909011' with expected name '0_11908807'
Id 960065584: Received RPC on node '0_11908807' with expected name '1_11909011'

```

This was originally discovered when implementing a custom alternative to `MultiplayerSpawner` which should utilise pooling of nodes (by disabling process and hiding instead of freeing / re-enabling process, un-hiding and renaming instead of instantiating a new scene).

### Steps to reproduce

1. Run the MRP (two nodes will be instantiated as children of the parent node on both server and client)
2. On server, press "RPC (check name)" button (this will print the name of the node which received the RPC as well as the expected name of the node which was sent by the server as a parameter of the RPC. For now, these should match on both server and client)
3. On client, press "reorder nodes" (this reorders the two child nodes on the client only)
4. On server, press "RPC (rename)" button (this renames the child nodes on both server and client, in the order of the index in the hierarchy)
5. On server, press "RPC (check name)" button (the printed names will now match on the server but mismatch on the client)

This behaviour persist both if the nodes are spawned via `MultiplayerSpawner` on the server and replicated to the client or if the nodes are spawned on server and client independently.

However, skipping step "2" in the above order changes the outcome of step "5". This leads me to believe that calling a RPC on a node for the first time might cache the node path or similar.

### Minimal reproduction project (MRP)

The project is configured via "Run Instances" to automatically run two instances with arguments which will automatically host and join a multiplayer session.

Afterwards, two buttons on the server (Id == 1) and the client (Id > 1) can be used to replicate the above described behaviour.

[multiplayer-rpc-test.zip](https://github.com/user-attachments/files/25273789/multiplayer-rpc-test.zip)

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.