(SAFETY COMMIT)
Largely breaking change.
* Interfaces in front of data types (and 'managers'), some interfaces
removed.
* Data and configuration fetching.
* Check activation checking (config flags, isEnabled, hasBypass).
* CheckType (activation checks, factories removed).
* Lots of collateral signature changes, including IPlayerData.
The (I)WorldDataManager stores per-world data (+ per world per check
type).
* Raw configurations.
* Typical flags: check activation, debug, lag adaption.
* Generic data, such as check configurations or per world check data.
The (I)PlayerDataManager stores per player data.
* Check Data.
* Typical flags: debug
* Exemption
* Check data (and config cache).
* Further mappings and later OfflinePlayerData.
* The registration interface will allow defining, how instances are
handled for registered types (factory, proxy, what on world change, what
on logout, global removal handler, per player removal handler).
(I)PlayerData is intended to be/become the central access point.
* External interface is IPlayerData now.
* Per player debug flags, exemptions.
* Fetching configuration and data: local cache, relaying fetching to
registered factories and proxy-registries/storage (e.g. fetching
configuration from per world storage).
Other fixes/changes:
(+) Extend the debug player command (set true/false, reset to world
default, arbitrary check types).
(+) PlayerData maintains a currentWorldIdentifier (to be used instead of
ChatData in future).
(+) The WorldConfigProvider getAll implementation returns a
LinkedHashSet now, avoiding duplicates.
(+) Move DefaultGenericInstanceRegistry to NCPCore.
(+) Thread-safety considerations for DefaultGenericInstanceRegistry.
(+) Don't log errors on hasBypass checking. TBD: Instead intercept
during listener methods (or even as a feature within the listener node:
e.g. @ThreadContext(primaryThread=true, skipOffContext=true,
cancelOffContext=true).
(+) Add fight.wrongturn permissions to plugin.yml.
(+) Missing GPLv3 headers.
Broken/Missing:
* WorldData inheritance from default: propagate all changes done
directly to the default config to children (all worlds that don't have
an explicit world_config.yml set) - possibly add an OverrideState or
similar, (NONE, FROM_DEFAULT, EXPLICIT) and don't override EXPLICIT if
coming from the default. Calling override on the default WorldData is
not to be confused with calling override for WorldDataManager (override
for all worlds as EXPLICIT).
* Organize overriding for special circumstances (version dependent
activation and the like). Might want to add registered override
handlers to be called on reload automatically.
* Store generic per check type per world data in the WorldDataManager,
such as configurations and per-world check data. TBD: Factories, cleanup
(!).
* Most efficient referencing (IWorldCheckTypeNode, IHandle<something>?).
* All the registry stuff (see PlayerData).
* Use interfaces for auto registry (and a flag within
RegistrationContext?) - world unload, world change, player join / leave.
* (Data expiration handling including transition to IOfflinePlayerData,
because now data is a little heavier.)
* Further details.
Benefits:
* Improves performance, where permission lookup has major impact, with
timeout based lookup, static permissions (skip permission check
entirely), and world/offline based invalidation. (Once fully
implemented.)
* Hopefully more efficient: use Bukkit Permission for faster defaults.
* (Allows control over how which permission is to be
updated/invalidated, which is useful per se.)
Risks:
* Complex changes yield bugs.
* Other plugins depending on NCP might break.
* Cache incoherence might happen (permissions are changed dynamically +-
unintended malconfiguration, or in case of bugs).
* (Endless loops certainly have all been fixed.)
Breaking:
* Lots of more or less internal API has been changed or removed: Check,
CheckType, CheckUtils, TickTask, ...
* Permission checking behavior has been altered.
Rough points:
* Implement a permission cache within PlayerData.
* Remove the player tasks and permission updates in favour of handling
those within DataManager and PlayerData.
* Adjust everything else to it (partly TBD).
* Updating sets of permissions (e.g. for CHAT) is done more lazily now,
i.e. one per 10 ticks). An actual permission check would still yield an
update next tick (asynchronous).
* Fixed/extended random spots (DualCollection, MiniListener registration
support, StringUtil).
Missing:
* Basic implementation
* Cleanup after logout (stages: 1. non-essential like permissions,
2. unrecoverable like set-back location, 3. complete data removal).
* Coverage
* Might have missed spots.
* NoCheatPlus.nameSetPerms should be replaced by caching + default
config for world-wise updating.
* Command permissions are always checked. At least for players,
cache based lookup should get implemented.
* More unit tests.
* Extended configurability: Per-world settings/policies.
* Efficiency
* Not all parts of the implementation are 100%/optimal yet.
This time the focus is on the utilities package.
Possibly used, but not really official API:
* Move block cache to a 'map' sub-package.
* Move RichBounds/RichEntity/Player-Location and TrigUtil to a location
sub-package.
Not really official API, likely not used:
* Move AttribUtil to compat, since it belongs there.
* Split off direction check methods to collision.CollisionUtil.
* Move static BlockCache methods to map.MapUtil.
* Move food related methods from CheckUtils to InventoryUtil.
* Move vehicle/passenger related methods from CheckUtils to
PassengerUtil.
Not breaking:
* Move IdUtil to commons.
Main objective is to get rid of too complex setMCAccess methods and to
be able to store handles rather permanently instead.
* Remove MCAccessHolder.
* Add/refine interfaces and implementations.
* Change constructors.
Major: Sketch vehicle envelope check.
* Renaming fields, methods, packages. Moving classes to other packages.
* Additions and refactoring for set-back handling and location tracking.
* Increase amount of debug logging.
* Adjustments to current vehicle set back handling.
* AuxMoving: call clear() on setMCAccess.
Minor: Adjust block change tracking implementation.
* Use a class instead of an id, in order to keep track of used entries.
* Allow reuse of an id, if the block still is intersecting.
* Improves situation for simple setup, issues remaining:
* Random UNKNOWN teleport by server potentially interfering.
* Distances > 1.0, possibly resulting from split move handling.
* On-ground estimation and passable.
* Blocks with gravity are worse (likely on-ground).
* More in-depth checking of constraints of implementation.
* Note that the block change tracker currently is disabled by default.
Very coarse modeling, players likely are able to abuse this and there
are verly likely more false positives.
Especially elytra will have issues:
* Players can fly very fast.
* Elytra will make players fly even faster than the set limit, resulting
in false positives at some point. Setting the allowed speed that high
will yield the problem of players being able to abuse even worse. Thus
limiting to the speed of spectator mode. Modeling will be changed to
accomodate for gain vs. max. distance and other.
This is a first step in, which doesn't change the default behavior,
however it might break plugins that rely on certain internals.
PenaltyAction allows to do something with probabilities to consider,
including the possibility to select the first applicable penalty or
applying several penalties. There will be player-specific penalties,
which are applied during ViolationData.executeActions always, and there
will be input-specific penalties, e.g. for applying within the event
listener.
Potentially breaking:
* Return value of executeActions is now void for Action + ViolationData.
* Return value of Check.executeActions is ViolationData now.
* CancelAction is now extending PenaltyAction.
* CancelPenalty may cancel, but might not, due to probability.
* IViolationInfo.hasCancel -> deprecated, now returns willCancel().
* IViolationInfo.willCancel is now used, applicable penalties are
estimated on creation of ViolationData.
* Custom actions can no longer be used to cause cancel. Only penalties
can do so now (due to the return type change). CancelAction is still
there to keep a simple action for canceling.
Not yet:
* InputSpecificPenalty support for fight checks and using them in the
default actions.
* Configuration for penalties (currently only a plugin could override
the action factories, later penalties may have a probability to apply,
reference each other, allow first match, apply several at once).
* In addition to the "distance from set-back" check, we have a check of
the per-move distance for in-air checks, taking account of friction.
* In-air and liquid checks should consume vertical velocity once needed.
* Model vertical velocity "exact", i.e. positive and negative, use an
entry once a sub-check fails, quite strict invalidation of not matching
values, matching against the y-distance directly.
* Vertical accounting has been sharpened for the moment. The new
per-move checking might make it superfluous.
* Remove MediumLiftOff in favor of a LiftOffEnvelope carrying basic
lift-off max-gain/max-height/max-phase, enabling to distinguish between
normal lift-off and liquid near ground.
* Rename others (e.g. sfLastYDist -> lastYDist). Thus breaking internal
naming, adding velocity via MovingData still works, but should behave
slightly differently.
* Fixes (waterwalk with head obstructed, resetting of sfDirty, possibly
others).
Issues.
* Edge cases with velocity, water.
* Lava needs friction, at least with velocity.
* Lostground_edge(ydist < 0.0) ->
bunny with yDistance > 0.0. Need more flags or better model for keeping
past moves information.
* Plain ground misses (layered snow).
* lostground with yDist == 0.0, then seemingly in-air yDist== 0.0, then
bunny/lifft-off (similar to above). Needs better modeling of past moves,
because several lostgorund cases mean "the move has been on ground".
Also includes geting the distance to ground for hack-proof set-back-y.
* Vertical velocity is now matched with a margin, because the client
seems to add randomly.
* Possibly new loopholes/exploits (extreme large moves?).
* Cleanup pending.
* Group selected classes into sub-packages of moving.
* Rename classes.
* Must use LinkedList for velocity entries.
* Prepare SimpleAxisVelocity + entry for use-once accounting.
(Might not be the final naming.)
This is not the thing (lots of yet), but it is a small step.
Refactor:
* Use access methods for several details on vertical velocity.
Fixes:
* Dont reset the current jump phase if there is vertical freedom left,
because the next jump might then cause a violation.
* Fix clearActiveVerVel (remainder used to clear hVel, yet unused).
* Clear vertical velocity on removeAllVelocity (!).
* Keep setting sfDirty if velocity is found, to prevent premature reset.
Missing:
* Some resetting conditions for sfDirty might be missing.
* Implement an error counter increasing with velocity-add by 1.0 or
slightly more , decreasing with violations, but undo violations if count
is > 0.0. Use at least for vertical accounting, in order to go stricter
on cheating with velocity.
* Revise setting sfDirty on horizontal velocity as well.
* Switch to AxisVelocity (vertical), accounting for + and -.
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.
Now players are forced to create moving events with CraftBukit,
in order to get above the trigger-distance, thus moving checks can
complement this (in theory).
This could lead to more false positives.
Factories are now on NCPPlugin level, thus all the core stuff can be in
one module, giving better source code browsing.
Updates has been moved into an updates package, because there is to be
expected more content, and to make utilities less fat.
To indicate the direction, the basic infra-structure has been added to
allow adding components to the DefaultComponentFactory. Further
processQueuedSubComponents is now called after each components adding in
order to allow more flexible registry features.
asofold
MyPictures