AntiXRay

Packet-based ore protection

AntiXRay masks protected ore states in outgoing chunk and block data before the client receives them. It is designed to prevent the client from learning hidden ore locations in the first place, rather than banning a player for displaying known blocks.

Fully enclosed ores remain masked, including across chunk borders. Unknown neighboring chunk edges stay masked until the required context arrives. Cave ores require a sampled clear sightline within the 96-block visibility range. Movement and reveal work is processed in bounded slices.

Previously disclosed unchanged states may remain visible. A legitimately revealed cave ore is not necessarily a protection failure. The subsystem only hides ores: it does not hide chests, containers, entities or players.

Turn XRay Protection on or off

packet-privacy:
  enabled: true
  dashboard-managed: true
  max-chunks-per-player: 1024
  max-block-states-per-player: 134217728

In the dashboard, choose a server and use XRay Protection under Server Health or in Settings alongside the check switches. Owners and operators can request ON or OFF; viewers can only read the status. The dashboard shows the request as pending until the plugin confirms the saved state.

The plugin saves packet-privacy.enabled and packet-privacy.dashboard-managed: true together in config.yml. The latter preserves your choice after a restart even when a beta or upload-test profile otherwise enables ore protection automatically. The ordinary unmanaged configuration defaults to enabled: false.

Dashboard ON/OFF is applied live. Already loaded chunks are updated in bounded slices: OFF restores masked ore states, while ON remasks protected ores. Movement prediction and client-world history continue while ore hiding is disabled. Data that a client already received while protection was off cannot be erased from a cheat’s memory; reconnect for a clean comparison.

This control requires the updated plugin JAR. An older server may report only AntiXRay statistics and does not expose the switch. A full server restart is required after replacing the JAR, changing packet-adapter budgets or editing this configuration manually.

max-chunks-per-player bounds tracked chunks. max-block-states-per-player bounds logical tracked block states; the default represents approximately 512 MiB of state storage before arrays and metadata overhead in the worst case. These are ceilings, not a reservation or normal per-player usage estimate. Consider view distance and player count before deployment.

Failure behavior

If the privacy adapter or protected write fails, the affected viewer is disconnected instead of receiving the original unfiltered protected data. Budget exhaustion also disconnects rather than silently evicting states and leaking ores. This is a confidentiality safeguard, not cheat evidence or an automatic ban.

The retired packet-privacy.containers setting is ignored. There is no AntiESP switch to enable container or entity hiding.

Inspect the protection

Run /arionac privacy <player> with arionac.connection. The output includes handler status, build/server information, processed packets and chunks, masked entries, block updates and reveal counts. The dashboard also presents AntiXRay independently of the check list.

After enabling protection, reconnect the test client so old client-cached chunks do not confuse the comparison. Check enclosed ores and legitimately visible cave ores separately. Report the exact block context and handler status if hidden ores still appear.