This is incomplete, as some pre-checks are still done with the full
bounds (flying just under web will put you to sf). Efficiency-wise there
could also be a more light-weight adjustment.
Attack areas are left too, e.g. flying (with or without boost) to
underwater, then end gliding to effectively clip with the head into
/through the block above.
With the lowered height it's also possible to get into odd spots, so
after stopping to glide you'll not be able to get out anymore.
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).
