Refactor some network Packets that affect the game state to be tick bound.

[ZehMatt]

Currently networking the player list is not bound to ticks where it should since the client always lags behind the server. We should perhaps refactor some packets to use game commands instead of being a simple network packets.

Example with PLAYERLIST packet:
Player (3) is currently placing tracks, issuing game commands at client Tick 33331
Player (1) kicks Player (3) at client Tick 33332
Server executes place track at Tick 33333, send game command back to clients.
Server executes kick at Tick 33333 and sends the new player list to all clients, player is removed at this point.
Player (2) receives place track from Player (3) at client Tick 33332, queues the command.
Player (2) receives PLAYERLIST, executed at point of arrival which removes the player if hes missing in the list received.
Player (2) executes at Tick 33333 the place track command, however the player does not exist anymore.

It should be clear that we can not remove players from the game state earlier than when the Server did it, the client has to always catch up otherwise this will cause faulty logic in the game state.

In some cases this is not a issue if the client is usually able to catch up fast enough however with higher latency this might be not the case.

I would like to hear some suggestions and ideas on how we should process with such specific things. One suggestion is, we could also include in the packet header the tick by default and tell each client if he has to wait or not for the tick to be reached, however this requires a common queue to keep order in tact.

[Gymnasiast]

To me, it looks reasonable. The thing is I know next to nothing about the network layer, so I can't really comment. This is something for @IntelOrca @janisozaur and @zsilencer (if he is active again).

[janisozaur]

We could have server remove kicked player's actions from the queue or if it fails to do so (e.g. the action has been already sent for the tick), defer kicking until earliest next tick.

[duncanspumpkin]

Why not just delay the kick for a nominal amount of ticks and disallow any future commands after the kick is in the queue.

[ZehMatt]

@janisozaur On the server client actions are never queued they are directly processed and then sent to the clients, theres no chance catching it before messages go out, it would be really rare to be on the same Tick where kick and place track happens from two different clients.

Clients should always do the same as the server in the same order and the same time, manipulating anything between seems error prone.

@duncanspumpkin The kick command is already bound to a tick, the real issue is that the playerlist is not and so the order of things is messed up like prematurely removing the player, it would be no issue if playerlist was a command since the server first sends the kick and then the playerlist.

[zsilencer]

PLAYERLIST does not affect game state.

Game commands are separate, they are not tied to the player list at all. Clients will still run the command even if the player doesn't exist. The only reason kicking is a game command is to make use of the client->server, permission thats already there etc. You don't remember but there were game commands before there was multiplayer, they are the only thing that can change game state.

Lets say you actually did this, when someone paused the game causing no more ticks to be processed, if someone joined the game or disconnected they would not even appear until it was unpaused.

[ZehMatt]

Thats how pausing usually works when theres a round trip involved. The other way would be to simply have a separate list for the player list to show but the actual client cant vanish not before the kick command is executed on the client.

Edit: Also PLAYERLIST does affect the game state by removing a player, if it wouldn't remove them then its fine, I'm not sure if we are on the same definition when we speak about game state, game states usually contain all players because the game state is synchronized. So removing the player too early will cause some things to fail once the client gets to execute commands from the player before he got kicked like placing objects, now the client doesn't even know who placed them.