This will not check all possibilities, if default=YXZ fails:
* X or Z collision: test YZX as alternative.
* Y collision: test XZY then ZXY as alternatives.
Would need to check client code, possible of multiple client versions,
considering widespread use of protocol support plugins.
New
* Define a couple of default lists for axis order.
* Allow setting axis order via a list.
Removed
* Configuration option to disable ray-tracing.
* Configuration option 'blockchangeonly' - there may be an equivalent
later on, where checking accounts for the entire bounding box(es).
* Legacy code option (things have stabilized and axis order switching
should fix false positives).
Random
* Accidentally commit FastConsume (whitespace).
Currently typically blockbreak.direction will fail, if blockinteract
used a (the first) flying packet.
Other oddities: Block damage followed a cancelled interact event.
* Issues remain with "moved too quickly" interfering (TP loop with
waterfall/alternating, possible to escape).
* Not sure the previous modeling makes sense at all with allowing
friction now.
This probably is too much of a special case (place without interact?),
might rather hit plugin features. Apart from that, consequently, other
checks should test for this too?
[BLEEDING] just to note blockinteract changes may alter things.
Currently it looks like only blockplace.against is using the last move
of BlockInteractData - later other checks are intended to use that too,
in terms of a data source.
* 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.
