Is your feature request related to a problem? Please describe.
Part of the appeal of having "host" as a mode is that your client and server can be run as a single unit, without needing to worry about spinning both up separately. However, this can lead to an awkward fit when one wants the host to authoritatively manage data that's synchronized via ClientRPCs.
What I mean is that there winds up being a bunch of "do whatever changes locally, then send out updated state to clients, except don't bother processing the updated state data if you're the host because you've already got the correct state locally and it's silly/potentially-error-prone to touch it again inside of the ClientRpc".
Describe the solution you'd like
An optional argument to the ClientRpc attribute could be nice:
[ClientRpc(RpcTargets.ExcludeHost)]
void UpdateStateClientRpc(...) {
//...
}
Alternately, a built-in way to construct a ClientRpcParams that only includes all non-host clients would be welcome, if less elegant than the above.
Describe alternatives you've considered
The most naïve approach is to check if you're the host at the top of the ClientRpc, but this still means that the host goes through the motions of serializing the RPC's arguments, deserializing them, and then throwing all that work away. E.g.
[ClientRpc]
void UpdateStateClientRpc(...) {
if (IsHost) return;
//...
}
Next best is to look up the client ID's for all non-host clients and then construct a ClientRpcParams object to use when calling the ClientRpc. This would either need to be done at each ClientRpc call site, or cached and updated whenever the connected clients list changes. Doable, but a bunch of extra work that I'd rather not have to think about. 😉
Is your feature request related to a problem? Please describe.
Part of the appeal of having "host" as a mode is that your client and server can be run as a single unit, without needing to worry about spinning both up separately. However, this can lead to an awkward fit when one wants the host to authoritatively manage data that's synchronized via ClientRPCs.
What I mean is that there winds up being a bunch of "do whatever changes locally, then send out updated state to clients, except don't bother processing the updated state data if you're the host because you've already got the correct state locally and it's silly/potentially-error-prone to touch it again inside of the ClientRpc".
Describe the solution you'd like
An optional argument to the
ClientRpcattribute could be nice:Alternately, a built-in way to construct a
ClientRpcParamsthat only includes all non-host clients would be welcome, if less elegant than the above.Describe alternatives you've considered
The most naïve approach is to check if you're the host at the top of the ClientRpc, but this still means that the host goes through the motions of serializing the RPC's arguments, deserializing them, and then throwing all that work away. E.g.
Next best is to look up the client ID's for all non-host clients and then construct a
ClientRpcParamsobject to use when calling the ClientRpc. This would either need to be done at each ClientRpc call site, or cached and updated whenever the connected clients list changes. Doable, but a bunch of extra work that I'd rather not have to think about. 😉