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.
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.
MCAccess will be split into smaller providers with time, so do expect
more breaking changes of this type. If this is an issue, please contact
us, so we can see how to smoothen things. E.g. we could still make
MCAccess an aggregate, that just delegates to the more fine grained
providers, or we could provide other
(default) aggregates.
This also adds a Bukkit-based provider for future updates.
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.
This won't cover all effects of internal changes, some blocks might be
interpreted wrongly still, some shapes may have changed in an
incompatible way (e.g. skulls).
* Make attribute methods consistent (remove the sprint boost modifier
from the generic speed multiplier, because it's inconsistent).
* Add missing implementations.
* Adjust default sprinting speed modifier.
* Add more guards for the latest compat module (1.8_R3).
* Add a reflection based compat module for CB, to cover minor updates.
* Possibly other minor fixes/changes.
[Hail "insufficient data written"!]
An implementation for NCPCompatBukkit is missing.
Note that the native access can not set lastYaw nor lastPitch in
PlayerConnection (private), but it could set lastYaw and lastPitch in
EntityPlayer.
Can't guarantee this actually helps with stuff like derp/magnet, because
we can not really set the outcome of a PlayerMoveEvent without
rubberbanding the whole planet. Hacks could send enough packets per tick
to keep freezing people - we might be able to keep track of yaw/pitch
correction and cancel (most) attacking for the same tick after yaw
correction (invalidate "same" with in-bounds yaw).
