Mostly for legacy Player instance getting, future aims are:
* Efficient lookup by name.
* Efficient lookup by prefixes of names (e.g. for command use).
* Efficient lookup name->uuid and uuid->name.
* Keep name->uuid mappings for history lookup and similar.
Refactor
* Move hasBypass code to CheckUtils.
Efficiency
* Alter/add methods for testing with with optional check data/config.
* Use more efficient calls in several places (unfinished).
Consistency
* Log an error, if calling hasBypass off main thread unexpectedly.
* (Mostly irrelevant null checks.)
This should prevent bouncing higher and higher (cheat).
Missing:
* The bounce effect should be set considering the last yDistance, in
order to allow negative vertical velocity to work.
* Add workaorunds for gravity with exiting cobweb.
* Allow multiple times zero y-distance (cobweb several times, slime 2).
Cobweb may need adjusting the bounding box to check with, instead.
* The server might reset the fall distance with preceding micro-moves,
so use NoFall data already on checking pre-conditions for bounce.
* Cap the bounce effect slightly smaller.
* Renew the bounce effect under certain conditions.
* Gravity, odds.
Remaining:
* Two consecutive times yDist = 0 at the maximum of a jump.
MISSING:
* Micro move onto ground, fall distance resets before sf check is run.
Done:
* Split PlayerMoveEvent processing to from -> loc + from -> to. Just if
from isn't the same coordinates as player.getLocation. This
reduces the complexity of workarounds.
* You do take fall damage falling onto slime blocks while sneaking.
* Queue bounce effect, only if the move is valid. Skip NoFall then.
* Apply bounce effect once moving up, to allow overriding.
* Cover more odd cases.
Unrelated:
* Use data.debug instead of cc.debug.
Adjust workarounds, confine velocity activation to next tick.
Cases missing:
* Lost ground cases (yOnGround has been reduced, strikes here).
* Two consecutive yDist = 0.
This will preserve the order of debug messages sent from multiple
threads. As a side effect, this might be better for performance, given
that on constant input the logging task will stay registered, so there
is little overhead and the file-io is taken off the asynchronous packet
and chat handler threads.Hopefully the thread switching is less
expensive than the gain by not delaying chat/packet threads, in case of
servers with few cores. We might adapt the used policy later, based on
cores and/or config.
* Queue outgoing positions in order to detect ACK on incoming.
* Since we can't detect relative teleports, positions are only queued,
if they match an absolute location from a teleport event (Bukkit).
* The queue is kept simple: only store the latest position.
* Cancel incoming flying/pos/look until ACK is received.
Missing:
* Are yaw/pitch are ever sent back changed.
* Configuration to turn it off.
* Might use this to just skip all violation handling until ACK.
This is a quick go with little testing, roughly up to level 60. Above
that there may be more false positives, also "no jumping" is not
enforced there.
A suggestion for the future could be to just use/part-calculate an array
for all the typical effects.
Used to be 0.0625 for a while, but intentions are to cover ground-loss
as lostground workarounds. Later switch to calculate the distance to
ground (with a given max-distance).
For efficiency (several?) other cases will be removable, once we model
the per-move ground/medium properties more accurately also for the past
move(s). At least lostground_pyramid should be removed then.
