Now players are forced to create moving events with CraftBukit,
in order to get above the trigger-distance, thus moving checks can
complement this (in theory).
This could lead to more false positives.
This is a workaround for the case that sprinting events are missing,
wrongly set up or for events firing in an unusual order.
This does allow speeding hacks that allow players to go at sprinting
speed without telling the server, so it should only be turned on if
there is any issues.
The option has to be turned on: checks.moving.assumesprint
Refactored penalty time handling to use a PenaltyTime object, taking
into account time running backwards, also unify attack (close combat)
penalties to a generic attack penalty. Combined.yawrate still keeps the
timeFreeze penalty, due to also cancelling other actions than melee,
still changed to a PenaltyTime object.
Changing the item in hand now leads to an attack penalty (that also goes
for not changing the item, but changing the slot).
"Quick" addition, not much testing, except few unit tests.
Note that this could change false detection behavior of other sub-checks
of fight, because the penalty time is checked last. Previously checks
like direction or reach would have cancelled already if the player was
within their penalty time. Hard to say if this creates new false
positives, but it will be more strict on continuous violations.
This will probably not be pulled through for all checks, because
the overall design does not support to do this in an efficient way.
Some checks will be added to allow pinpointing data removal,
mainly to allow compatibility tweaks, e.g. with actions.
Roughly this line of develpment has to do with:
* Prevent destroying ones own vehicle [INCOMPLETE: conflict with older
MC versions.].
* More careful set-back handling.
* Reset the players position to that of the vehicle if the player moves
too far off (likely does not have effect, needs more testing). In
principle this is intended to trigger a teleport, the normal player is
intended to not notice, but no guarantees yet.
Not configurable yet, might not work 100%, yet.
There seem to be cases with a repeated horizontal speed increase which
should be covered by the bunnyhop mechanisms. The first increase will
not go as high as possible but have 0 y-diff, while the second one will
trigger a violation with a higher y-diff and another increas in the
horizontal distance. This commit does not cover a general multi-step
speed-increase case, but just attempts to catch this special case.
