PingRequest

Measures round-trip time to the game server: send it, wait for PongEvent, keep the delta.

TWO SENDERS, AND ONLY ONE OF THEM IS A TIMER.

THE AUTOMATIC PROBE sends quiet = true. A timer re-arms itself every INTERVAL ms, but a tick only sends if the player touched an input device since the previous tick:

every INTERVAL ms:
    if input_seen_since_last_tick:
        input_seen_since_last_tick = false
        send PingRequest(quiet = true)
    re-arm

INTERVAL is 5 seconds when the client's fast-ping option is on and 10 minutes when it is off. There is no third value, no jitter and no back-off.

THE CHAT CONSOLE COMMAND 'ping' sends quiet = false, once, immediately, with no gate at all. Its sibling 'aping' prints the stored average and sends nothing.

THREE PROPERTIES OF THE INPUT GATE DECIDE WHAT YOUR TRAFFIC LOOKS LIKE. It is a LATCH, not a counter - ten thousand input events between two ticks produce one ping, not ten thousand. It is CONSUMED by the tick, so two consecutive pings need input in two separate intervals. And it is read BEFORE the send, so the first tick after an idle stretch is silent.

WHAT COUNTS AS INPUT IS NARROWER THAN IT LOOKS. The latch is set only while a keyboard key or a mouse button is held, or a movement axis is off centre. Moving the mouse without pressing anything does not set it, and neither does giving the window focus back. Gameplay does not set it either: a character walking a route under script control produces no input at all.

A CLEAN PERIODIC PING STREAM IS A STRONGER ANOMALY THAN SILENCE. A real client cannot produce one - with the input devices untouched it sends almost never. A capture of an active session shows pings roughly ten seconds apart while the player was moving: irregular, not clockwork. If your script never touches an input device, the faithful behaviour is to send this rarely, or not at all. The gate is a traffic-shape rule, not a legality rule - the server answers a ping sent at any moment.

ONE PING AT A TIME. The client keeps a single outstanding send timestamp: stamped on send, cleared by the reply. A reply that arrives with no outstanding send is discarded and produces no sample, so pipelining pings gets you fewer measurements, not more.

WHAT HAPPENS IF NOTHING COMES BACK. One second after each send the client raises its lag indicator, and lowers it again when the reply lands. Nothing is retransmitted and nothing is torn down - the exchange simply stays unanswered.

THE SAMPLES ARE NOT DECORATIVE. Each round trip is appended to a rolling buffer of the last 50, and the average of that buffer is the number a real client reports when the server polls with BasicLatencyStatsEvent. A script that never pings has no honest value to put in BasicLatencyStatsRequest.