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

Catching Xray, Admin Abuse, and Unapproved Mods

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.txt, 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 RoleCode, a PrivilegeLevel, and an explicit Privileges list:

{
  "RoleCode": "suplayer",
  "Name": "Survival Player",
  "PrivilegeLevel": 100,
  "Privileges": ["build", "chat", "whisper", "pickup"]
}

New arrivals land on whatever DefaultRoleCode is set to, normally suplayer. The stock roles are suplayer, suvisitor, crplayer and crvisitor. Use /role [rolename] [property] to tune a role's spawn point and land-claim allowance when you want a genuine moderator tier that still cannot spawn diamonds.

Stopping Unapproved Client Mods

This is the question with the least satisfying answer, so here it is straight: you cannot reliably enumerate or block 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.

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 ships movement-based anti-abuse, tuned by two values:

{
  "AntiAbuseMaxWalkBlocksPer200ms": 3,
  "AntiAbuseMaxFlySuspicions": 3
}

These catch speed and flight anomalies, which is real protection worth leaving enabled at sane defaults. They do nothing about xray, item duplication, or a player with privileges they were handed on purpose. Do not treat their presence as coverage of the problems above.

Prevention That Costs You Nothing

1. Whitelist on, from the first session.
2. Nobody gets /op unless they would be a co-owner of the world.
3. Land claims around shared builds. Use /land claim start and /land claim end to mark a protected area, and /land free to release one.
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 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.