* Store complete event result state for interact.
* Store consumed checks as well.
* Still run the speed check, if only using the item in hand is allowed.
* 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.
