If status shows every non-Steam player carrying VALVE_ID_LAN, or the same STEAM_ID_LAN, your entire admin and ban system is broken — because AMX Mod X keys admin flags and bans on the unique id. When everyone shares one id, banning one player bans them all, and granting one admin grants everyone. This is not a plugin bug; it is an authentication configuration problem, and it has two usual causes.
1. sv_lan 0 first
The engine only issues real ids to internet clients. With sv_lan 1, every client — Steam or not — is stamped VALVE_ID_LAN because the server believes it is on a LAN where authentication is pointless. This alone produces the exact "everyone has the same id" symptom. In server.cfg and on the command line:
sv_lan 0
Restart fully and re-check status. If the shared id was VALVE_ID_LAN specifically, this is very often the whole fix.
2. Give non-Steam clients a source of unique ids
Steam clients get their id from Steam. Non-Steam clients have no Steam id to present, so something on the server must derive a stable, unique id for each of them — that is Reunion on ReHLDS (or dproto on original HLDS). If that component is missing or misconfigured, non-Steam clients collapse onto a single fallback id. If non-Steam players cannot even connect, solve that first in non-Steam players can't join; this guide assumes they connect but share an id.
3. The salt is what makes the id unique and stable
Reunion derives each non-Steam player's STEAM_x:y:z from their client identity plus your SteamIdHashSalt. Two rules follow:
- The salt must be at least 16 characters, or Reunion refuses to load and you fall back to a single shared id.
- The salt must be set and never changed. If it is empty, ids are not properly individualised; if you change it, every non-Steam id changes at once, wiping admin and bans.
SteamIdHashSalt = 8f3Kd92lasQ7zXcV19mT
Set a random 16+ character value once, back it up, and leave it alone.
4. Check the client-id modes
Reunion's cid_* options decide how each client type is turned into an id. A misconfiguration here can route several client types onto the same generated id even with a good salt. Start from the shipped defaults and change them only when you understand each mode — the Reunion guide documents what each does. The goal is that revemu/steam-emulated clients each yield their own stable STEAM_x:y:z, not a shared one.
5. Why this matters to admin and bans
AMX Mod X can key admin access to either an id or a name+password, and it keys bans to the unique id. If you run id-based admins, your addons/amxmodx/configs/users.ini entries look like this:
"STEAM_0:1:12345678" "" "abcdefghijklmnopqrstu" "ce"
The first field is the authid. When every non-Steam player collapses onto one shared id, that single line grants — or bans — all of them at once. This is why the symptom shows up as "I banned one cheater and half the server vanished", or "I gave one friend admin and now everyone has it". The moment ids become unique and stable, both amx_ban by id and id-based users.ini entries behave correctly again. Check who is who live with:
amx_who
which prints each connected player's name, authid and access flags — the fastest way to confirm every player now carries a distinct id.
Common errors
- Everyone is
VALVE_ID_LAN—sv_lan 1. Step 1. - Everyone is the same
STEAM_ID_LANdespitesv_lan 0— no working non-Steam auth provider, or Reunion failed to load because the salt is too short. - Ids were unique, then all changed on the same day — someone changed
SteamIdHashSalt. There is no recovery for the old ids other than restoring the previous salt; keep a backup of it. - Steam players fine, non-Steam share an id — Reunion loaded but the
cid_*modes are collapsing client types. Step 4.
Verification
Get two different non-Steam players (or two non-Steam clients on different machines) connected at once and run:
status
The uniqueid column must show two different STEAM_x:y:z values — not VALVE_ID_LAN, not the same id twice. Then have one of them disconnect and reconnect: their id must be the same as before, proving it is stable across sessions (which is what makes bans and admin persist). Distinct ids per player, stable across reconnects, means the fix holds and your admin/ban system will behave again.
