Per-Gamemode Anticheat Profiles for One Network

Use one base profile with documented overrides

Use one base anticheat profile for every game mode, then record only the settings each mode is allowed to change. Keep the override list short, give each override a reason and an owner, and generate mode configs from the base file when you can. Profiles that drift apart are hard to review and easy to misconfigure.

Decide which settings may vary by mode

Not every setting should change between modes. Settings that control logging, alert routing, and staff access should match everywhere, because a difference there hides evidence. Settings that describe how players move, fight, or build can differ, but only with a written reason.

Lay out the profile files

Keep one base file and one override file per mode. The layout below is a placeholder. Use the file names and loader behavior your anticheat expects, and confirm how it reads overrides before you copy any file.

anticheat-profiles/
  base.yml               # shared settings, approved by the rollout owner
  overrides/
    pvp-arena.yml        # only keys that differ from base.yml
    survival-smp.yml
    creative-plots.yml
  generated/             # output of a merge step, never edited by hand

Build and review the override list

Each override needs the same four facts: the mode, the key, the base value, and the mode value. Add the reason and the approver. A short, reviewed list is the main thing that keeps per-mode profiles manageable.

• List every key that differs from base.yml in one table with the mode, key, base value, mode value, reason, and approver.
• Require a second reviewer for any override that loosens a check.
• Set a cap on overrides per mode. A mode that needs many overrides probably needs its own tested profile.
• Retest any mode whose overrides change, and retest after each plugin or server update.
• Delete an override when its reason no longer applies, and log the deletion.

Test each profile on its own mode

A profile that passes review on paper can still misfire in play. Before a mode uses a new profile, run it on a staging copy with that mode's plugins and typical player behavior. Watch for alert types that appear only in that mode. Record the tester, the mode, and the profile version. Do not use another mode's test results as proof.

Worked example: an arena inherits a survival value

A survival override loosened a movement check, because the SMP has steep terrain and elytra use. The arena profile was built by copying the survival file, so it inherited the looser value. Arena players never use that terrain, so the looser value only hid movement the arena should have flagged. Nobody noticed for two weeks, because the arena's alert volume was low. The fix was one line. Finding it took a diff of each mode file against base.yml, which is why every override needs a stated reason.

Common mistakes with mode profiles

Per-mode setups usually fail through copying and neglect, not through a single bad setting.

• Copying one mode's file to start another. Inherited values stay in place until someone happens to notice them.
• Letting an override outlive its reason. Review the override list on a fixed schedule.
• Reading low alert volume as proof that a mode's profile is correct. A mode with few players can hide a wrong value for a long time.

Know when one profile is enough

Per-mode profiles reduce accidental drift, but they do not show that any profile is accurate. They also add review work for every change. A network with one or two similar modes can often run one profile with a short, documented list of exceptions, which is easier to keep correct.