Minecraft anticheat guide

Combat Terms for Minecraft Staff and Anticheat Review

Plain definitions of combat terms staff see in FairPlay, including rotation traces, reach compensation, air swings, and totem tests, and how to review them.

Updated 2026-11-07 · ~5 min read

minecraft combat termsanticheat combat termsreach compensation minecraftminecraft rotation tracetotem test anticheat

What do combat terms mean in an anticheat review?

Combat terms name the behaviors and settings staff review after a fight. Most of them describe a mechanic, a diagnostic, or a mitigation rather than a cheat. The table defines each term briefly and names where it appears on your server.

Combat mechanic, diagnostic, and mitigation terms for staff review.
Term	Plain definition	What you will see on the server
Rotation	How a player's view direction changes over time. FairPlay has rotation checks and a trace command for this data.	Rotation check names in alerts and rotation settings in hooks.yml.
Rotation trace	A bounded record of rotation data for one attacker and one target, started and stopped by staff.	The /fp rotations <attacker> <target-id> command and its status and stop branches.
Rotation checks	Two rotation-related checks whose names appear in the default hook exclusion list.	RotationBreak and RotationPlace entries in hook settings.
Air swing	An attack swing that does not land on a target. The mitigation docs tie reach compensation to this case.	Air-swing references in the increaseReach description.
Reach compensation	A bounded allowance for a qualifying clean beneficiary against a target. It does not give extra reach to an offender or change a player's reach permanently.	The increaseReach setting in mitigations.yml.
Clean beneficiary	The player who qualifies for compensation under FairPlay's rules. The documents name the role but this glossary does not list the full criteria.	The qualifying role is described in the mitigation guide, not in a log field.
Totem test	A diagnostic command that checks totem behavior for one player over a window from 50 to 5,000 ms.	The /fp totemtest <player> [window] command and its permission.
Totem controls	Mitigation gates for totem behavior, set separately from the check itself.	Totem entries in mitigations.yml.
Macro-spear controls	Mitigation gates for macro-spear behavior, set in the same file as the other combat gates.	Macro-spear entries in mitigations.yml.
Check category	The grouping used in the checks reference, such as Elytra, Hitbox, Macros, and AutoTotem.	Category headings in the checks reference, which also list each check name.

How do you read a combat alert with these terms?

Work from the alert to the setting, one step at a time. The command below uses the documented shape with placeholders, so read the installed usage message for the exact argument order before you run it.

Read the check name in the alert and match it to its category in the checks reference.
Check mitigations.yml for any gate that applies to that category before assuming an effect.
If the review needs trace data, start the trace only in a controlled session with consenting participants.
Stop the trace with its documented stop branch and read the status output before concluding data was captured.
Record the participants, the target identifier, and the redacted output.

Documented rotation trace shape with placeholders.

/fp rotations <attacker> <target-id>

Which combat terms are easy to mix up?

These pairs describe nearby ideas that are easy to confuse in a review. The table separates what each term covers and where to check it.

Commonly confused combat and mitigation term pairs.
Pair	The difference	Where to check
Rotation vs rotation checks	Rotation is the data: how the view changes over time. Rotation checks are the rules that read that data.	Alert check names versus the rotation trace output.
Reach compensation vs a reach check	Reach compensation is a bounded allowance in mitigations. A reach check is a detection rule. They do different jobs.	increaseReach in mitigations.yml versus the checks reference.
Clean beneficiary vs offender	A clean beneficiary is the player who qualifies for compensation. An offender does not get extra reach from it.	The mitigation guide and the alert history.
Air swing vs a landed hit	An air swing does not land on a target. A landed hit does. Compensation is tied to the air-swing case.	The swing context in the alert, not a single setting.
Totem test vs totem controls	A totem test is a diagnostic command with a time window. Totem controls are mitigation gates that stay on or off.	totemtest command output versus totem entries in mitigations.yml.
Check category vs check name	The category groups related checks. The check name identifies one rule inside that group.	Headings versus names in the checks reference.

How should you handle trace data?

Trace output can include player names, UUIDs, world identifiers, and file paths. Treat it as sensitive, and redact those values before any external sharing.

What we have not verified

This glossary does not state how often any combat check triggers, its false positive rate, or its accuracy against any cheat client. It does not describe the qualifying criteria for clean beneficiaries. Test combat settings on a staging server with known participants before you change them on a live network.

FAQ

Does reach compensation give an offender extra reach?

No. The mitigation docs say increaseReach is compensation for a qualifying clean beneficiary, and it does not give an offender extra reach.

Is a totem test a cheat detector?

It is a diagnostic command. Its window runs from 50 to 5,000 ms, and staff must review the output before taking any action.

Can I share rotation trace output?

Only after you redact names, UUIDs, world identifiers, and trace paths. The rotation diagnostics guide asks for this before any external sharing.

Why are the rotation checks in the hook exclusion list?

The hook defaults exclude RotationBreak and RotationPlace from that hook. Check the current hooks.yml value on your server, since the default is listed there.

Why does the rotation command reject my arguments?

The docs say the command takes two arguments after the subcommand, in an order the installed usage message defines. Read that message on your server before you retry, since argument names can differ by version.