Troubleshooting and Known Limitations

This chapter covers the server-side failure modes operators most often see: joins rejected before gameplay, password-gated joins, noisy diagnostics, asset-transfer issues, and stale configuration.

Log prefixes

Anomaly server messages use predictable prefixes:

[Anomaly] for plugin lifecycle, networking, asset, and general operational messages.
[Diag] for detailed authentication, role, command, and spawn diagnostics.

Use these prefixes to filter your server logs when investigating a report.

Auth and role diagnostics

Diagnostic logging is enabled when Anomaly is running. It records enough information to correlate a player join, identity assignment, role changes, remote-admin state, and spawn events.

A typical role-related investigation starts by searching the affected player’s @anomaly ID, then reading the surrounding [Diag] lines.

If diagnostic output is too noisy, filter it in your log aggregation tool. There is no in-game config toggle for it today.

Common failures

Clients connect, then drop immediately

Check for these broad causes:

The player is using a vanilla client.
The player and server are on incompatible Anomaly releases.
The server requires a password and the player entered the wrong password or canceled the prompt.
The player’s local identity is invalid or missing.
The server did not finish loading Anomaly during startup.

Ask the player to update the Launcher and launch the modded game once. If the issue affects all players, verify the server DLLs came from the same Anomaly release.

Password-protected joins fail for everyone

Run password status in the server console. If password auth is required but no password is configured, set one with password <value> or disable the requirement with password clear.

On startup, the server logs whether password auth is required and whether a password is configured. If the password is required but missing, clients are rejected until an operator fixes the state.

One player is temporarily blocked after password failures

Repeated bad password attempts from one IP can trigger a temporary block. By default, the block lasts five minutes.

If this is too strict for your environment, adjust PasswordMaxFailuresPerIp or PasswordBlockSeconds in the Anomaly config. Setting either value to 0 disables password failure blocking.

Late joiners show no custom textures or broken assets

Confirm AssetDirectory points to the expected folder and that the server process can read it. The server startup log should report that assets were discovered.

If only one player is affected, have them reconnect or clear their local asset cache from the Launcher/runtime paths documentation.

Asset changes do not appear on clients

New files and changed files are not always equivalent from a runtime perspective. For reliable production updates, restart the server after changing the asset set.

During development, reconnecting the client is the fastest way to confirm whether the asset folder is correct.

Plugin works on vanilla IDs but not Anomaly IDs

Review any plugin code or config that assumes Steam IDs. On Anomaly servers, user IDs end with @anomaly and should be treated as first-class user IDs.

Known limitations operators ask about

No runtime disable

Do not unload Anomaly mid-round. Stop the server before removing or replacing Anomaly DLLs.

No config toggle for diagnostics

Filter [Diag] lines externally if needed.

Asset path changes need restart

Changing the configured asset directory requires a server restart.

Password changes apply to new joins

The password command affects new connection attempts immediately. It does not kick players who are already connected.

Reporting bugs

Open issues at the Anomaly GitHub tracker. Include:

Server log around the failure.
LabAPI version, Anomaly version, and other plugins loaded.
Reproduction steps.
The affected @anomaly ID if the issue is player-specific.