Increase default cl_maxfps and cl_maxpackets to 125

[Calinou]

• Related to https://github.com/ec-/Quake3e/pull/299.

This provides a more responsive gameplay experience with more consistent input handling. The new defaults also correspond to integer millisecond values (8 ms per tick), which avoids issues related to rounding.

rate was also increased accordingly to ensure all packets are sent (the new default matches sv_max_rate). This could help address #219 too.

I've been using this configuration for years now and it works just fine, even on an average ADSL connection (before I had fiber).

[skullernet]

Can you define what more responsive gameplay experience is? Low cl_maxpackets value should not affect gameplay experience in any way, but helps to avoid polluting the network with many small packets the client sends when running at high frame rate. Granted, internet links are much faster now than 15 years ago, but that's not an excuse to generate more useless traffic.

Not sure if increasing cl_maxfps to 125 is a good idea as well. cl_maxfps does affect player movement, and higher cl_maxfps is not always desired. Since running the client at 125 FPS was hardly possible in 1997, sticking to 62 FPS default is preferable.

Perhaps this is less relevant now, but there were servers out there that would kick you for having cl_maxfps higher than 120, or rate above 15000, so this should be considered too before changing defaults.

[joe0x04]

While cl_maxpackets doesn't affect gameplay at all, it does affect ping reporting by clients: that "sawtooth" pattern where pings jump around. I know it's just an artifact of protocol 36 and doesn't affect gameplay, but players don't seem to understand that, no matter how many times I explain it. They just see a ping value higher than they like, or see it bouncing around and assume the server is on a bad connection and they leave. I started setting cl_maxpackets to a minimum of 100 via q2admin for popular servers (ex. pf-de3), and players tell me how their experience is so much better. It's all in their head...

[Calinou]

Can you define what more responsive gameplay experience is?

If input packets are sent more often to the server, it's more likely that the server will get your latest inputs in time for the next server tick. It also reduces the visible jitter on the server's end. Also, if one of your input packets gets lost in transit, it's less likely to have a significant impact on gameplay. The rationale for this is described in detail in the Better networking section of the sauer-sdl2 homepage (this is not id Tech, but the principle is similar).

cl_maxfps does affect player movement, and higher cl_maxfps is not always desired. Since running the client at 125 FPS was hardly possible in 1997, sticking to 62 FPS default is preferable.

This is true, but it seems a lot of competitive players are now used to cl_maxfps 125 movement. This particular value allows you to jump a bit higher than usual (like in id Tech 3, although less extreme than com_maxfps 333 there). This means it's been a staple for competitive play for a while now.

(Note that cl_maxfps 120 is often mentioned, but the value is rounded to the nearest millisecond, so in practice, you could either use 111 (9 ms per tick) or 125 (8 ms per tick) but not something in between.)

Perhaps this is less relevant now, but there were servers out there that would kick you for having cl_maxfps higher than 120, or rate above 15000, so this should be considered too before changing defaults.

I've heard about this too, but I've never been kicked on a server because of cl_maxfps 125 or rate 60000 (I've been playing since 2014).

[kke]

I've heard about this too, but I've never been kicked on a server because of cl_maxfps 125 or rate 60000 (I've been playing since 2014).

Q2jump servers kick you out if you set cl_maxfps over 120.