cl_timenudge observations


(SCDS_reyalP) #1

Below is something I posted over on the TWL forums, but I’d be interested to see what other ET coders think. There is so much misinformation and myth surrounding this cvar, it would be nice to have it cleared up.

I am aware of arQons article on the subject (and subsequent statement that timenudge was made effectively placebo in most q3 games) , and the unlagged FAQ and code documentation.

Timenudge operates on the client system (as the cl_ prefix indicates). It affects the client time, which in turn affects how snapshots (information from the server) are treated, and the timestamps of commands sent to the server.

  • Using negative timenudge moves your client time forward, causing you to use more recent snapshots, even if this requires extrapolation. This gives you a warpier, but more up to date view of the server.
  • Positive timenudge moves your client time backwards, causing you to use older snapshots, even if more recent ones are available. This essentially simulates a higher ping, although on a fluxy connection, it could make things smoother as well.
  • Timenudge moves the command time of your commands sent to the server in the same way.
  • Regardless of PB or etpro restrictions, the game itself will never let timenudge actually go less than -50. It also caps the positive value. Although you can set the cvar to -500, it will only move your client time by 50 ms.

In etmain, timenudge is purely client side (in the sense that the server doesn’t do anything with your cl_timenudge value. Since it affects your command times, it does have some effect on information on the server.) The only reason the value is sent to the server is so the server can display it in /players.

It appears that when the pings involved are extremely low (< 10 ms) using -50 timenudge can have a small impact on how you show up on other peoples screens. This is due to another bug, but from my testing it happens rarely, even on a 100mbit LAN. The timenudger must have high FPS, high maxpackets, and a sub 10 ms ping. Even then, the resulting delta is quite small. If the timenudger is playing on the internet, this will never be factor. (note: this is due to the g_smoothsclients thing, but in practice, should be a non-issue)

Previous versions of the rules have restricted timenudge, to 0, -20 and -50 at various times. The current rules do not restrict it at all.

Since timenudge affects both your client time and command time equally, it should not cause problems in conjunction with antilag (caveat: I don’t know what etpro might do) unless you use a negative value of greater magnitude than your ping. However, I don’t see any good reason to use it with antilag.

Note: Unlike 99% of the information floating around the net about timenudge, the above is based on actually printing out the values used by the etmain game/cgame, not hearsay, speculation, or feel. Of course it is still possible that I have missed something important.


(Rain) #2

cl_timenudge is clamped to -30 … 30 in the engine, btw.


(Korollary) #3

The good reason to use a negative timenudge with or without antilag is to release snapshots sooner. I have been mostly q3 nowadays and most of the good players use -30 so that the other players don’t have an advantage over them.

In RTCW days without antilag, I used the minimum value allowed since it released snapshots sooner and descreased the distance I had to lead when aiming.

With a working antilag, there is no need for negative timenudge. I think the leagues should force 0.