* 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
* Fix scheduling vehicle set-backs: disabled by default.
* Adjust detecting already set set back in morepackets (vehicle).
* Always warn if a set-back gets overridden.
* Adjust debug logging and comments.
* Some data loss.
Looks like we're running into set-back loops, unless we can control this
otherwise. It's more safe and consistent for our context, however it
leads to nested events. Vehicle exit, player teleport and vehicle enter
will fire from within handling whichever event the vehicle checks got
called from, such as vehicle update, player move, vehicle move.
Possibly some justTeleported flag helps us here. Likely there is no
similar switch that we could use with scheduled set-backs. The proper
option would otherwise be, to use packet sending and/or even cancelling
packets selectively, which would more or less force us to hard depend on
ProtocolLib for supporting basic features of Minecraft, despite possibly
a
sensible move anyway.
* Implement VehicleMoveInfo and provide via AuxMoving.
* Use MovingData.resetVehiclePositions to reset past location on enter.
* Some auxiliary functionality.
* Route vehicle update and move through the same checkVehicleMove
method, to initialize things, making some decision about what locations
to use for from and to, and to ensure that firstPastMove is set.
* Adjustments and fixes (workaround for generics with PlayerLocation,
LocUtil.hashCode).
Prepare using VehicleUpdate and PlayerMove instead of VehicleMove for
vehicle moving. This change isn't intended to change
anything/much on the surface.
* Implement native IEntityAccessPositionAndLook for 1.9_R1 and 1.9_R2.
* Alter method visibility and parameters.
* Common pre-conditions.
* Route contents of both VehicleUpdateEvent and PlayerMoveEvent through
a common related method (also named onVehicleUpdate).
* Remove RichLivingEntityLocation, to be able to simplify more.
* Refine interfaces for locations (IGet... ISet... vs, I... for both).
* Implement location related interfaces in some places, related changes.
* Override hashCode for some of the location related classes. Use that
for storing location hashes instead of Location.hashCode. Auxiliary
methods for hashCode in LocUtil.
* Add onIce to LocationData.
* Renaming player vs. vehicles (likely incomplete).
* Possibly other related/random changes.
Line count is high for this change, despite not so complex. Next step is
to change VehicleChecks to use past move tracking to estimate from where
a vehicle is moving (left not compiling). Due to the lack of teleport
events, and due to entity last location being mostly useless, we have no
choice but to hard-set-back on anything that looks strange.
