MCAccess will be split into smaller providers with time, so do expect
more breaking changes of this type. If this is an issue, please contact
us, so we can see how to smoothen things. E.g. we could still make
MCAccess an aggregate, that just delegates to the more fine grained
providers, or we could provide other
(default) aggregates.
This also adds a Bukkit-based provider for future updates.
* Call removeInvalid if many elements are queued on add (cheat not
sending moving events, player takes damage), and on clear, in order to
allow detection of unused velocity with not sending moves.
* Add get+set for unusedActive.
Simplistic unused vertical velocity tracking for starters. Only
activates with debugging set.
Needs on-the-fly debugging (all) or at least debug set for moving
(config: checks.moving.debug: true), and needs debug set for fight to
check on damage/attack (config: checks.fight.debug).
Method is simple, roughly: Keep track when the player has last been on
ground, or when their head had been blocked. Based on that, we can
attempt to judge if invalidated velocity entries might be cheating.
There is more aspects to cover, and this is not a check, it just will
debug information to the log file. Would appreciate feedback on if/what
this will log with noknockback cheats on :) (false positives are most
welcome as well).
* Account for off hand in more places.
* Use bridge methods to get rid of warnings for now.
* Adds utility methods to CheckUtils.
* Do not allow left click on off hand (knockback).
Since merging by distance only creates false positives (one would have
to increase the bounding box for an entry, but the angles would never be
100% right), we never merge, instead we don't add a new entry if the
position is the same, the time value is not updated in this case. For
validity of an entry you always have to consider the time span until the
previous (younger) entry or until now for the latest entry.
Rough changes:
* Use an interface for accessing trace entries.
* Use a linked structure for the actual trace.
* Use maximum age and size to limit the number of stored entries.
* Use a pool to somewhat limit object creation (size may need
configuration or scaling with number of players).
* Since the trace starts empty, have the field be final.
* Keep trace elements if settings are changed, cut size if necessary.
* Remove obsolete tests.
Potentially missing:
* Usage of LocationTrace has not been checked if we need to account for
the time of the latest entry not necessarily being updated (!).
* New tests, e.g. accounting for the expiration of entries.
Follow ups:
* (Extend fight/loop checks to a latency window mechanism.)
Upcoming changes will roughly be:
* Change implementation to a double linked structure.
* Implement/use something like ListIterator.
* Never merge entries, instead use some pool and time/extre-n as limits.
* A basic latency window implementation just for the LocationTrace for
preliminary experiments. [Track hit/miss all time + recent so and so
seconds, some extra cancelling/invalidation mechanics, allow to test
complement 0->window start and possibly window-end-> max latency for
some cases, cancelling mechanics may contain a buffer or a mixture of a
buffer relating to average miss rate]
Wild card exempt NPCs by default, encapsulate meta data checks here (if
exempted, if is NPC).
With these default settings Citizens NPCs should be exempted by default,
also all custom Player implementations that extend the Bukkit interface
NPC (not sure if such still exists).
Follow ups:
* Configurability.
* Exemption tickets to prevent others overriding your exemptions
(later).
Kept configurable to enable increasing difficulty for fly plugins use,
e.g. to allow players to fly within certain regions, but still deal fall
damage on falling.
Section at: checks.moving.vehicle.envelope.hdistcap
Default is 4 (extreme move fall-back) at 'default'.
Other entries by bukkit entity type name, if desired.
This allows forcing set backs for testing in a convenient way, e.g. with
setting the value to 0.3 for boat/default.
Main objective was to not reset the set-backs on setting back a vehicle
with a player, plus data resetting cleanup.
Specific changes:
* Prefer an existing set-back, in case the default one has been
invalidated.
* Do not cancel a vehicle set back task, in case no set-back is present.
* Avoid multiple resetting and redundant calls for resetting positions.
* Ensure the location set back to is set as a set-back location after
set back.
* Skip changing vehicle data with player moving resetting (e.g. player
teleport, player morepackets disabled).
Review and possibly correct/alter use of:
* MovingData.vehicleMoves.invalidate
* MovingData.vehicleSetBacks
* MovingData.clearMostMovingData
* AuxMoving.resetXYPositions
* MovingData.clearVehicleData
* MovingData.clearVehicleMorePacketsData
* MovingData.clearAllMorePacketsData
* MovingData|AuxMoving.resetVehiclePositions
