* Some cleanups (spaces, commented out references updated).
* LogManager implement INotifyReload, but gets processed extra (not
added with addComponent).
This is the first simple version, just setting debug for all checks for
the player(s). It can only be undone by removing the data, e.g. with
"ncp remove (player)", reloading does it too, but is much heavier.
For debug output now data.debug is used instead of config.debug, so the
data is initialized with the config.debug value. As an effect of this,
removing the data or reloading will override flags that have been set by
means of API-access only.
Affected:
* Adds getDebug and setDebug to ICheckData.
* Adds appropriate configs to all constructors of check data.
* Some per-check debug flags have been removed.
Extras:
* spaces
* import cleanup.
* Remove on-ground check.
* Always increase VL by 1, because clients could control it anyway.
* Skip if the player is in a vehicle.
* Remove adapting to lag.
* All logging is also going into the log file (always), debug output is
mostly/only going into the log file. File logging uses an asynchronously
processed queue now (!).
* Specify an existing directory (e.g. logs) and log files will named
after date + sequence number, changing with every reloading of the
configuration.
* Console and ingame logging remain within the primary thread.
* No extra configurability for customization, yet.
* Not all places have been cleaned up, concerning log levels. target
streams and package naming.
* Work in progress.
Hinting at further changes to unify permission access and caching. Later
permission caching can also be done for moving checks, though checking
for the current thread may be exchanged in favor of config flags.
Generic configuration will allow to set individual timeouts for checks,
check groups and default. There could also be change policies like
"world change only", possibly listening to permission updates, if
feasible.
CheckData / AsyncCheckData are not as simple to unify, if we want to
keep the footprint as low as possible there. There could even be more
implementations to match different policies.
* Always log location of logout if debug is set.
* Also check inconsistent logout if manahattan distance is > 0.
* Only perform "passable check" only if enabled and not dead/sleeping.
* Try to actually set-back.
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.
