First batch:
* Initialize blocks somehow, so no errors nor missing blocks happen
during startup.
Possibly Missing:
* There might be references of removed/renamed material (blocks/items)
throughout the code.
* Some blocks may behave different now/then.
Missing:
* Block#getData may not reflect (all?) properties anymore.
* Block shape getting is missing. Block shapes are now (potentially)
more complex to process. Concept might be to keep a double array for the
rough bounds, and add an (optional +- null) array of arrays for sub
shapes, if present (IBlockCacheNode). So a first rough update is more
simple/compatible.
(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.
Only count the fall height below the set back y from lift-off (rather).
Breaking:
* Adjust method signatures and public visibility / interface for NoFall.
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.
To model differing behavior of fluids, i.e. half fall distance per
in-lava move vs. zero fall distance once in water, block flags will be
used. To really do this the NoFall check will be altered to account for
new flags. Once at it, the check should also treat from and to
independently of each other - there are some inconsistencies, such as
how oFallMaxY is set.
Further flags are reserved for MIN_HEIGHT..., indicating that
compatibility will be improved without compromising protection too much.
Thus instead of making a block entirely passable, you could set a
specific min height flag alongside ground_height (and possibly height
for max. height), in order to allow walking between level x and y but
not below (think of grass_path).
Where it's known that it's the primary thread, that test should be
omitted.
A remaining problem is the Check class, where the convenience methods
all will lead to testing for Bukkit.isPrimaryThread(). This needs to be
done differently.
It'll be hard/impossible to work around, if we have to check permissions
and meta data. For permissions we could do some kind of bulk/context
dependent caching and updating policy and check via PlayerData, but meta
data needs the Bukkit API to state thread safety. Future design could
also do without knowledge of the thread, if permissions are cached and
exemption by meta data is turned off (or also cached, but this only
works if other plugins don't use it for temporary exemption), a lazy
approach could pass on an AlmostBoolean isPrimaryThread.
For now, at least some of the frequently run moving checks use the
optimized approach.
Changes contain:
* MCAccess.dealFallDamageFiresAnEvent -> true
* Always log basic data on (handled) fall damage events.
* Add a tag for the cancel reason with NoFall. Alter the default alert
message.
* Move 3.0 to Magic.
* Set the skipping flag correctly on allowFlight being set.
Fall damage is adjusted or cancelled, if the Minecraft fall distance is
greater than the distance(s) tracked by NCP (per move diffs, maximum y).
Intention is to prevent (speeding by) self damage by abusing Minecraft
dealing fall for untracked moves.
Issue: https://github.com/NoCheatPlus/Issues/issues/338
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.
Kept configurable to enable increasing difficulty for fly plugins use,
e.g. to allow players to fly within certain regions, but still deal fall
damage on falling.
Prepare using VehicleUpdate and PlayerMove instead of VehicleMove for
vehicle moving. This change isn't intended to change
anything/much on the surface.
* Implement native IEntityAccessPositionAndLook for 1.9_R1 and 1.9_R2.
* Alter method visibility and parameters.
* Common pre-conditions.
* Route contents of both VehicleUpdateEvent and PlayerMoveEvent through
a common related method (also named onVehicleUpdate).
* Remove RichLivingEntityLocation, to be able to simplify more.
* Refine interfaces for locations (IGet... ISet... vs, I... for both).
* Implement location related interfaces in some places, related changes.
* Override hashCode for some of the location related classes. Use that
for storing location hashes instead of Location.hashCode. Auxiliary
methods for hashCode in LocUtil.
* Add onIce to LocationData.
* Renaming player vs. vehicles (likely incomplete).
* Possibly other related/random changes.
Line count is high for this change, despite not so complex. Next step is
to change VehicleChecks to use past move tracking to estimate from where
a vehicle is moving (left not compiling). Due to the lack of teleport
events, and due to entity last location being mostly useless, we have no
choice but to hard-set-back on anything that looks strange.
Roughly:
* Encapsulate past move tracking in a MoveTrace class.
* Have playerMoves and vehicleMoves (the latter unused).
* Resetting method for both player+vehicle including more packets each.
* Don't reset vehicle data on game mode change.
asofold