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.
