* Cancel/alter on lowest.
* Override cancel on set-back on highest.
* Adjust data on monitor.
Partly simplify, e.g. by just cancelling the event (nothing should
happen) - can't recall if there has been a reason to setTo(setBack)
instead of event.setCancelled(true).
* Call both most of the time.
* A convenience measure to have last move ground set, at the cost of
setting it 'too often' (players might not get checked by survivalfly at
all).
* Wrap calls with one PlayerLocation instance, for efficiency.
Move location-dependent properties from MovingData and MoveData to
LocationData.
Rough list of related Changes:
* Represent from and to positions as LocationData inside of MoveData.
* Have flags for onGround, inLiquid and the like in LocationData.
* Change noFallAssumeGround to touchedGroundWorkaround within MoveData.
* Add touchedGround to MoveData (to|from|workaround).
* (Remove involved properties from MovingData and use MoveData.from/to
instead.)
* Use MoveData and LocationData flags instead of PlayerLocation methods
in more places.
* Adjust various special case pre-conditions, based on past move data.
Other changes made on the fly:
* Allow maximum of jump gain and step height for ground -> ground.
* Add envelopes for vDistAir after teleport/join/respawn.
* Add cases for vdistrel.
* Extend logging on teleport (add cause, log set-back too).
* Reorder/fix vdistsb workaround checking.
* Reorder teleport handling.
* Remove small-range workaround for teleport [uncertain effect].
Immediate future follow ups:
* Attempt to only accept PlayerLocation for various setPositions methods
in MovingData (ensure to set MoveData with extra properties +
simplify/cleanup (public) methods with MoveData/LocationData).
* Relate to past move tracking for more workarounds, either to confine
pre-conditions more (inLiquid instead of toWasReset~somehow), or just to
be able to track a false positive at all (thisMove + 2 past moves
needed).
* (Fixes, etc.)
Distant future follow-up:
* Somehow merge with PlayerLocation, e.g. using LocationData inside
PlayerLocation internally, which means changing raw types to Object
versions, just like it's done inside of PlayerLocation right now.
* Possibly PlayerLocation is transformed to static methods with
BlockCache and LocationData as input.
Expected trouble:
* New/old false positives, due to replacing the fromWasReset and
toWasReset by more distinct flags from past move tracking.
* A workaround may have prevented other false positives
unintentionally, e.g. had been intended for liquid, but the
to/fromWasReset flags previously did include ground/noFallAssumeGround,
thus the workaround will not cover that case anymore, after the change.
* Forgetting something like checking touchedGround and to/from.onGround
or similar as a replacement for xyWasReset.
* Mixing up thisMove and lastMove for touchedGround.
* Mixing up touchedGround and touchedGroundWorkaround in MoveData.
This is a first version without any safeguards and without any settings.
A player who has any meta data for 'nocheat.exempt' is regarded exempt
from all checks. Suggestion is a boolean value (true), but setting
anything will do for the moment. Later String values or List<String>
might be supported to allow some kind of generic categories for
exemption (to be discussed with skill plugin developers).
This is not meant for permanent marking, but rather for "extra" events
like area damage with entity.damage(amount, damagerPlayer). The plugin
setting the metadata should also remove the metadata. In order not to
remove all protection by NoCheatPlus, plugins should fire extra events
or cancel events on a higher priority level than EventPriority.LOWEST.
To be continued:
* Relating to the 'allowed base distance' for horizontal moving allows
to judge speed without taking friction or bunny-hopping into account.
* Make use in bunny hop (seems to make 2-high ceiling + sprint jump a
little better).
* Later more workarounds should be confined to a minimum, using
MoveData.
* Namely walkSpeed, downStream.
* SurvivalFly: Alter method signatures to use thisMove rather.
* MoveData: Only initialize the necessary minimum.
* Add MoveData.alwaysInvalidated, to indicate random future purpose.
Should only be possible to happen, if an actions entry doesn't use 'ncp
delay ...' for teleporting, or if a hook teleports the player (both
discouraged).
Does break use of MovingData for last coordinates and distances (not
officially exposed API).
Other changes:
* Position resetting on teleport events has been altered.
* Some blocks/methods are guarded by checking for lastMove.toIsValid.
* Possibly other.
Also:
* Rename the walkSpeed constant to WALK_SPEED (nuisance to mix up).
* Alter conditions slightly in some places by using
thisMove/lastMove.headObstructed.
Issues remaining:
* Moderate speed increase with yDist 0 and hDist like 0.35 -> 0.45.
* Transitions head blocked -> not, can trigger hspeed violations.
* Remove extra conditions for from.isHeadObstructed in vDistAir.
* Account for yDistance in more places. Use the maximum of the default
margin and yDistance.
* Add a tag for not setting low jump, due to the head being obstructed.
Fixes:
* Issues with 2-high ceiling with normal ground.
Issues remaining:
* Ice floor + 2-high ceiling.
* Jump/bunny with head blocked, moving to where the head is not blocked.
There is a small chance that other plugin cancel these events. Since the
server ignores event.setFrom for cancelled events and also won't fire a
teleport event, this remains a problematic case.
Represents the first "simplistic" approach to block change tracking,
only attempting to make vertical push/pull work.
It seems that we need to add on-ground checking accounting for piston
moves as well, otherwise anything with pistons retracting will lead to
survivalfly violations. Pistons extending and retracting may also
randomly move around players, including dragging them into the piston
block with the bounding box (not center of player).
In order to make on-ground work, we might need to check in another
place, possibly check where resetFrom an resetTo are set. Performance
questions might remain, there might also be a slight redesign necessary,
in order to run some sub-routines more side-effect free, to check
several branches, including after-failure checking.
