Horizontal speed rework (bunnyhop, strafing, sprinting …)

[Lysandr0]

This ticket is meant to aggregate everything related to SurvivalFly’s horizontal movement handling, which needs to be recoded.
The general idea/direction is something more similar to how vDistRel (relative vertical distance) treats vertical motion:

• 
Estimate the relative allowed speed based on MC’s calculations.
• 

Compare estimated distance to workarounds for special/odd cases (medium transitions in this game are fun :) )

• 
 Finally, a VL if distance is above limit and no workaround matches.
• Also monitor the distance taken in 3d/2d (strafing): INDEV conceptual: detect unrealistic direction changing (in-air-strafe + form of speeding) NoCheatPlus/Issues#431
  (ISSUE: PlayerMoveEvent thresholds, split moves)

In order to achieve this however, several other points have to be tackled first (in order of difficulty/time-consuming):

• A proper latency-compensation system
• Workaround explosion velocity
• Liquid pushing speed
• Fix ground status being detected when it shouldn't.
• (Mostly done) Correct block shape definitions for lower MC versions (< 1.17. From 1.17 and above we have this useful method https://hub.spigotmc.org/javadocs/spigot/org/bukkit/block/Block.html#getCollisionShape() )
  This is important to get friction and slipperiness correctly.
  Related commits history:
  9293cde
  ae62126
  b2d015a
  7d01b45
• Better and more reliable handling for sprinting and sneaking. 

  This means that the assumeSprint workaround that was introduced 9 years ago has to go (Which is more complicated than one might think due to the bloody desync issue on the server-side; there's a good reason if asofold kept such workaround for so long)
• Indirectly related: handle levitation and slowfall with SurvivalFly to prevent any possible abuse of Fly check switch
• Continuing review of vDistRel workarounds (and prevent misuse). Leaving liquid workarounds in particular.
• Refactor of all lost ground cases, removing duplicate ones and confining them more (https://bugs.mojang.com/browse/MC-90024);
• Complete rework of the horizontal friction system (Implement a block friction library in BlockProperties, vertical isn't concerned for now).
• At that point, the current bunnyhop detection mechanism will be replaced/recoded as well.

Follow ups:

• Re-add sprinting checks (omnidirectional sprint)
• Horizontal velocity handling: implement asofold’s suggestions to limit abuse of queued entries. Simply recording the absolute distance between used and received location is already a good safeguard.

• Horizontal accounting will be obsolete by then. Either repurpose it or simply remove it.
• The horizontal buffer will be obsolete as well. Could get rid of it OR, leave it and introduce much, much stricter conditions for regaining levels.

As always, any more ideas/inputs/suggestions are much appreciated.

[Regomy]

I'm waiting, really waiting =)

[ghost]

I'm waiting, really waiting =)

[xKumorio]

I'm waiting, really waiting =)

[LatiBlueLatios]

I'm waiting, really waiting =)
(Can't wait to find a bypass trol)

[Lysandr0]

Pull requests are always welcome :)
I'll try to briefly summarize what needs to be done before publishing a first beta build:

• Port/Code Mojang's 1.20 bug fix for walking on blocks with motion properties (See: https://www.youtube.com/watch?v=_UT8hLb60NQ)
• Handle sneaking in some way: sneaking is broken on newer versions, for whatever reason. We still need to investigate this further.
• Entity pushing needs a more stable handling (simply allowing some grace isn't enough)
• Slime block and powder still need to be implemented properly (attributes ... )
• Probably the biggest obstacle to overcome: handle ground detection mismatches.
  We do not use Minecraft's 1:1 collision logic; we use our own instead. What this means is that there can be cases where Minecraft and NCP don't agree on the player's ground status: sometimes, we detect players to be on ground when they actually aren't. Other times, we miss a ground collision that the game would instead pick up.
  Ever since its release, NCP has been dealing with this through some hacked-together, hard-coded workarounds , which has been an alright (but convoluted) solution for something that did not require high-accuracy, at the time.
  Now that we have switched from a limit-based speed check to a predictive one, we cannot afford to maintain such system (at least not if we want to preserve our sanity 😛 ). At the same time, reworking the "on ground" logic would also mean mostly scrapping NCP's current collision system, which -as you can imagine- would prolong all of this even more.
• Then, there's vDistRel hat needs to be reworked: again, now that we have switched to a predictive system, the horizontal prediction relies on the vertical one to rule out bypasses. That is, if we want to avoid bunnyhop exploits, the vertical prediction (which NCP has been doing since 2015 by the way) needs to be much more accurate than the current one; which is even worse, in terms of readability and maintainability. Fortunately, it is not as complicated as the horizontal handling to do, but still.
• Lastly, there are some annoyances to take care of, like:
  • players being able to essentially "double jump" on stairs: thanks to the auto-jump feature, players can BOTH step AND jump at the same time on stairs, resulting in a double speed increase. However, on the server-side, there's no way to distinguish.
  • Although coded, liquid current is still glitchy
  • Some false positives when sneaking on edges
  • Riptiding from the ground: the game increases speed by 1.29999
  • Probably unify elytra in SurvivalFly instead of CreativeFly.

[Doogie13]

No more 2014 speed modes bypassing :3