AnticheatPublic build
FairPlay
Combat compensation built from observable packets, not a movement-prediction fantasy.
Combat-focused Minecraft anticheat combining deterministic checks, packet-level analysis, integrations, mitigation systems and machine-learning workflows.
Active development. Source is at 4.1.0; distribution is through BuiltByBit.
Checked version 4.1.0
Evidence checked 2026-10-30
The problem
Combat cheats are messy: reach, hitboxes, autoclickers, velocity and latency all interact. A check that cannot explain which packet produced a decision is difficult to tune and easy to distrust.
What I built
- Built a combat-focused detection pipeline on PacketEvents with deterministic checks and explicit cancellation authority.
- Added transaction synchronization with provider arbitration for Grim, native and disabled modes.
- Kept mitigation separate from detection so servers can choose alerts, cancellation or punishment deliberately.
- Added an API and optional hooks instead of hard-coding one server's plugin stack.
Architecture and trade-offs
Receive packets once, dispatch by type
Incoming PacketEvents are deduplicated by event identity and sent to dedicated handlers. That prevents two listeners from applying the same compensation twice.
Detection and mitigation are separate decisions
Checks produce results; a hitbox decision aggregates independent failures. PASS and UNKNOWN are not treated as a cancellation reason. Mitigation configuration decides what happens after a failure.
Transactions resolve latency honestly
The transaction service can use Grim, its native implementation, or disable itself. Provider conflicts are handled at startup instead of being discovered under load.
No movement prediction by design
FairPlay concentrates on combat. It does not pretend to replace a movement-prediction anticheat, and it does not require one specific external check suite to make a decision.