Suggestion #13983

Latency Normalization Techniques for Combat

Many players are geographically far from the server's location, and even with the fastest internet speeds they still will have high latency due to the number of network hops from the client to the server. due to that, a massive portion of the playerbase on EC has high latency, which drastically affects combat; either lower latency opponents get an advantage, or the higher latency opponents get protected by server desync.

Below i propose two ideas that could mitigate the complaints and issues players face during combat in regards to latency:

1. Proxies
As a previous suggestion by 'xStarxFly_' mentions, many popular servers implement regional proxies that allow players who are geographically far from the server join to the closest proxy to them while still joining the same server everyone else plays on regardless of which proxy they joined from. the count and placement of those proxies would matter a lot for improving players' latency. the cons to this method is the financial investment needed to establish and maintain those proxies. whether it is an investment that is worth it or not is up to the owner to weigh on.

2. Latency normalization through a plugin
This original idea could be taken as absurd and impractical at first but with proper implementation it has massive potential for improving combat all around the server.

In short; the server would artificially delay an opponent's packets in combat to match the other party's latency. the objective is not to reduce latency, but to reduce the disparity in latency between two players during combat.

Here's the elaboration:

Minecraft servers process packets asymmetrically, and with a huge latency gap, high latency players are harder to predict in movement and have both delayed knockback and seemingly impossible hits that often are misjudged as hacking or reach edits.
by limiting a lower latency player's connection to deliberately throttle it to match the higher latency opponent, both players would experience the same delay resulting in a fair fight.

From a technical perspective, this is feasible since the server already runs on paper, and plugins such as ProtocolLib already intercept packets. to put it simply, the server can intercept a player's packets and hold them in a queue then release them after a dynamically selected amount of time. moreover, not all packets should be limited as rubber banding/inventory lag/ghost hits/etc. are problems that arise from limiting the entire connection; a selective implementation that targets only the networking relevant to combat, rather than delaying every packet, would likely be preferable to avoid the aformentioned issues. it might seem like a massive technical feat, however a competent developer could investigate implementing such a system either through ProtocolLib or by modifying paper's networking stack.

As an example, take a player with 40ms ping facing a player with 180ms. the 40ms ping player would get throttled till they reach ~140ms latency to match the 180ms player as much as possible to eliminate massive desync issues.

In terms of implementation, this feature if implemented should only activate when a player enters combat, e.g. entering ct or queueing in match in /go pvp. furthermore, there should be a cap to how much latency the opponent is throttled, for example the max latency the artifically throttled player could have is 200ms/250ms.

I present a pro and a con for this suggestion:
A pro is that if this feature is implemented successfully, reports of suspicious reach would likely decrease because many situations that appear to be illegitimate are actually caused by significant latency differences between players, and ping/vpn abuse would be rendered useless as that is also a widespread issue on the server that is undetectable and isnt currently being combatted.

And a con is that even if this feature is implemented to activate only when combat is initiated, players might dislike having unnecessary higher latency. a lot of players enjoy playing on lower latency against higher latency players while a lot of players complain of the issues higher latency players cause. no feature added can appease all people so the cons and pros should be weighed carefully.

Ultimately, it will come down to staff/the owner to decide on whether this trade-off, making some low-ping players intentionally feel laggier, is worth the improvement in competitive consistency. it is quite the large project to embark on, but since the feature is suggested to only affect combat, it is at least worth discussing the idea.

Thank you for reading, and i wish to hear the staff and the community's thoughts on this suggestion.