-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RPC manager rework #52
base: development
Are you sure you want to change the base?
Conversation
- Moved RPCManager to legacy folder
What happens when you register multiple RPC handlers of the same typename? It goes specifically by instance right? Will it send an RPC to all instances of RpcMinimalDemo? |
Registering an instance of the same type twice will result in a warning: https://github.com/Jacob-Mango/DayZ-Community-Framework/blob/f9deb5e56a43e898fb1cb63ad1a43599b4bcd765/JM/CF/Scripts/3_Game/CommunityFramework/RPC/RPC.c#L34 There can only be one handler because of the read context in the RPC. Once the first handler read the data from it, it would be empty for the next one. I do not see a way around it currently. |
Needs to be able to explicitly mark the functions which can be handled. Don't want to allow any function within the handler to be called. |
Maybe an optional whitelist when registering? Default would be everything is whitelisted (for the main use-case of extra handlers that ONLY contain functions to be called). And if you were to add MissionGameplay as handler instance you could restrict it to the 2-3 functions you want to be callable. |
Updated invoke function interface order Remove invoke function target object parameter Removed target parameter from context prepare
Updated inline documentation
Added CF.RPC parameter validation Updated CF.RPC inline documentation
Updated RPC documentation with tweaks
Updated RPC context functions to be chainable Updated RPC.SendTo to force recipient parameter Updated RPC documentation formatting
Updated function name for setting rpc handler function parameters Fixed typos
|
||
if(m_FunctionParameterTypes.Contains(hashKey)) | ||
{ | ||
PrintFormat("[WARNING][CommunityFramework][RPC] Failed to register function parameters for %1. Already registered.\n Existing parameters: %2. See trace below:", hashKey, m_FunctionParameterTypes.Get(hashKey)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remove print message here, there are 2 reasons the constructor can be run again.
- The class is initiated during mission runtime many times during the games lifetime
- The class contains a network ID (Object)
Remove the message from other offending areas as well.
The main advantage is that you do not need to explicitly register your mod and function for everything you might want to send. If a mod only needs one handler you only set it up once and then every new function added does not require any interaction with CF.
Additionally, the now underlying ScriptRPC allows for retransmission of the same data to multiple receivers.
What is not part of the reworked interface is the whole concept of single-player execution behavior. There are other more compact ways to switch logic for single-player testing. Either they use different functions, or within the function, you check if you are the host or not and handle the data accordingly. Besides - I have not seen much clever use of it. If someone absolutely needs it (which I doubt) they can refer to the legacy RPCManager that continues to exist until we figure out a way to update the new interface to offer that as well.
See the minimal demo of how RPC's would work with this now: