For whatever reason it was commented out, it is now put back, assuming
that the reason was "it did not help with mcMMO", because mcMMO used to
fire extra BlockBreakEventS.
Now we use a tri-state and set it to MAYBE if instantBreak is set
already on lowest priority, to have a rough indicator if a plugin set
it, or if the server might have done it. Later we might let FastBreak
assume some maximal duration for either case, instead of ignoring these.
Fixes:
* On passable-violations useLoc might have been passed as newTo.
Reduce potential for accidental future misuse:
* Call useLoc.setWorld(null) as late as possible.
* Do not reset world of MoveInfo.useLoc in MoveInfo.set.
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.
