Minecraft anticheat guide
PacketEvents vs Bukkit Events for Anticheats
Why packet tracking gives anticheats better timing for combat, digging, inventory, movement, and block interaction checks.
Who owns each event layer
Bukkit events are owned by the server: they describe outcomes the server already accepted, such as a processed interaction or a registered hit. PacketEvents observes the client stream before the server collapses it: swing timing, movement updates, placement packets, digging phases, slot changes, inventory clicks, and entity interactions.
An anticheat built only on Bukkit events therefore reviews summaries, while a packet-aware design reviews the sequence. That ownership split is the architectural reason packet tracking improves combat, digging, and inventory evidence.
Ordering examples that summaries hide
Consider a digging workflow: start, cancel, and finish packets interleave with slot changes and movement in ways a single BlockBreakEvent never shows. Consider a fight: swing timing, rotation state, and interaction order precede the damage event the server finally fires.
Sequence-aware checks catch reordered or cancelled intent that summaries erase. Staff reviewing such flags should ask for the packet order, not just the outcome.
The thread boundary this split imposes
Packet callbacks must not mutate the world directly. The safe model decodes wrappers, updates packet-safe player state, runs math, and cancels illegal packets, then schedules any Bukkit entity or world mutation on its owning context.
That boundary keeps one detection core portable across classic Bukkit, Paper, and threaded ownership rules. Visibility improves on the packet side while authority stays on the scheduler side.
FAQ
Does FairPlay require PacketEvents?
Yes. PacketEvents is required to run FairPlay. Install it before starting the server.
Does packet-based detection mean unsafe threading?
No, provided packet listeners avoid direct world and entity mutation and route enforcement through the correct scheduler or server context.