I don't see a big problem with developers using the wrong event, because that's easily correctable for the case that the plugin would work with the classic PlayerMoveEvent. If it's noticable it'll be easily found by timings, and the complicated name of the base event (Untracked...) might repell the average plugin coder . For absolutely highest performance you could make a hook system with an interface and a fixed signature, no reflection used etc.

A simplified approach like "firing events only on block changes" would allow to kill off most serious cases, though floors made of half slabs could still be clipped into using the untracked move + set home.

For me this is not the biggest issue right now, though it complicates a lot what we have to do to prevent moving into/through blocks. Even if we did "real" ray-tracing with the full players bounds, preventing them from getting close enough to the wall in the first place (currently we only check the foot position!), we will still be left with the players being able to go through blocks downwards, using sethome or similar with the untracked moves.

I'm for it - but probably should be a configurable option - perhaps a "plugin whitelist" in spigot.yml, as I'd only want/need anticheat plugins to utilize this. (Of course, some developers could demand server owners to add their plugin to this whitelist, but then again who would care for developers that don't care about performance?)

I'd be against this, simply because there is a huge chance that new developers would use the method as a replacement reducing efficiency dramatically - if we were to use, it may be worth deprecating as a warning to developers.

More from asofold:

"A use-case that hurts quite a bit, is that people can move through solid blocks: (1) just move slightly into a block without firing a move event (2) set home or warp (3) move back out of the block to prevent defenses triggering (4) teleport to the "legit" home/warp position. This can be automatized by clients. Our current counter measures are monitoring teleports and commands which is somewhat possible but also quite problematic. In general untracked moves are a quite distinct pain for the anti cheating business .

Firing an extra event like "UntrackedMoveEvent" or allowing to register (even if obc-) hooks would be a great help!

Update, why not use ProtocolLib: (1) ProtocolLib does not make any guarantee that hooks are run in the primary thread, instead explicitly demands thread-safe listeners. We already have had a constellation where it called flying-listeners asynchronously, causing an endless loop in a HashMap (... possibly on 1.7.10 with other plugins registering listeners asynchronously, forcing ProtocolLib to run all flying-listeners asynchronously). (2) Not entireĺy sure if the order of events will be 100% correct from PlayerMoveEvent vs. PacketFlying, also consider the order of other Bukkit events with other players and other triggers (3) More dependency, less update safe vs. using reflection a lot.

Many kinds of protections are potentially weakend or undone, e.g. people could move through a diagonal (air-stone/air-stone) wall and access chests there. In such a situation ray-tracing wouldn't help. Instead one would have to check for untracked positions for all sorts of interactions/events, complicating a lot of things (not anti cheating, regions, portals - all with cross-plugin interaction in mind as well!).

We love ProtocolLib and use it anyway.

Performance: Hooking into ProtocolLib certainly has much worse performance than firing a separate event, you could even not fire an extra event for the case no listeners are registered."

Quoting asofold: "A use-case that hurts quite a bit, is that people can move through solid blocks: (1) just move slightly into a block without firing a move event (2) set home or warp (3) move back out of the block to prevent defenses triggering (4) teleport to the "legit" home/warp position. This can be automatized by clients. Our current counter measures are monitoring teleports and commands which is somewhat possible but also quite problematic. In general untracked moves are a quite distinct pain for the anti cheating business .

Firing an extra event like "UntrackedMoveEvent" or allowing to register (even if obc-) hooks would be a great help!"