Hi guys,
I’m defining a use case of event handling like this flow:
User X change avatar item → Call RPC → Server save data → Server find the current match of X → Server notices another clients that X has just updated his avatar.
How could i find the current match of User by their userId?
I’m developing with an env which included:
- Versions: Nakama 3.10, Docker on Mac, client SDK Unity
- Server Framework Runtime language: Go
@tunglt1810 Why not send the “change avatar item” as a command message in your netcode to the match itself. It would just be like any other data message to the match handler but would be handled in your match handler loop to set the new avatar item and replicate that knowledge to any other participants in the match (as needed).
I guess what I’m not clear on is why use a socket RPC at all when it could just be a data message to the match handler?
Thank @novabyte for your support.
What I think is the implementation behavior separation. “Change avatar” just a kind of command and “notice participants in the current match” just a kind of side effect which can add to the posthook of command execution.
@tunglt1810 Does this mean that a user can change their avatar while not in a match? That would make sense to use an RPC or use the UpdateAccount
function in the server (based on whether your avatar input would need to be validated). But I’m not clear on why a user would update their avatar in the match but you’d not send that update as part of the netcode for the multiplayer logic.
@novabyte
Update avatar just a kind of command. I’m think about the way to trigger the side effect of a command to the current match of user