Minecraft anticheat guide
Global Punishments and Per-Check Overrides
Compare shared punishment tiers with individual check overrides and use a focused configuration example for one exception.
Global tiers carry the shared policy
A large anticheat with many checks becomes hard to maintain if every check carries separate punishment logic. FairPlay reads shared violation-tier actions from GlobalPunishmentsConfig (punishments.yml), so staff learn one escalation model before any check is customized.
Violation progression is tracked per check: flags from different checks do not combine into one check's tier progression. A tier action therefore needs review together with its check, expiry behavior, and mitigation gate.
Precedence: exact check configuration wins over the shared tier
When a check declares its own file and nested path through @ConfigInfo metadata, that local configuration governs the check's behavior; the shared tier supplies the action grammar it can reuse. Action behavior and kick/ban eligibility are owned separately by MitigationsConfig (mitigations.yml), whose fresh defaults keep kick and ban disabled.
The same precedence idea applies to external hooks: exact blacklisted checks take precedence over trigger patterns in the hook configuration contract. In both layers, the narrower exact rule wins over the broader pattern.
Use local overrides only for proven exceptions — for example, one check stays alert-only while a high-confidence check mitigates earlier. Do not override every check on day one; start global, observe, then adjust narrow cases.
A safe partial override pattern
Back up the generated files first, change one check in one file, and leave every other check on the shared tier. The sketch below shows the shape of a single-check exception; read exact keys from the generated file for the installed build rather than copying key names from memory.
Document the override so staff know why the check differs from global policy, and re-verify after any FairPlay update that ships configuration migrations.
# punishments.yml keeps the shared tiers untouched.
# One check file carries one local exception:
# checks/<family>/<CheckName>.yml
# - keep the shared tier reference,
# - change only this check's action or threshold,
# - note the reason and date for staff review.FAQ
What is punishments.yml for?
It defines shared violation tiers and enforcement behavior that checks reuse through GlobalPunishmentsConfig.
When should I use a local override?
Only when a specific check needs different behavior based on real production evidence — one check, one file, documented.