Searching for better idea for fixing 'Node not found' in Networking

dest

Hi guys. A fine tuning question. Ive started developing a multiplayer game and i keep getting alot of errors with 'node not found'. This is happening because in my project there are controllable projectiles that explode once they hit a target or time runs out. So what is happening that, in my server, the object is freed faster than at my client, so the client still sends packages considdering the projectile and the server receives the packages later, when the projectile has already been freed. Resulting in:

E 0:00:18:0653 Node not found: Main/Rooms/1/Players/1315924185/Projectiles/1466 <C Source> scene/main/node.cpp:1382 @ get_node() E 0:00:18:0663 Failed to get cached path from RPC: Main/Rooms/1/Players/1315924185/Projectiles/1466 <C Source> core/io/multiplayer_api.cpp:266 @ process_get_node() E 0:00:18:0669 Invalid packet received. Requested node was not found. <C Source> core/io/multiplayer_api.cpp:194 @ process_packet()

I've already thought up a potential solution: I suppose i could disable the projectile with setting a variable 'destroyed' at the server and not freeing it until a yield(get_tree().create_timer(1)) expires. This however seems like a hacky fix to me (I might be wrong, but i thought i'd ask anyway). Does anyone else have a better idea for me how to handle this problem?

TwistedTwigleg

What great timing! I just started dabbling with some networking code in my spare time and am having the same issue!

Currently, I’m thinking about having a singleton RPC “router” that handles all RPC calls so I can add some extra logic, like checking to see if a node exists before sending the call. Then all network stuff can call the RPC router using normal RPC functions, where every function has to pass a node path relative to the RPC router so it knows what to execute where.

I think this may have the added benefit of making scene replication easier, as when an RPC call comes for a node that does not exist for a client, it should be able to detect it and respond (probably ask the server for node info or something?).

I’m not sure if its a good solution, if it will work, or cause any bottlenecks, but its what I’m currently thinking about trying for my project to fix the issue.

dest

Hi TwistedTwigleg,

Thanks for your reply! That is an interesting way to solve it. Yes that way you can indeed run some checks before actually processing the RPCs. I dont see bottlenecks per se and i do think it solves this problem:)

To me, it feels a bit like using the RPC system differently than its designed to be like though, as the RPC system is very centered on finding the same node in server and client, instead of dedicated sending and receiving modules and then passing it on. I wonder why it is developed that way if this issue cannot be solved in a different way. Maybe someone still has some input on that?

But for now your solution will work, i think:) Please let me know if you do hit a wall with it. Ill think about it a bit more, but possibly i'll use your method:)

TwistedTwigleg

@dest said: Hi TwistedTwigleg,

Thanks for your reply! That is an interesting way to solve it. Yes that way you can indeed run some checks before actually processing the RPCs. I dont see bottlenecks per se and i do think it solves this problem:)

To me, it feels a bit like using the RPC system differently than its designed to be like though, as the RPC system is very centered on finding the same node in server and client, instead of dedicated sending and receiving modules and then passing it on. I wonder why it is developed that way if this issue cannot be solved in a different way. Maybe someone still has some input on that?

But for now your solution will work, i think:) Please let me know if you do hit a wall with it. Ill think about it a bit more, but possibly i'll use your method:)

Yeah, I tested it and it seems to be working great so far. I haven't done any tests with scene replication, but for RPC calls it works without a hitch. I did find that I have to pass the absolute node path as part of the RPC call, but thankfully the get_path function works fine for this.

I agree that it does seem to be using the RPC system in a way that I think was not intended in the design. Strangely though, in my testing it seemed to make things a little faster, which is not what I would have expected. Though, to be fair, it could also have just been I optimized things, as I made a bunch of changes to get the RPC system working.