Message Boards

Topic: Ticcmd queue discussion  (Read 7248 times)

Offline Dr. Sean

  • Developer
  • Posts: 69
  • G'd up from tha feet up
    • View Profile
    • Odamex - Helping middle-aged men relive their teen years
Ticcmd queue discussion
« on: September 04, 2012, 15:53:41 »
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.

Odamex Development Team Member

Offline Pseudoscientist

  • Posts: 43
  • Peanut gallery
    • View Profile
Re: Ticcmd queue discussion
« Reply #1 on: September 05, 2012, 03:40:41 »
Quote
I hope to gather data regarding ticcmd queue size during gameplay for informational purposes.
Is that your "ticcmd_queue logging test" server?

I'll repeat my (draft) proposal.
Just trying to make the player move slowly enough is not quite correct; Doom doesn't allow you to stop suddenly unless you crash into an object or a wall. So speed should be changing slowly as well.
Not knowing a few consecutive ticcmds doesn't introduce much uncertainty to player position. (It grows quickly with the number of ticcmds, though.)
The current behavior, however, somewhat helps client experiencing a short latency spike by suddenly stopping them and thus disrupting their enemies' aim. Creating artificial latency spikes is, however, useless for cheaters, because of the additional latency which can't disappear at cheater's will (the queue on the server).
Ticcmd queue is also, in effect, an anti-speedhack. This should be preserved also.
Thus, I propose the following:
- If the server stops receiving ticcmds form the player and exhausts the ticcmd queue, start to estimate possible player positions. As long as uncertainty doesn't exceed some threshold OR the player cannot be visible anyway, predict the player position and increment the player's counter. (Client probably should be aware that player's position is server's speculation.) When it does, stop predicting.
- When the lost ticcmds arrive, immediately execute counter commands, set counter to zero, and put the rest in queue.

Notes:
If we're uncertain if player will cross a special line, stop predicting.

Problems:
- If the player firing command was lost, it might have been better for him to be "frozen" and hope the enemy will miss adn his own shot will hit.

In coop, ticcmd queue doesn't help much but ensures that monsters will kill you. It probably should be off in coop configs.
Sorry Guest, you are banned from using this forum!