Minecraft anticheat guide
PacketEvents Anticheat Architecture for Minecraft Servers
The packet-versus-Bukkit event timeline, the thread-ownership boundary it imposes, and how that architecture differs from the PacketEvents dependency decision.
The packet timeline runs ahead of Bukkit events
Bukkit events describe what the server already accepted: a processed interaction, a completed break, a registered hit. Packets describe what the client sent and in which order — swing timing, movement updates, block-placement packets, digging start/cancel/finish, slot changes, inventory clicks, and entity interactions — before the server collapses them into events.
That ordering is the architectural reason packet tracking improves reach, hitbox, scaffold, fastbreak, inventory, and AutoTotem evidence. A detector reading only post-processed events works from a summary; a detector reading the stream works from the sequence.
| Layer | Observes | Misses |
|---|---|---|
| Packet stream | Send order, swing timing, rotation state, digging sequence, slot and inventory activity | Server-side outcome of the action |
| Bukkit events | Accepted server outcome after processing | Pre-decision timing and reordered or cancelled intent |
| Combined design | Ordered intent plus authoritative outcome | Nothing structural; tuning and ownership still required |
The thread boundary: decode on packets, mutate on owners
Packet callbacks must not mutate the world directly. The safe model is decode wrappers, update packet-safe player state, run math, and cancel illegal packets — then schedule any Bukkit entity or world mutation on its owning context: entity work on the entity scheduler, block and chunk work on region context, global actions on global context, and file or network work async.
That boundary is what keeps one detection core portable across classic Bukkit, Paper, and Folia ownership rules. Visibility improves on the packet side; authority stays on the scheduler side.
How this page differs from the dependency guide
The companion page answers the install decision: why FairPlay declares packetevents as a hard depend entry, compiles against 2.13.0, and must have the plugin resolved before it enables. This page answers the runtime design: what the packet timeline adds over Bukkit events and where enforcement must be scheduled.
Keep the two questions separate when evaluating any PacketEvents anticheat. A correct dependency setup does not prove correct thread ownership, and a clean architecture diagram does not prove the installed PacketEvents release was tested with the exact server build. Both need independent verification.
FAQ
Does FairPlay require PacketEvents?
Yes. PacketEvents is required to run FairPlay. Install it before starting FairPlay.
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.