Not sure if this really pays, if most people use protocol-support
plugins that limit packets anyway. There could be some future use, e.g.
generic rate limiting with configurable implementation.
Other:
* New methods for RawConfigFile+ConfigManager to check for
AlmostBooleanS.
* Add all net check permissions to plugin.yml.
Using a LinkedHashMapCOW for now, fetching instances should be
thread-safe. This isn't such a big issue, but there might be handles in
asynchronously processed threads later on, and the handle will
initialize lazily. Copy on write won't be nice during registry setup, if
we have hundreds of objects registered at some point in the future,
neither would locking be too nice to have - but locking could be
acceptable with using handles, as those get updated by overriding the
instance field. Using locking would affect static utilities, but this
could be mended. An alternative could be to have some registration stage
'setup', during which fetching will yield the old state, while new
registrations will be added to a new map. Upon changing the registration
stage to 'live', the map reference is switched simply, this could be
acceptable even with a completely new setup after reloading the
configuration.
* Only unregister once really.
* Don't count to below 0.
* Throw a RuntimeException in getNewHandle, if already disabled.
(+ Allow checking if disabled for sub classes.
* ICollideBlocks matches the interface better. If we ever need ICollide
for something common (e.g. set(ICollisionSetup) allows to fetch
information about start conditions and run generic tests !? not really
sure if such will happen...)
* Add ICollideRayVsAABB, to prepare other types of direction/visible
checking (enable more precision, but also configurable leniency).
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.
registry.feature is rather meant for stuff that registers automatically
with adding as a component to the NoCheatPlus API.
Package organization isn't done in a very consistent way, this is just
taking a step into looking at how it would/could look like.
Likely that kind of separation can't be kept, so things will in the end
be organized by their main topic perhaps, and a registry implementation
will have to state what will be registered in what way, and possibly
have a method to allow checking what's possible to register.
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.
The idea is to change internals towards having a 'default'
DisableListener executing onDisable before the data removal of checks
and DataManager have been called, thus plugins or even checks might
still access all sorts data with disabling the plugin.
* Only load chunks, if there is no illegal coordinates.
* If there is no valid set-back on receiving illegal coordinates,
attempt to recover from past move / current (bug), or kick.
* Add a way to stay updated about the latest registration state for a
class.
* Add a class for the registry.
* Let the registry log all registrations.
* Make super interfaces for LogManager (simple logging of
String/Throwable).
Missing:
* More streams (REGISTRY, PLAYER/CHECK_STATUS/EVENTS or just CHECKS at
least). Make status rather the plugin status. Registry could have an
extra file.
* More efficient IGenericInstanceHandle use (wrap + reference counting).
Attempt to treat fake players less Concept is subject to change, might
want fall-back methods or skipping native access in general where it's
not needed (thus not need to check for native entities).
Other
* Don't insert dataMan into disableListeners twice.
This is neither complete nor final. Intentions are to group interfaces
better, rather organizing packages in a flat way.
At some point there will be other major move-arounds, but that'll
hopefully be a point where we have a better idea of where to put what
(...). For now the approach is to move interfaces/things rather where
it's not interfering with profane exemption API use, preferably neither
taking down the top level API layer
(NoCheatPlusAPI).
Added deprecated interfaces to prevent cncp to break too quickly.
Outlook:
* Classes that are rather only expected to be used internally for setup
will likely get moved around freely.
* Classes that have been added since last release might also get moved
around freely.
