Since other fixes migth be in focus, some changes are commited
merged/commented out:
* Prepare AxisVelocity to carry positive and negative values.
* Prepare MovingData to use vertical AxisVelocity. Rename hVel.
* Prepare CreativeFly (...), do not count velocity for height limit.
(Most preparations were unfinished, just hinting at the direction.)
AxisVelocity will later represent per-axis velocity accounting for both
directions along an axis.
There have been no changes to the functionality, so it still only
accounts for positive values.
Previously the max. bounds hitting the block edge would not be
considered as colliding, this can now be controlled with a flag.
If the flag is set, you will collide at offsets of 1.0 for either
coordinate (not if the offset is < 1.0).
* Better coverage of block-transitions: One step per axis, dT can be 0.
* Cover one step always, also if no distance is covered.
There might be more false positives, due to newly intoduced bugs, or due
to not all block-transitions being checked (a x + z transition will have
two variations to test extra to the ordinary diagonal path, but only one
is checked).
To make this works we change LogUtil to allow logging to console, and
initialize BlockProperties with MCAccessBukkit and use a fake
BlockCache, that allows to set blocks with an access method, so that we
can test ray-tracing.
The testEmptyCorner test would fail with the current implementation.
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.
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?
