Minecraft anticheat guide
How FairPlay Helps Admins Review Reach Claims
How staff can evaluate reach complaints using hitbox distance, occlusion, packet timing, and debug context.
Geometry first: what the numbers must show
Preserve the exact diagnostic text exposed by the installed build when reviewing a reach alert. Record the configured reach limit and server, tick, or synchronization context only when the diagnostic output actually includes those details.
Ordinary alerts are not assumed to expose target boxes, block-shape bounds, world-state ticks, a named look vector, or transaction fields. Do not infer those values when they are absent.
Line of sight and latency complete the picture
If the installed diagnostic includes relevant occlusion or timing context, retain it verbatim and note the build and server conditions. Otherwise, treat those details as unavailable rather than filling them in from a video or an assumed implementation.
Why reports need evidence, not recordings alone
A player recording can be an investigation lead, but it does not establish server-side geometry or packet-time state. Redact identifiers before sharing any diagnostic, and do not claim measurements that the installed build did not provide.
FAQ
Can a video alone prove a reach claim?
A recording can be an investigation lead, but do not infer server-side measurements or context that the installed build did not expose.
What should a reach review note contain?
Keep the diagnostic text as exposed by the installed build, and record configured limits and server context only when those values are present.