Paper and Spigot Settings That Change Anticheat Behavior

Which server settings can change anticheat results?

Server-level settings can change connection handling, packet limits, tick timing, chunk visibility, and entity simulation. An anticheat reads the same server state, so a settings change can shift what it sees. Review these areas before you enable enforcement, and read the current Paper or Spigot documentation for the exact key names in your build.

Which files should you open first?

Settings are split across several files. Open each one before you change anything and copy its current values into your change log.

• server.properties, for authentication, view distance, simulation distance, and compression.
• Paper's global and per-world configuration files, for packet limits and world-level tick behavior.
• spigot.yml, for settings that Spigot exposes for entities and world ticking.
• bukkit.yml, for server-wide plugin and spawn behavior.
• Any plugin config that changes packet handling or player movement on the server.

Which server.properties keys matter for combat checks?

These four keys appear in server.properties. Confirm each one in the file your build generates before editing, because key names can change between releases.

online-mode=<true|false>
view-distance=<chunks>
simulation-distance=<chunks>
network-compression-threshold=<bytes>

What does each key change for an anticheat?

online-mode decides how players authenticate, which changes who can join and how identity is checked. Check your anticheat's documentation for its behavior on offline-mode servers and behind a proxy.

view-distance and simulation-distance control which chunks the server sends and which entities it ticks. Players near the edge of loaded area can see different targets, so combat evidence near that edge needs more care.

network-compression-threshold changes packet size and when compression applies. Test it in staging if you change it, because compression changes packet timing.

How do packet limits and entity settings affect alerts?

Paper's global configuration has a packet limit area that can disconnect players who send too many packets. A disconnect from that limit is a server event, not an anticheat verdict, so log it separately.

Spigot and Paper also expose entity activation and tick range settings in their world configuration. Those settings decide when distant entities stop being simulated. Check the current docs for the keys in your version, then test a small change on staging.

Which settings should you record together?

Settings only make sense in combination with the others. Keep one table for each change so the staff team can see what moved and when.

Why can a settings change look like an anticheat bug?

A change to tick range, view distance, or packet limits changes the data the anticheat receives, so alerts can move even when the anticheat itself is unchanged. Staff who see a new pattern of alerts after a settings change often blame the plugin first. Compare the timing of the alerts with the timing of the settings change in your log before you change anticheat thresholds.

The reverse also happens. A settings change can hide a real problem by removing the conditions that produced an alert. Keep the old settings value in the record, so a quiet period can be explained rather than assumed to be good news.

How do you test a settings change?

Make one change per staging run, so you know which setting caused any change in alerts. Keep the alert-only window open long enough to cover a normal peak.

• Record the current value of every setting in the table above.
• Change one area on a staging copy, and restart the server.
• Run an alert-only window with testers who play the same way your players do.
• Compare alert counts, tick time from your profiler, and player reports with the baseline.
• Write the result and the rollback value in the change log before you apply it to production.