Trying to prevent a burst propagate and cause a violation, it will be
smoothed onto following buckets, if they have less than max packets,
stopping after adding to the first non-empty one.
Uncertain effect on cheating, first tests seem to show no huge
difference.
Original pull request:
https://github.com/NoCheatPlus/NoCheatPlus/pull/24
This probably is not the final implementation, but it allows some
minimal freedom:
* Specify number of entries to show.
* Specify check types (and groups!).
* Specify what to sort by.
There might be need for some merged view, combining several different
check types somehow, or just shortcuts for specific selections, e.g. for
fighting-related checks.
----
+ Fix root command not showing sub commmand usage.
- Replaces all tabulators with spacebars
- Splits Commands to Commands and Auxiliary Commands
- Commands and Auxiliary Commands are ordered alphabetically now
This way, using the speeding permission as a workaround for all
individual speeds is possible. A player moving faster than default will
likely move faster in web too, and so on. There seems to be little
reason for keeping it confined to walking + sprinting only.
Moving it to the end also allows a quicker return for walking and
sprinting, though that policy might be questionable as well, because
some calculations might use hAllowedDistance, subject to review.
This should be better in case the vanilla command allows UUIDs some day.
At least during testing in uuids did not work, so we added a warning
message if uuids are used for banning.
Using player names for actions should be safe anyway.
Access by id may or may not be changed internally, depending on what
happens on the API side.
For performance reasons we might like to do without passing on extra
stuff like Material, or even do String-comparison.
If ids will become more expensive to use than other ways, or if it will
be possible/accepted that ids get reused during runtime, then we will
have to change all internals.
A merge can happen if the maximum distance between any two points
exceeds the merge distance, because LocationTrace attempts to balance
distances entries. Thus this test must not bne able to walk further than
the merge distance.
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.
