So I’m trying to do a kick player function and I just can’t get it to work properly. The thing is I want the player to know why he was kicked, so I need to be able to send a string along with the kick, to tell the player what happened. (It could be an int with an id as well, but I do prefer the string method).
So here’s what I’m doing:
[ClientRpc]
void RpcKick(string msg)
{
//If we are the server kick the client
if (Links.MS.IsHost)
connectionToClient.Disconnect ();
//If we are the client owning the object, show the message.
if (GetComponent().isLocalPlayer)
{
Links.MS.ShowMessagePage(msg);
}
}
I cannot seem to find the code tag, but the function is rather small, so I figure it’ll be okay. The thing is, if I don’t ask the server to kick the client, it works just fine, but as soon as I ask the server to kick the client, the client never gets the message. I’m guessing it happens because the server closes the connection so the RPCCall never gets through.
In the old unity multiplayer system however, network messages were guaranteed to arrive in the order of which they were sent, is that not the case with the new one?
Is there really not a proper way to make sure the client recieves the message before kicking him? I realize that I could make the client disconnect himself rather than the server, but I’m afraid that people could then make modifiedc clients that refuses to let them be kicked.
I did also consider waiting a certain amount of seconds before doing the final kick, but I fear the player might feel like the UI is being unresponsive. It does however look like the only way to go.
But does this means that RPC in the new system are not guaranteed to arrive in the order they are send in?
I suspect the RPC message is being sent to the buffer, but the connection disconnect is immediate so it dumps the waiting messages.
If you are using Reliable Sequenced for the channel, messages will arrive in order but the connection closing is immediate so it ignores the message buffer.
EDIT: It looks like unreliable messages get sent immediately but reliable messages will generally get sent next Update() so you can probably yield for a frame or two before disconnecting
Sorry for the late answer but thank you SO much! I did end up delaying the disconnect, but knowing that my RPCs should be sent in order is great indeed!
@Mytts
I’m trying to do the same thing, but after the disconnect client was unable to join the host anymore. So I’m wondering if you have this problem? If not would you please share a little bit more about you above code, thanks.