Message Boards

Background:
A ticcmd is a collection of data that represents the action buttons a player presses during a particular gametic (1/35 second frame). This includes the amount of movement in the forward/backwards direction, the amount of movement in the left/right direction, status of the +use, +jump, and +attack buttons, and the desired view angle and view pitch.

The ticcmd queue was introduced in Odamex 0.5.6 as a means to smooth the stream of ticcmds going from clients to the server so that the server can process one ticcmd every gametic on average and keep players moving smoothly regardless of sudden spikes in network latency (also called network jitter). At the start of a gametic, the server will enqueue incoming ticcmds for each player and then process the first ticcmd in the queue. If there is a latency spike, the player will typically have a period where the server doesn't receive any ticcmds from the player and then will subsequently receive several ticcmds at once. The means the player's ticcmd queue will be shrinking (or empty) for a few gametics and then will suddenly grow with several ticcmds.

Problem:
When a player has a latency spike, they are often left with a ticcmd queue with several ticcmds. This creates additional latency between when the player sends the server the ticcmd and when the server processes it. Additional latency is undesirable and Odamex attempts to reduce this latency in a couple manners.

The server will process all of the ticcmds in a player's ticcmd queue when the player is dead, since the dead player does not require smooth movement. Additionally, if a player is not visible to any other players, the server will process 2 ticcmds once every 0.5 seconds as well as if the player is standing still.

Although these methods allows the player reduce the size of their ticcmd queue, it is far from ideal. Odamex may need other ways to reduce the queue size. I hope to gather data regarding ticcmd queue size during gameplay for informational purposes.