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.
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...
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.
* Account for off hand in more places.
* Use bridge methods to get rid of warnings for now.
* Adds utility methods to CheckUtils.
* Do not allow left click on off hand (knockback).
Directly following:
* Boat fly check based on VehicleUpdateEvent and fetching last pos.
* Implement a native access based provider for
EntityAccessLastPositionAndLook, after testing the reflection based one.
Likely following:
* Implement the same fly checks based on PlayerMoveEvent for horses and
pigs too, for the case server-side fly checking is disabled.
* Configurability for individual types of enbtities, at least a flag for
activation.
* Not sure if a fall-back to VehicleMoveEvent should be kept, setup
shouldn't be all too complicated.
This is a first step in, which doesn't change the default behavior,
however it might break plugins that rely on certain internals.
PenaltyAction allows to do something with probabilities to consider,
including the possibility to select the first applicable penalty or
applying several penalties. There will be player-specific penalties,
which are applied during ViolationData.executeActions always, and there
will be input-specific penalties, e.g. for applying within the event
listener.
Potentially breaking:
* Return value of executeActions is now void for Action + ViolationData.
* Return value of Check.executeActions is ViolationData now.
* CancelAction is now extending PenaltyAction.
* CancelPenalty may cancel, but might not, due to probability.
* IViolationInfo.hasCancel -> deprecated, now returns willCancel().
* IViolationInfo.willCancel is now used, applicable penalties are
estimated on creation of ViolationData.
* Custom actions can no longer be used to cause cancel. Only penalties
can do so now (due to the return type change). CancelAction is still
there to keep a simple action for canceling.
Not yet:
* InputSpecificPenalty support for fight checks and using them in the
default actions.
* Configuration for penalties (currently only a plugin could override
the action factories, later penalties may have a probability to apply,
reference each other, allow first match, apply several at once).
This breaks testing for UNKNOWN_VERSION, if that is used externally.
Access methods are added for testing for unknown versions.
PR mentioning access methods:
94c4da3267
* 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"!]
Contained changes:
- Melon and pumpkin block break timings: 1.8-specific, keep workaround.
- Don't run all horizontal move checking if no move.
- Utility method for checking for air.
- Some formatting.
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).
