Moving to ioquake3 since it looks like it's an engine fix.

Created attachment 965 [details]
fix cmd overflow caused by slow loading

There doesn't seem to be any good reason to send server cmd's to the client when it is connected but has not yet recieved the gamestate.  On servers with many players it's bound to overflow the MAX_RELIABLE_COMMANDS (128) especially when a level first starts and the server spams out commands for every "connected" and "entered the game" message.

I should also mention that it appears Enemy Territory has the same behaviour since I don't see any chat messages in the console that were sent out while I was still loading (this was not the case in Tremulous before this patch).

Although my first patch was valid, it didn't really solve the problem.  Here is what really happens:

A connecting client goes from CS_CONNECTING to CS_PRIMED when the server sends them the gamestate.  This is right BEFORE the client starts loading the map.  The server continues to try to push server commands at the client as long as they are CS_PRIMED even though the client is too busy to handle the incoming requests.

In Tremulous this behaviour is especially brutal since as players join the game, the CS_PLAYERS strings are updated like crazy at the start of the map as players join teams, pick classes, evolve, etc.  It seems like the largest offender here is the server commands that update configstrings.

My solution (first patch) attacks only the problem of configstring update commands:

  1) do not send any configstring update commands to the client until they are CS_ACTIVE

  2) keep a record of which configstrings have been updated when a client is CS_PRIMED

  3) when a client goes from CS_PRIMED to CS_ACTIVE send configstring update commands for each configstring that was updated while they were primed.

This takes care of the majority of real world senarios of this overflow problem, and will not cause any compatability issues.

However, this is not a complete solution.  The second patch (depends on the first patch) stops the sending of ALL COMMANDS until the client is CS_ACTIVE.  This has a potential to cause all kinds of problems, but since I couldn't think of anything offhand.   Whether or not this patch is valid depends on the following assumption:

  "Other than the configstring update commands, no other server commands should change a client's gamestate"

If this assumption is true, then this second patch is valid and should prevent this error from ever occuring because of long client load times.

Created attachment 1090 [details]
svn913 no configstring updates while CS_PRIMED

Created attachment 1091 [details]
svn913 no server commands while CS_PRIMED

Created attachment 1092 [details]
svn913 no configstring updates while CS_PRIMED

mistakenly neglected to update configstrings that had been changed to empty values

It looks like it will be too problematic if we don't send any server commands at all while CS_PRIMED (first patch).  There are a couple of things that would need to be changed in the q3a game code to make this work reliably (e.g. in-band 'disconnect' commands).  Since there are without a doubt many more potential problems in various other mods this would be a bad idea.

The 'no configstring updates while CS_PRIMED' patch is well tested by some Tremulous servers and it doesn't have much potential to cause problems.  It should be beneficial to all q3 games since it will often reduce load times even in cases where the reliable command buffer doesn't overflow.  The only tradeoff is the tiny memory increase: MAX_CLIENTS * sizeof(qboolean)

However, people do report getting the same "CL_GetServerCommand: a reliable command was cycled out" error when 'map_restart' is executed as opposed to loading a new map.  I still need to look into this.

Created attachment 1109 [details]
svn917 no configstring updates until CS_ACTIVE

* fix problem with map_restart from last patch

commited as changeset 935

Setting a QA contact on all ioquake3 bugs, even resolved ones. Sorry if you get a flood of email from this, it should only happen once. Apologies for the incovenience.

--ryan.