static_cast<int>, while you're at it. Btw, why the m_AutostartPlayers is int? I think it should be size_t.

2018.

To add to NSS_JOIN_SYNCING:

• The server started to or finished transfering the simulation state to deserialize and the client has not finished loading the map and deserializing the state yet.

If not the implementation, this block needs comments too. Implementation (.cpp) probably better though.

Almost all OnFoo functions are only executed when a CFooMessage is received, but OnStartGame breaks this pattern because it is called for rejoiners (while OnRejoined is only called if an other client rejoined.)

Since CNetFileReceiveTask_ClientRejoin does // Pretend the server told us to start the game

What do you mean with rejoin?
(Maybe I just forgot something, it was a long time ;))

Shouldn't that be joining?
If an observer joins he'd go into that state, but he wouldn't rejoin.

Not sure if we can call loading a started game. From my understanding the game starts after everyone finished loading.

Maybe not that this state isn't in use currently?
(Or is it?)

dot

"transfering" → "transferring"

A rejoin is when a client joins the match after it started and thus doesn't see the gamesetup page?

I guess it's historical reason (there were no observers back then) that networking jargon equates rejoin with joining after the game started.

That's in particular the case with all the variable names such as IsRejoining, even in the network packet properties.

Dunno, perhaps because it's user-input and not the product of a vector length? There is a lot of stuff wrong with C++ Autostart.

Why is the button named "launch game" and the message that is then sent "CStartGameMessage" if it doesn't inform server and clients that the game was started? Every client initializes the CGame object when it receives that message.
It's the purpose to define these terms here and the addressee is the developer, not the player.

It's unused currently yes. I agree that it it is in the scope to correct state descriptions, but I am reluctant to add TODOs. (We have a ticket for that IIRC and we can remove the state as well if we want to correct it to it's current state.)

Hmm, so with was informed if a rejoin needs to be performed. you mean if it can leave out the gamesetup page?
For me rejoin needs to be performed sounds like the client needs to disconnect to the server and connect again.

So we should start introducing the correct terms, right?

Ok, what about The gamesetup was completed, the game was started and now we begin loading the map.?

There are 126 occurences in the code that use "rejoin" as the name for the procedure.
The purpose of this patch is to describe the states, not to rewrite everything that uses the word rejoin.
If you want to change the connotation that rejoin = join after gamestart, that can be done in a different patch (preferably after all the other networking patches are in). Should this procedure, packet and variable names be called LateJoin? PostGameStartJoin?

"we begin loading the map" and "now the map is loading" doesn't change much, but why not.
"we" is ambiguous. We are the readers of the code. It could be the NetClients, the NetServer, both, or even further related instances. (I prefered to repeat the word user and Wildfire Games 30 times in the the ToS / PP for that reason too). It should state which instance we talk about.
So it should be "all clients started loading the map".

What about The client is joining a running match (Called rejoin in most of networking code)?

What about The gamesetup was completed, the game was started and the map started loading.?

So it should be "all clients started loading the map".

That is also fine.

Not most, in _all_ of the C++ and JS code.
The string displayed in the ingame chat for observers is the only place that differs from this.