Changing EmptyRoomTTL/PlayerTTL
Options
egress
✭
Hi Tobias, is there a way to change EmptyRoomTTL and PlayerTTl outside of RoomOptions during the create room operations?
I was trying to get around the situation where players can force quit the game (through the app switcher in iOS for example) and as a result they look as if they are still in game to other players as they did not disconnect properly.
I was trying to get around the situation where players can force quit the game (through the app switcher in iOS for example) and as a result they look as if they are still in game to other players as they did not disconnect properly.
0
Comments
-
If the client did not send a Disconnect(), then there will be a timeout for this connection and that takes a while (the alternative would be a LOT more disconnects which is not a good solution either).
At the moment, you could only check if maybe less messages from the other side are incoming than you expect.
EmptyRoomTTL and PlayerTTL can only be set at creation time.
What exactly do you want to achieve?0 -
Ah I was looking at cases where :
First player (using JoinOrCreate) creates the room. He is now the game master, who picks the rules and decides when the game starts.
Other players join in. They are waiting on the master client to start.
Now, if the first player force quits his game, or loses their internet connection, he still remains as the master as he has not called disconnect. If the players leave and search for another room, they will still rejoin the room that he is in as he has not been removed until he times out, leaving them unable to start a game.
Are you suggesting that I send a message at certain intervals to ensure that the player is still available?0 -
The timeout for a connection is ~10 seconds. There is no way a client disappears without the timeout happening.
So in worst case, some players might take 10 seconds before they notice the Master is gone and then they pick another automatically.
If you attempt to do this earlier, you work around the Master Client selection and that's not always a good thing to do.
If you sent some kind of update regularly, then you could check if it really arrives in the expected interval (approximately) and show a sign that the Master might be about to disconnect.
I would not send extra data just to reaffirm everyone that the master is still there. That player IS there unless it times out or quits.0
