KeepAlive interval configuration

[andreypfau]

Is your feature request related to a problem?

Motivation

The real latency of the player is displayed only after 15 * 3 seconds, before that, in the first 15 seconds of the game, it is displayed that the player has a latency of 0 ms

Now its hardcoded to 15 seconds, please add configuration to change it

As addition also provide configuration for the ability to change the coefficient of the arithmetic mean:

Describe the solution you'd like.

Configuration for KeepAlive interval (and/or coefficient of the arithmetic mean) for via System properties or paper config

Describe alternatives you've considered.

Fork paper and changes by myself

Other

No response

[Malfrador]

Adding a config option for something that can very easily completely break client connections completely and that potentially will have some conflicts with vanilla changes in the future just to fix a 15 second visual issue seems a bit much to me. The client relies on a certain order of things happening on login, allowing for changes here seems dangerous.

Additionally the ping on login will be very unreliable due to the large amount of data sent anyways. The ping display in the tab list also just differentiates between less than 150ms/300ms/600ms/1000ms/more, making it mostly useless and really not a place where accuracy matters at all.
Unless there is something else this would fix outside of a very small visual issue, I don't think this should be in Paper.

[electronicboy]

The reason why the keepalive is delayed for 15 seconds is because otherwise the keepalive would be sent during the client being spammed with login stuff which was creating overly inflated ping values, or just leading to outright kicks from it

[Cryptite]

I'm not in 1.20.2 yet but FWIW I have changed this to 5s locally in my 1.20.1 fork and have never experienced any issues that i'm aware of and considered PRing a config change myself.

We use it to show more granular ping updates to players themselves which we derive from measuring Keepalive packets.

If clients are failing to login due to 1 or 2 extra keepalive packets, arguably they have bigger problems.

[electronicboy]

The issue wasn't the extra keepalive packets, the issue was generally the keepalive packets would end up on the tail end of the flood of packets from login + initial chunks, which the client would effectively stall out

The configuration phase and the chunk limiting stuff in paper (and now vanilla) should mostly aleviate the need for my patches to revert back keepalive behavior, it was just generally a sense of "we're not kicking clients during login all the time for this now so imma no touchy"; I have nothing against a PR for the interval