SyncEvents let you register to the event that will be called from anywhere whereas a ClientRPC will only be called on the same NetworkBehaviour and you can’t register to it like an event.
can’t i achieve event registration also with ClientRpc, e.g - expose an Rpc method that raises an event:
public class TestBehaviour : NetworkBehaviour
{
public event System.Action TestEvent;
[ClientRpc]
public void RpcTest()
{
// Call this event
TestEvent();
}
}
And my point was that SyncEvents are pointless since you can achieve the same like i showed. The typing it saves is absolutely minimal in this case… unless i got it all wrong and they have some other purpose.
Let’s be honest if you want to say that you don’t need convenient functions to do specific things because you could do them other ways as well we might as well just get rid of all these convenience attributes and do everything with the Network Messaging System.
I am not saying “let’s get rid of all the little convenience functions”. I am asking why do we need 2 things to do the same thing just for minimal extra typing.
For example, the [SyncVar] attribute saves a lot of typing by generating code, managing the dirty bitmask and calling the relevant serialization methods for the NetworkBehaviour type for you. This is a good example of something that is beneficial for the developer; but having 2 options that do almost the same thing, just for saving 1 line of code seems odd to me.
I actually kind of agree. SyncEvent has turned out to not be very useful. A fully networked version of the UnityEvent system that was introducted with uGui that understands distributed authority would be useful, but SyncEvent as it stands is far from that.