* Store the per check type flags within PlayerData/PlayerCheckTypeTree.
Access methods within PlayerData.
* (More) thread-safe access, with the twist that alterations are mostly
done within the thread-context (primary thread vs. asynchronous).
(+) Mimic legacy behavior, by non-nested entries. However untouched
nested entries are possible, creating ExemptionContext instances with
other negative ids.
(-) No ExemptionRegistry is implemented. This just aims at replacing the
internals, without altering the (legacy) behavior.
* Each asynchronous permission check yields an update request anyway,
thus frequent bulk update requests have been removed.
* With join and world change, lazy permission updating is requested.
Breaking:
* Remove CheckConfig.getCachePermissions().
The original idea had been to just count an abstract value for load, so
the number of permission checks per tick stays limited, however that
doesn't scale with the CPU power and other.
This doesn't account for lag, but keeps the impact down slightly. Not
sure this is really useful.
(+) Only run set back for online players. Quitting has to be handled
differently.
(+) Comments.
* Remove the old per-world permission cache.
* Use the new permission caching feature.
* Always use permission subscriptions.
Pitfalls:
* Permission subscriptions might fail under certain conditions
(legacy?).
Only count the fall height below the set back y from lift-off (rather).
Breaking:
* Adjust method signatures and public visibility / interface for NoFall.
Issues with bunny hopping remain (...), but this might help with
elevators.
Use of velocity entries has been made more strict (directly use, remove
previously queued ones).
(+) Extend/alter slightly, e.g. added a regex example.
Replacement characters are not needed, and default values won't keep
reappearing.
Tests pending, e.g. dump with the upcoming registry log.
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.
Relatively cheap addition, done:
* Internal API within BlockProperties.
Missing:
* Support configuration: compatibility.blocks.breakingtime
* Support a command to update by the last n mined blocks (!). Needs
storing all side conditions within BlockBreakKey and convenience methods
for getBlockBreakKey + use internally.
The old ListenerManager is removed, new system in place. Removed
doesManageListeners(). (The new system isn't that new, but it's been
fixed and adapted to using RegistrationOrder.)
New
* Register all Bukkit events via the new EventRegistryBukkit.
* This way listeners can be ordered by numeric priority and tags
(regular expressions for beforeTag and afterTag).
* Unregistering listeners is possible (a listener node stays in the
Bukkit registry, but only one per event).
* It's possible to add listeners with minimal impact (MiniListener).
* The registry registers by event class 'hard' i.e., no relations
between already registered classes are checked.
* Order isn't necessarily stable nor even reproducible for randomized
start conditions with the same elements.
Point
* Compatibility hooks can easily place event listeners
before/after/between NCP default listeners, without resorting to tricks
like 'load-before'.
* Future registry of NCP itself: unregistering listeners is necessary
for runtime-removable checks, order is useful if not necessary, to be
able to add check listeners at any point of time.
Breaks:
* Anything relying on the previous (optional) managelisteners feature.
Missing:
* Lots of testing/inspection.
* Ensure all NCP listeners are coming with name/tag at least.
* Provide meaningful tags/RegistrationOrder for fine grained access
(e.g. after feature.moving but before feature.inventory).
* Change cncp to hard depend on NCP and use listener priorities.
* The annotations made for RegistrationOrder are defined in there.
* Add RegisterMethodWithOrder (method) for event handlers.
* Add RegisterEventsWithOrder (type) for default order with listeners.
Yes
* Remove the UNKNOWN type.
* All types except ALL have a parent now.
* All types have a type now.
* APIUtils: Add getDirectChildren for distinction.
No
* APIUtils doesn't collect the descendants in a generic way yet.
(+) Note: If it's fired asynchronously, meta data isn't checked, due to
that not being thread-safe. In future extra checks for (demanded to be)
thread-safe external plugin APIs can be added (reflection only).
(+) Add comments to PlayerData, concerning future treatment of name-uuid
mappings and retaining data.