An implementation for NCPCompatBukkit is missing.
Note that the native access can not set lastYaw nor lastPitch in
PlayerConnection (private), but it could set lastYaw and lastPitch in
EntityPlayer.
Can't guarantee this actually helps with stuff like derp/magnet, because
we can not really set the outcome of a PlayerMoveEvent without
rubberbanding the whole planet. Hacks could send enough packets per tick
to keep freezing people - we might be able to keep track of yaw/pitch
correction and cancel (most) attacking for the same tick after yaw
correction (invalidate "same" with in-bounds yaw).
"Magnet" refers to a player seemingly freezing other nearby players onto
the spot, causing them to yaw-glitch, seemingly getting attracted by the
cheater.
Thanks again @Iceee for reporting and @Amaranth for finding cause +
suggested fix.
Not sure this both helps and prevents false positives, so it could get
redone a couple of times, might also result in being impossible to fix
with a plugin in an acceptable way.
- Never skip undoing changes. This is necessary to also process commands
that are not registered or that are fall-back aliases.
- Check adding all plugin commands always.
- Check for aliases as well for decision if to match a command.
These seem not to have been affected beforehand, due to the nature of
the SimpleCommandMap, however we don't want to exclusively rely on
fetching that one successfully.
Setting a set-back location with a null World will now lead to a
NullPointerException. Setting null worlds on set-back locations is not
intended by contract, however due to using temporary Location instances
with Entity.getLocation(Location) and setting the world to null
afterwards to prevent memory leaks, also considering the number of
places where setSetBack is used, this seems to be an appropriate measure
to track better or help excluding violations of that contract.
This does not change the used methods much, thus it will rather allow
much more cheating, however it allows some basic testing for false
positives. The reach implementation has been slightly optimized to run
faster. The current implementation is not final and only uses trace
elements that were added in the current tick, the latest is always
included.
Next steps will probably be:
* Stricter methods for an individual TraceEntry (demand near-exact hit).
* Don't allow random latency shifting. Maintain a window-thing.
* Probably get rid of the classic method for attacking other entities.
No change for the function of the plugin, except if there are new bugs.
Actual changes:
* Keep track of squared distance to the previous element in a trace.
* Balance mergeDist: prevent merging the latest entry, if the squared
distance from the latest to the second latest element is greater
than mergeDist. Never merge if there are only two entries in total.
* Add convenience methods for resetting and updating the trace.
* Maintain the moving traces actively. With intended use being
player-player interaction, we will not reset with every teleport.
Just the raw implementation + initial test cases. To keep memory use
constant, a ring-buffer with some maximal size will be used. The
iterators are meant for faster implementation, rather than fastest
iteration. Later some trigonometric functions could be added to
LocationTrace, depending on if that may gain a lot of performance.
Next we will add the logics for adding entries and resetting the trace
to NCP (moving, teleporting, joining), on Logout the trace must not stay
in MovingData but should be garbage collected. That should be a
milestone dev build, though it does nothing for the user, it might help
finding crash bugs :p.
Soon to follow will be changing some fight checks to be able to use the
moving trace, then alter them to actually use it. Fight and interact
checks could also do moving consistency checking (tp exploit).
Who reads this?
The cancelled BlockPlaceEvent will lead to an extra sign being dropped,
while the item in hand stays. Odd enough, the cactus is removed before
the BlockPlaceEvent - need to check if a ticket exists for CraftBukkit
already...
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.
