Spring RTS Engine

Seems simple enough that lobbies understand they need to send their battle status when they join a battle. Afaics in the Uberserver implementation it would take 5 seconds to remove the command. Is there some reason that other lobbies depends on this? It doesn't cause any problems for the command to be ignored from a lobby's point of view.

It's a signal to the client that they have now reached the point where the server has sent them all available information about the battle (at which point, and not before, the client will wish to reply). There is nothing else to signify to the client that this point was reached, because the number of teams/allyteams/boxes/bots/etc is non-constant and may be zero in some cases - see https://github.com/spring/uberserver/bl ... tle.py#L41. Consequently this command is required.

Silentwings wrote: ↑14 Dec 2019, 20:33 It's a signal to the client that they have now reached the point where the server has sent them all available information about the battle

I fail to see the significance of this information – but I guess there could be a reason a client may want to know this, even if I can't think of one. I'd suggest then that REQUESTBATTLESTATUS wouldn't be the best name for the command and that the description should change, but I'm not sure that's worth the effort and compatibility breaks.

(at which point, and not before, the client will wish to reply).

Why not before? The code doesn't appear to care, and there seems no issue when I send my status immediately after receiving "JOINBATTLE".

Because the client has the option to choose their battle status dependent on what is going on inside the battle. Whether the client actually makes any use of the information is up to the client. Regardless, the server will not process the clients reply until after all the battle info was sent to the client.

Iirc the clients typical response is a MYBATTLESTATUS, so REQUESTBATTLESTATUS doesn't seem a bad name.