Catching Xray, Admin Abuse, and Unapproved Mods on a Vintage Story Server

Catching Xray, Admin Abuse, and Unapproved Mods

Checked on 14 October 2026 against the Vintage Story 1.22.7 server.

Two versions of this problem come up constantly on Vintage Story servers. Someone is pulling ore far faster than the terrain should allow and you suspect xray. Or worse, you discover months into a world that a player had privileges they should never have had and quietly used them.

Both are investigable, and the tools are already on your server. This page covers what the logs actually record, why the usual permission setup causes the second problem, and which claims you should not make.

Start With the Logs, Not the Accusation

Vintage Story writes several separate server logs, and two of them are the entire investigation:

Pull these before you talk to anyone. See where Vintage Story stores server logs for exact locations.

Investigating Suspected Xray

Vintage Story has no built-in xray detection, so there is no switch to flip and no report to run. What you have is server-build.log (once LogBlockBreakPlace is on), and it is more useful than people expect, because xray does not change what a player breaks, it changes the shape of how they get there.

Read the suspect's break history and look for:

• Tunnels that go straight to ore with no branching, no dead ends, and no exploratory digging. Honest prospecting produces a lot of wasted stone.
• Direction changes that only ever pay off. A player who turns left three times and hits copper three times is describing knowledge they should not have.
• Ore yield against time played. Compare the suspect with a known-honest player on the same world. You are looking for an order-of-magnitude gap, not a modest one.
• No use of the intended mechanic. The game gives you prospecting for exactly this job. Someone finding everything without ever using it is a signal.

The Admin Abuse Problem Is a Privileges Problem

When a player turns out to have replaced tools, skipped storms, or protected their own base, the root cause is almost always the same: somebody ran /op on them. Operator status is not a moderation tier, it is the whole keyring, and it is far more than a trusted friend needs to open a door for you while you are away.

Grant single capabilities instead:

/player [playername] privilege grant [privilege]
/player [playername] privilege revoke [privilege]

The privileges worth understanding before you hand any of them out:

gamemode and give are the two that let a player silently rewrite a survival world. If your goal is "my friend can let people in while I am at work", neither is needed.

Build a Moderator Role Instead

Roles are defined in serverconfig.json as a Roles array, each entry carrying a Code, a PrivilegeLevel, and an explicit Privileges list. The 1.22.7 server already ships a moderator tier, sumod:

{
  "Code": "sumod",
  "PrivilegeLevel": 200,
  "Name": "Survival Moderator",
  "Privileges": ["controlplayergroups", "manageplayergroups", "manageotherplayergroups",
    "chat", "areamodify", "build", "useblock", "buildblockseverywhere",
    "useblockseverywhere", "kick", "ban", "announce", "readlists",
    "attackcreatures", "attackplayers", "selfkill"]
}

It can kick, ban and build or open things anywhere, but has no give, gamemode, tp or controlserver, which makes it the role to hand a trusted friend instead of /op (which is shorthand for /player <name> role admin). New arrivals land on whatever DefaultRoleCode is set to, normally suplayer. The stock roles are suvisitor, crvisitor, limitedsuplayer, limitedcrplayer, suplayer, crplayer, sumod, crmod and admin. Use /role [rolename] [property] to tune a role's spawn point and land-claim allowance, and /player <name> stats to see a player's role and every privilege they hold.

Stopping Unapproved Client Mods

This is the question with the least satisfying answer, so here it is straight: you cannot reliably enumerate what a connecting client has installed locally. The server distributes the mods it requires and clients pull those down, but a purely client-side mod is not something the server is given a trustworthy inventory of. Any guide promising a complete client mod audit is overselling it.

You can, however, tell clients what not to load. The server sends its /serverconfig modblacklist and modwhitelist to every player who joins, and a standard client then refuses to load a blacklisted mod, or, when a whitelist is set, any client-side mod that is not on it. A modified client can ignore that, so treat it as a fence for honest players rather than proof.

What you can actually control:

• Which mods the server requires and ships, so everyone is at least running your baseline. See installing mods.
• Who gets in at all. WhitelistMode accepts Default (on for dedicated servers, off for LAN), On, or Off. For a friends world, On and nothing else.
• A join password via the Password key, as a second gate.
• Behaviour in the logs, which is where a client-side advantage eventually becomes visible anyway.

If clients are stuck in a download or resync loop rather than cheating, that is a different problem: see the mod sync loop fix.

What the Built-In Anti-Abuse Actually Covers

Vintage Story watches movement on its own: /player <name> stats shows a Fly suspicion count and a Tele/Speed suspicion count for anyone online. The protection you configure is the AntiAbuse setting, set with /serverconfig antiabuse:

{
  "AntiAbuse": 1,
  "AntiAbuseBufferSize": 100,
  "AntiAbuseTriggerOnBlockBreakCount": 40,
  "AntiAbuseTriggerOnDurationMs": 2000,
  "AntiAbuseBlockBurstAbuseBanDays": 14.0
}

AntiAbuse is 0 (Off) by default. At 1 (Basic) the server checks a player's reach when they place, break or use blocks, and since 1.22.6 any level above Off also bans block-break bursts automatically: with the values above, 40 blocks broken within 2,000 ms earns a 14 day ban. That is real protection worth turning on. It does nothing about xray, item duplication, or a player with privileges they were handed on purpose, so do not treat it as coverage of the problems above.

The build log also lets you undo a griefer. Since 1.22.6 the server can restore blocks that chosen players removed: put a names.txt with one player name per line (and optionally a blocks.txt of block codes) into a folder and start the server once with --restoreLogsFolder pointing at it. It replays server-build.log, restores the blocks and shuts down, which only works if LogBlockBreakPlace was on when the damage happened.

Prevention That Costs You Nothing

1. Whitelist on, from the first session. Since 1.20 that is the default for a dedicated server; keep it.
2. Nobody gets /op unless they would be a co-owner of the world.
3. Land claims around shared builds. Start with /land claim new, mark two corners with /land claim start and /land claim end, add the area with /land claim add and keep it with /land claim save; /land free releases a claim.
4. Back up before you investigate, not after. Any rollback you might want depends on having a copy from before the damage. See Save Management.
5. Re-read your privilege grants every few months. Temporary grants become permanent by default.

Next Steps

• Full admin command list with examples
• Where server logs live
• Running a high player count server
• LAN, VPN, or hosted server

For version-specific command syntax, the authoritative reference is the official list of server commands. In game, /chb (or the Command Handbook button in the pause menu) opens the Command Handbook for the exact commands your build supports.

Want logs, backups, and the console in one place instead of over SSH? Run Vintage Story on Supercraft.