Unknown Players

[LucasAdams]

In the archives I've noticed clientIDs appearing that are not in the players list.
For example in https://api.openfront.io/public/game/xBfi1ncT the client gZts6g7J seems to connect at turn 3126 (~5minutes into the game?!?!), spawns at turn 3555, and even performs an attack at turn 3783, before disconnecting at turn 4130 (~30secs later).
Additionally in a random selection of ~100 games I find ~5 games where disconnects (without other actions) occurs to ~10 clients.

Looking at GameServer.ts the archiveGame() outputs this.gameStartInfo which is only set in start() and only populated by this.activeClients.
I think this has two issues:
(a) Temporarily disconnected clients are not reported: clients are removed when ws.on('close') (if the client actively closes the connection this can be less than the 30sec disconnectedTimeout and less than the hardcoded 60_000 in phase()). GameManager.ts tick() seems to show that the prestart() period is only 2secs long which reduces exposure.
(b) New clients are not reported: joinClient() allows clients to join after start() called (_hasStarted==True).

If archiveGame() iterates over this.allClients rather than this.gameStartInfo.players then the archive is completely fixed.
If start() iterates over allClients rather than activeClients then (a) is mitigated completely.
However (b) requires sending updates to clients on joinClient() potentially requiring a new message.

Some general thoughts about the GameServer code:

• sendStartGameMsg() should just accept client as a variable which all of it's callers can provide, rather than searching again for the corresponding websocket.
• this.websockets should probably be removed in favour of iterating over this.allClients.ws
• should client.ws.on("close") immediately trigger a mark_disconnected? or is it intended to keep the 60sec delay for temporary disconnects?
• ideally kickClient would immediately mark them as markClientDisconnected(true) so their territory could be immediately canibalised.
• the disconnected status and the websocket itself are managed separetely and it might be worth unifying. for example phase() implements a timeout of 60_000 but checkDisconnectedStatus() uses the 30sec disconnectedTimeout but these concepts are somewhat orthogonal.

[LucasAdams]

In the above game, there are 68 players in info.players and 65 unique clientIDs in the spawn intents, but 95 unique clientIDs in all intents.
It is possible that the client's clientID changed, although ~30 changes in a game of ~60 players seems a bit high, perhaps the server was slow and half of the clients hit refresh?

[LucasAdams]

• Non-players should be able to join at any time but not take actions, ideally with some sort of indication that they are read-only: https://discord.com/channels/1359946986937258015/1359946989046989063/1465482340037034258
• GameServer should drop non-player intents
• • for actions https://discord.com/channels/1359946986937258015/1359946989046989063/1465482826903322654
• • and for wins https://discord.com/channels/1359946986937258015/1359946989046989063/1465483460628975751

[LucasAdams]

Looks like extending the connection time to cover the spawn cutoff would only add ~3% of players.
The bigger issue is the 13% of players that seem to be present at tick 0 but don't have a username, eg: https://api.openfront.io/public/game/sPJdtt5G clientID=VA5vo3aA. The mark_disconnected intent is queued on joinClient() but only sent on endTurn(), perhaps these are clients that connected then disconnected? If so, generating gameStartInfo from allClients rather than activeClients would fix this.
Surprisingly despite 98% of players being connected only 69% bother to actually spawn in (I only count first spawn).
https://discord.com/channels/1359946986937258015/1359946989046989063/1465699122953851107