Open darthLeviN opened 1 year ago
See this draft PR for a proposed system which suppress RPCs and replication until authentication completes: https://github.com/godotengine/godot/pull/67917 .
Once the peers connects, the replication system already supports peer filtering (visibility), via the MultiplayerSynchronizer
node, the RPC system likely need to be updated to respect that visibility (though it might get tricky in case of relayed peers, so it deserves some more investigation).
Describe the project you are working on
A game with multiplayer. it needs a reconnecting system, an authentication system. it relies on rpc calls and needs to filter these calls properly.
Describe the problem or limitation you are having in your project
Godot offers almost no control on rpc calls. you can't block certain rpc calls from reaching certain users.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
Add a mechanism to filter rpc calls. also redirect failed rpc calls for more handling.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
I just have to mention when i say something like "disable rpc calls" i also mean
rpc_id
, reliable or unreliable.rset
, reliable or unreliableChanges to
Node
:bool
property calledpublic_rpc
with the default value offalse
.rpc_meta
that will be attached to rpc calls to handle their failure if needed.Implement a new Object type called
Rpc_call
with the properties below (this is just to give a gist of the idea):Simimilarly implement a new Object type called
Rset_call
:Changes to
MultiplayerAPI
:public_rpc
set tofalse
.enable_rpc(int peer_id, bool enable)
. on the server side it can disable rpc calls for peer_id(incoming and outgoing). ifpeer_id
of 0 is used, it will do it for all users. on the client side, onlypeer_id = 0
is allowed and it will block rpc calls coming/going from the server. the client will be responsible to decide what to do about the fact that some reliable rpc calls for some nodes have been dropped.bool
property calleddefault_enable_rpc
with the value oftrue
. this will determine the initial state of rpc calls for newly connected peers. the default value will make it backwards compatible.rpc_failed(rpc_call, int error)
. this way if a node is not found,rpc_call.meta
will contain information that helps the programmer create the node if needed. for implementation note to take care of updating sender peer id to the peer that has it's rpc call failed so that we can still useget_rpc_sender_id
to know who the signal is for.rset_failed(rset_call, int error)
. same as above.last_rpc_meta()
to get therpc_meta
for the latest rpc call even if it succeeded. this means thatrpc_meta
can also be used for other functions to reduce some of the data redundancy that it causes.A thing that i didn't cover is that i don't know if one should also disable rpc calls for peer_id = 1 (host itself) or just let them pass. maybe a variable could control that behavior if needed?
Also a flaw that
rpc_meta
has is that it will be copying the same data over and over so we have to use a data that's easy to copy to not have noticable performance drawbacks. a better approach would be to make the rpc calls more flexible with an extra argument to attach whatever we like. but that wouldn't be backwards compatible.If this enhancement will not be used often, can it be worked around with a few lines of script?
Nope. It has to be built in.
Is there a reason why this should be core and not an add-on in the asset library?
It's one of the most important multiplayer features.