How does SetReceivingEnabled work?

In my game, it's possible that a match is taking place for some users, while others are still "waiting in the lobby". Basically the way I handle this is by having the "lobby-people" not loading the level in the load level RPC.

For the "action in the level", I have reserved an own group. Now I would expect that if I do:

Code (csharp):

1.  
2. foreach (NetworkPlayer player in Network.connections) {
3.     Network.SetReceivingEnabled(player, theLevelGroup false);
4. }
5.  

Right in the load level RPC (before loading the level) for the "lobby-players", they should not receive any of the RPCs sent to group theLevelGroup. However, on the "lobby-client", I'm getting a lot of errors along the line of:

and

I made sure that the RPCs I'm getting those errors for area really in that group that's being ignored.

What am I doing wrong here? And: How would be the right way to do this?

Jashan

 

Hi Larus,

thanks for the answer - that confirms that groups are checked after a message has been routed to the network view, which explains the current behavior. So, SetReceivingEnabled sure won't work. Thinking about it, that would be a wasteful approach, anyways...

Using SetSendingEnabled sounds cool, except for that I can only switch off a group completely that way. By doing that, also my clients that need to receive the messages would be blocked off. So, this would only work for me, if I could specify the NetworkPlayer which is effected by SetSendingEnabled.

Setup is like this: Clients send server RPC "start the level X for us, please", server sends load level to everyone who is "ready to play" (and not to those, who are not) and starts spawning the relevant object through Network.Instantiate(...). Before starting that, I could either disable receiving the group messages on the client (which I can't really do because groups are a level "below" the NetworkViews which don't exist on the relevant clients), OR tell the server "please do not send to NetworkPlayer a, b, c, d on group G" (but keep on sending to these NetworkPlayers for the other groups, of course).

Would that currently be possible? Did I miss something? I think that would be needed, wouldn't it?

I sure need a way for clients to say "I don't want to get this'n'that" - with SendSendingEnabled(NetworkPlayer, Group, enabled), I could do that by doing an RPC from the client to the server telling the server to stop sending messages to "me". Basically, a way to subscribe to groups on a "per player basis".

Jashan

 

Exactly - and that's just the beginning: In future versions, there will be different "matches" taking place all at the same time on the same server. For that, I really need a way of grouping the messages - and the current NetworkView.group won't help me with that for the reasons mentioned above.

Some of these matches will take place in the same "level", for that, the current implementation with groups would be sufficient. However, there will also be matches taking place in different levels simultanuously (there's some tricks involved in that, but it should work very well as long as the server implementation is very efficient).

In the current version, this would be an option - but in the long run, I'll have multiple levels being played simultanuously on the server. However, the clients will only have one level. Instantiating all the objects on the clients would then probably create quite a mess and waste a lot of bandwidth ;-)

What I'll try for now is, below an abstract layer, to send the messages directly to the NetworkPlayers instead of using RPCMode.All and RPCMode.Others. I would assume that this comes with a bit of a performance hit, but I need this flexibility.

That would be really good. By using an abstact layer in between, I will probably be able to convert to the "Unity-style", once "the Unity-style" is available...

Do you think when implementing that feature, you would use SetSendingEnabled(...), just with another parameter? Or is that too early to make a decision on that? Knowing how this would be designed into the Unity-API would help me design my abstraction... I'd like to do this in a way that once the Unity feature is available, all I need is a global search and replace and then I can drop my workaround...

Jashan

 

Hm... I'm having a little problem with implementing this myself: It seems as if I can't send RPCs from the server to the server.

When I'm using my own network player on the server to send an RPC, I get an error that this player is not connected (which is not quite true, because I am connected). Then, I tried it with RPCMode.Server. Since I am the server, I would assume this should work. Unfortunately, it does not.

Only when I'm doing RPCMode.All, the server gets the message itself. But that doesn't help me much because I need to send the message specifically to those players registered...

Now, there's obviously ways to work around this (I could change all RPC-calls from the server to directly call the RPC "in place" as a simple method call), but as what I'm doing right now already IS a workaround, I'd rather not do this... Is there any chance SetSendingEnabled(NetworkPlayer, GroupID, enabled) will make it into 2.0.2?

Aside of the struggles I'm having right now with sending a message from the server to the server, there's also the issue that with a "home grown filtering system", I can't use Network.Instantiate or State synchronization (the RPCs from "under the hood" will go to everyone ). So, not being able to create a filter and neither being able to create a solid workaround is kind of a show-stopper for me...

Or am I just missing something obvious?

Jashan

 

Having the same problem as jashan, I'm very looking forward for the development of this area on Unity, currently, dividing a server's capability's between (number of levels\maps)*(number of each level's instances) is quite an "impossible mission", having several areas\maps\levels separated, all running with players on each is currently a fools errand.

What unity currently does is expecting everyone(every player+server) to be in the same level at the same time, which is quite unthinkable on any online style game, from Online FPSs(where you can have several matches running) to MMORPGs(where you have from Character creation screens, to dugeons, to pvp areas), even on a simple chat room program there can be private rooms.