* Add a class to loop the flying queue with a block as target (look
only).
* Pass the flyingHandle to sub checks (doesn't necessarily make sense
with reach - should probably re-check reach with the used flying queue
state, but that's more complicated due to the possibility of split pos
vs. look).
* Use the loop class both for visible and direction (not reach).
Likely similar has to be done with BlockPlace and BlockBreak - would be
good to find a skipping heuristic for blockbreak.direction etc., so we
know we have successfully checked that block from that exact position
for this player and nothing has happened between (and so on, or a more
relaxed heuristic).
skipping redundant checking (limiting the number of visited packets
doesn't work - instead 'good candidated' for packet inversion with dig
packets should be stored together, so it's easy to just check vs. the
first/last stored one).
To be done:
* Use yaw and pitch of past packjets for Direction and Reach.
* If block break mathes the last interacted block (+ moving sequence
indicates no change), skip some checks like direction and reach there,
possibly keep track if those were run at all.
If the teleport confirm packet is available, flying packets with
AckResolution.WAITING will be cancelled.
This is real bleeding edge and might need other adjustments not to
freeze players for to be discovered edge cases. The TeleportQueue
already does contain a timeout mechanism and should return
AckResolution.IDLE after some time.
* Count all events/packets regardless of settings.
* MovingListener: Remove pos/look counting for move events.
* MovingFlying: Call the counter method according to primaryThread flag.
Since the normal function is to interpret packets, it's not really a
performance hit, if we always try to interpret packets.
This way at least FlyingFrequency can still run. For incompatible setups
FlyingFrequency can still be disabled.
This way, you can calculate a more interesting set-back location from
within a hook during violation handling. All you need to do to adjust
the set-back location is to call MovingData.setTeleported(newSetBack)
and NoCheatPlus should recognize this as the location to set back to.
Please do:
* Test if the check in question would set back at all
(IViolationData.wilCancel() returns true).
Please in such a case do not:
* Don't call setTeleported if IViolationData.willCancel() returns false
:).
* Cancel violation processing.
* Teleport the player.
* Do something complicated with MovingData otherwise :).
Store an extra array of items internally and allow fast fetching (for
fastest processing, where necessary). The sortedItemNodes array is kept
for future purpose.
Despite having an interface yet, add things like unregister many objects
(items) and getting all registered items, e.g. for dealing with
sub-registries efficiently (at first code-wise).
Store items in lists by type, sort by RegistrationOrder either lazily on
fetch or upon request. Allow registering an item multiple times, but
only once per type.
Tests, adaption of signatures, additions and variants should follow.
* Add RegistrationOrder for order.
* Add sorting functionality with some tests. (See
RegistrationOrder.AbstractRegisTrationOrderSort.)
* (Except for test cases, all this is not yet in use.)
(Perhaps the sorting should be changed to use an array for output
instead of iterators, this just represents a quick way in.)
Further direction:
* Replace all the registry lists like for INotifyReload and
IDisableListener and so on within registries by a generic storage that
uses this for sorting. This way every such thing will support both
priority-based and tag-based order at the same time.
* To support different order definitions depending on what type an
interface like IRegisterWithOrder might be supported by a registry.
* Later generic event listeners might also use this, simply.
* Reduce details and only send a configurable amount of lines in
notify/chat, default to 5, just state to check logs in the end,
instead of lengthy hints.
* Log detailed output to STATUS (file/s).
* Fix wrong build number printed to set configversion.created to.
* lostGroundAscend: new condition.
* lostGroundStill: some precondition checks moved inside, new condition.
* vdistrel: Extra case with decreased lift-off gain, but second move as
if normal lift off.
* With from being on ground, and last move not having touched ground,
setSetBack(from).
* The construction routine for ActionListS is to by passed the silent
permission already, so getting optimized copies will not add another
'.silent' to the already passed permission. (Correct me if i am
mistaken).
* Clarified javadocs/names.
* Further null permissions are handled, even if not (yet) necessary.
Still to be called with the ordinary check bypass permission:
* ConfigFileWithActions: The convenience methods to obtain
(Optimized)ActionListS from the
configuration.
* AbstractActionFactory.createNewActionList: will then create actual
lists, extending the permission by '.silent', unless the permission is
null.
(Stumbled onto, while looking for optimization potential with log action
execution.)
[BREAKING]
* Due to adding a method to CheckDataFactory.
* Might alter data removal (less is removed, might've overlooked
something).
For MOVING, FIGHT, COMBINED, data removal for sub checks now is
possible, allowing for more precise resetting via commands. Other check
groups may follow on request / randomly.
Data removal for check data is logged now (only CheckData, not
IRemoveData in general), in case the debug flag is set in the data.
Later, a more flexible method may get implemented, accepting a String
id, so not only check type related data, but also any type of special
data can be removed (e.g. moving.locationtrace would not be a check
type, but allow resetting the location trace of a player).