While we can/could control which stream to log to within onDisable, we
should still assume that an asynchronous task could be using the logging
system. Since we don't have a clean entry to onDisable, we have to catch
the exception.
* Extend CheckConfigFactory with a remove-all method.
* DataManager.clearConfigs() now uses CheckType for getting factories.
* Split off Check.hasBypass method to check exemption + permission.
* Allow null permissions in CheckType (interpret as no bypass).
* Add Check types for FlyingFrequency and SoundDistance.
* Add exemption and actions to FlyingFrequency, alter defaults.
* Add a test for moving a simple config value (not sections).
* Add a flag to @Moved to allow explicitly skipping sections.
(Should enable moving values into a child path of the previous one.)
* Don't set values before inside of processMoved...
First attempt to detect if a moving event would fire. This might not be
100% accurate, as a) we can'T really know and b) lastTo is not minitored
in the most reliable way (e.g. teleport on highest priority, resetting
logic favors set-backs).
* Use a HashMap for data, as we intend to use the primary thread.
* Move redundant move checking into a method.
* Ignore on-ground, if it is sent too often.
* Log if redundant move checking has to be disabled.
Removes access by name and entity-id for now. Access by name might be
re-added, though any kind of mappings will likely be maintained
somewhere near DataManager.
Measuring the time from sprint to attack doesn't work well. The
ctrl-sprint thing also adds to it. Better would be measuring the
toggle-sprint frequency and possibly combine it with some other measure
(packet level attack frequency?) then rather deal attack penalty time.
We can now decide on base of the Minecraft version, which value to use,
with the config entry set to "default". Used with
pvp-knock-back-velocity and enforce-location (first move exploit).
Activated features are shown in the version info ("ncp version"). The
version info is now logged to the log file after post-enable and after
reloading the configuration.
* Add methods to NoCheatPlusAPI to add/set/get version tags.
* Display all tags in the ncp reload command.
* Alter test framework to set a dummy API.
* Add tags for blocks, net checks, FastConsume.
Contained changes:
- Melon and pumpkin block break timings: 1.8-specific, keep workaround.
- Don't run all horizontal move checking if no move.
- Utility method for checking for air.
- Some formatting.
A cheat client could move such that they are inside of a block, but
CraftBukkit will not fire an event, because the distance and looking
direction don't change enough. Teleporting other players or yourself to
that location would result in getting someone into a block. Consequently
we also have to block commands like /sethome at such locations.
Our first attempt to patch that will monitor teleports that use the
TeleportCause.COMMAND (might miss out on plugins that are not using the
appropriate cause, and on plugins that use items for teleportation), in
addition we monitor certain commands (configurable prefixes), to catch
things like "sethome" and "sethome2". The world spawn is exempted. Only
teleports into blocks are monitored.
This does not yet sanity-check the distance to the last tracked
location, but it will ignore if none is set.
Details:
* Only trim commands from the left side (both on feed and check).
* Ensure versions with and without leading '/' are fed into trees.
* Move methods to feed CharPrefixTree from configs to CommandUtil.
Potentially fixes (untested):
* Only deny the sub-commands for a prefix, example: feed 'version ' to
consoleonly, in order to allow 'version' but not 'version NoCheatplus'.
* Might fix some plugin/server specific prefixes not being detected,
example: feed "/version" and expect "/bukkit:version" to be blocked.
* 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.
