Closed Bruce-Chan closed 1 year ago
Hey @Bruce-Chan it's unclear to me exactly what your workflow is, but I am assuming you are talking about adding custom .proto
files for your RPC responses. The solution isn't to modify the original C# source code but instead to parse the bytes from the RPC response into your generated custom .proto structs. Does this make sense?
Hey @Bruce-Chan it's unclear to me exactly what your workflow is, but I am assuming you are talking about adding custom
.proto
files for your RPC responses. The solution isn't to modify the original C# source code but instead to parse the bytes from the RPC response into your generated custom .proto structs. Does this make sense?
Thanks for your reply. Actually, We are not only adding custom RPC function, we also want to modify the prebuilt struct and API method from Nakama. Just like my example above. "For example, we would like to modify the ApiUser struct to support FriendInviteEdgeCount and FriendBlockEdgeCount instead of EdgeCount. Now, we cannot finish it on the client-side."
We definitely don't support extending the Nakama API this way. We'd rather encourage a layering approach on top of the existing APIs as well as using our RPCs.
We definitely don't support extending the Nakama API this way. We'd rather encourage a layering approach on top of the existing APIs as well as using our RPCs.
But if we just use the custom RPC, we need to defined a lot of struct again on the client side, e.g. the User Struct, match struct, Party struct, etc... Extending the Nakama API seems easier for us.
Are you talking about redefining the structs provided by the Nakama SDK in order to parse RPC responses? Why would the former necessitate the latter?
By the way, the original source code is in our .NET library: https://github.com/heroiclabs/nakama-dotnet
A lot of work doesn't support with RPC. For example, we feel hard to support mobile phone message auth, because this framework assumes all the users have already login.
By the way, the original source code is in our .NET library: https://github.com/heroiclabs/nakama-dotnet
That is exactly what I want! Thanks a lot!!!
It's still pretty unclear to me why you need to take this approach, so be careful, but that's where it lives 😄
Hey @Bruce-Chan could you actually either file an issue on Nakama or reach out to support so we could have a further dialogue about this? We want to further understand what you’re trying to do and potentially integrate some of your needs into Nakama. Otherwise you won’t be able to run on Heroic Cloud or use Nakama Enterprise.
We implemented a lot of new feature for the server-side code, it is easy to modify the API IDL by regenerating the PB. But on the client side, the response struct is defined in the nakama.DLL. That makes us feel hard to customize it.
For example, we would like to modify the ApiUser struct to support FriendInviteEdgeCount and FriendBlockEdgeCount instead of EdgeCount. Now, we cannot finish it on the client-side.