The per-config-path notifications would keep showing up, even if you
removed the paths, then run 'ncp reload', then alter any of them and run
'ncp reload'.
To fix this, the configversion.created value is set to the current
build, if no config warnings are there - which is the same, as what the
notification suggests as an alternative to removing the paths and
running 'ncp reload'.
To do this, isConfigUpToDate had to be moved from Updates to
ConfigManager, which makes more sense anyway. In addition the 'created'
and saved 'values' are set to the biggest thing found, instead of the
prehistoric static value.
Further a negative 'created' value will not be overridden anymore,
allowing to silence the config notifications forever. Not necessarily
recommended for the general case, but it can be useful/necessary with
maintained blueprints, e.g. with administering multiple servers.
One of the next steps will be to remove the DefaultConfig.buildNumber in
favor of setting a build number for each and every path added. All
provided we don't run into nasty issues here.
Another follow up could be to create an extra registry/config log file
and write all the values there, and only print the first 5 in ingame
chat.
Instead of maps for each individual purpose, and the rather expensive
TickListener adding and removing, player specific task will be done via
one PlayerTickListener that can be registered with the TickTask. Thus
PlayerData has the access methods requestUpdateInventory and
requestPlayerSetBack, and so on, later more. For the
DataManager.playerData map it'll be UUID first now.
Consequently some calls have been altered to prefer passing Player or
UUID for PlayerData getting.
Breaks: DataManager.getPlayerData(String, boolean) has been removed, new
methods added to do the same without boolean or with UUID passed extra.
Following changes may repeatedly/randomly break PlayerData and check
data access (unless you use CheckType.getDataFactory), this may not
follow directly, but more or less soon. Even Later, CheckType will get
broken too :), in favor of class instances with dynamic registration
ability.
Basic direction is to concentrate stuff in PlayerData, getting rid of
all the static data stores, but also making access to shared data
more efficient (e.g. store last world id + name and permission cache in
PlayerData). Access will be more thread safe (only for PlayerData,
permissions cache, likely for fetching check data too, however returned
objects may have their own contracts).
Tested with a pig. It's not nice.
* Vehicle envelope needs a lot of overhaul.
* Force fall set backs may be more nice to have for in-air downwards.
* The set back locations can be from seconds ago, with different
passengers than at the time of the set-back.
* Auto generate the sub-module file structure.
* Add rest manually.
Rest
* Enter new classes into factories.
* Add entries for modules and dependencies to the root pon and the
NCPPlugin pom, to make the new module represent 1.10 R1.
* Point the 1.10_r1 build profiles to the new module.
* Add a new module for 1.11, point to cbdev (which still is 1.10.2,
though).
Next steps (next MC release, probably):
* At least auto generate a file, containing all entries to make for the
new module, for convenient use with copy and paste.
* (Later: alter the files automatically, possibly interactive. Needs
more care, e.g. if profile entries already exist. The factory entries
can have a marker each.)
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.
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.
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.
* 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.
In order to simplify the pom.xml files, we now work with a ncp_base
(formerly 'minimal')
profile for the minimal configuration and demand this to be activated in
addition to other profiles. This means the build parameter 'ncp_base'
can/should be used as well. See the README.md for a table of build
profiles).
Perhaps later there will be extra settings and an extra log file for
registry/setup related output, while real errors would still be logged
to file/console.
Configurable. Falling blocks, piston, end portal, roughly. Destructive:
the entity is removed.
(In addition some of the feature tags are added regardless activation
flags, because 'ncp reload' could change things anyway.)
Feel free to suggest alternatives/variations...
