We have a Game server which simulates a whole 3D world with a lots of objects. If we connect a client he gets all the instantiate RPC calls and the objects are created remotely as well.
But, we have another client type e.g. an observer with limited performance which is just logging some things. In any case the instantiated objects should not be created on this kind of client.
The problem is that SetSendingEnabled(player, 1, false) or RemoveRPCs(player, group) executed in OnPlayerConnected on the server does not influence the initial transmission of all buffered RPC calls since they are already sent at this point. This seems to be a serious design issue because we would like to be able to prevent sending buffered RPCs of certain groups to some of our clients!
After a lot of tries we figured out a way to achieve what we want more or less by calling SetReceivingEnabled(player, group, false) on the client side in OnConnectedToServer. We could at least prevent object instantiation on the client side per group.
Imagine you have a scene with thousands of instantiated objects, how can you prevent the server to send all instantiate calls to the client? Without taking the client himself in charge of blocking the thousand instantiate calls?
Since we have different clients how can we immediately determine the client type? It seems there is no direct way to provide an extra string of connection information like RakNet allows naturally.
Any advice would be highly appreciated. We currently have the feeling that the network design suffers some unecessary limitations.
You should use manual allocation of viewids instead of network.instantiate to gain more control. Just stop using it completely.
“Detect the client type”? How so, there is just one server and 0 or more clients in the Unity networking. There is now the networking GUID if thats what you mean.
Yes this might be a feasable work around for this problem. Since Unity provides the Network.Instantiate API I really would like to use it though. Eventually the workaround forces us to manage all Instantiate/Destroy calls as well as the viewId settings on all clients manually :-/
I hope a future version of Unity could solve this issue by just not sending all RPCs before the OnConnected event.
As I tried to describe above we have different kinds of clients which use (visualize) and change only a certain small subset of the data managed by the server. We would like to determine the type of client on connect (e.g. type A, B or C) so that the server can decide which data to send and update. Managing all viewIds manually like you suggest above would ofcourse solve the problem since we then have the time to exchange this information after the successful connection and start sending all necessary data afterwards.
I don’t the “It provides it so I want to use it” counts here. It’s like using Unity’s built in normalmap generator for high end graphics; it’s not meant for advanced usage. Furthermore, it’s not really much work/complicated to do the manual allocation instead of instantiation. You’ll see that you’re codebase even becomes cleaner and clearer.
For 2 you should just maintain a list of connected clients and assign them A B or C. Or have them tell you wheter they are A B or C via an RPC. This is unrelated to the instantiate or manual allocation really.