[Calinou]

This needs playtesting before it can be merged. While this should be fine on paper, it's possible that this is too much for less-than-ideal connections (4G, distant servers, …). I can host a 24/7 server with this pull request if this is desired 🙂

This decreases effective latency significantly by making clients and servers sending and receiving updates sooner. This increases network traffic by a factor of 3, but it should be manageable on today's networks.

The average game-induced latency (on top of network lag) should now be 14 ms (10 ms server + 0-8 ms client) instead of 60 ms (40 ms server + 0-40 ms client).

See https://extra-a.github.io/#bnet for more information.

[qreeves]

Needs further testing and discussion.

[q009]

The idea appears worth exploring to me. However, I think it'd be worth to put those behind variables, so the users can tune those. So, worst case scenario, the gist of the change may remain, only the final value of the variable would see further tweaks.

[qreeves]

We revisited this and tried reworking it along the lines of q009's review: the update interval became a server variable (default 40 ms, so nothing changed unless an admin set it), and the timings tuned for 40 ms followed it. We've decided not to go ahead for now, but here are our findings for anyone picking this up later.

Measured bandwidth (private local server, two clients plus bots, steady state over 10 seconds):

	40 ms (25 Hz)	10 ms (100 Hz)
Server upload	12.4 KB/s	32.3 KB/s (2.6×)
Server download	13.3 KB/s	33.6 KB/s (2.5×)
Client upload	~5.5 KB/s	~13.6–18 KB/s

The increase is less than 4× because much of the traffic is events rather than positions, but it grows with player count. Demos record every world state, so they would grow too.

Code tuned for the 40 ms rate:

• Remote player smoothing. smoothmove (100 ms) blends each position correction over about 2.5 updates at 40 ms. Simply scaling it with the server's interval breaks down for players who can't send that often: a client sends at most once per frame, so at 10 ms anyone below 100 fps sends less often than the interval and would look jerkier to others than today. A proper fix would smooth over each player's actual update gap.
• Dropped flag and bomb updates. capture.cpp and bomber.cpp send these on their own 40 ms timer (totalmillis%40).

Client send timing. c2sinfo() sets lastupdate = totalmillis on every send, so the timer drifts to the next frame each time. At 60 fps the client actually sends every 50 ms (20 Hz), slower than the server's 25 Hz, which is the "slipped frames" effect mentioned in this PR. The server keeps its schedule (lastsend += millis - (millis % 40)) and doesn't drift. Fixing the client would slightly change current behaviour (about 25% more client packets at 60 fps), so it should be looked at deliberately rather than as part of a rate change.

Compatibility. Old clients silently ignore unknown server variables, so a server variable would be safe to add; they'd keep sending at 40 ms.

Not tested: real internet conditions (jitter, packet loss, distance), full servers, and low-end machines. Any future attempt would need a public test server before changing defaults.

Leaving this open for further discussion.