How to Make Your Server Accept Non-Steam Players

Out of the box a CS 1.6 server validates clients against Steam and rejects non-Steam ("no-Steam") builds. Accepting them is a deliberate choice: you install a connection-layer plugin that answers the validation itself and assigns each non-Steam player a SteamID. There are two, and which one you use depends on your engine: Reunion on ReHLDS, dproto on original HLDS. Do not run both.

1. Pick the right one for your engine

• ReHLDS → Reunion. Reunion is written for ReHLDS and is the current, maintained choice. This is what you should be running.
• Original Valve HLDS → dproto. dproto predates ReHLDS and still works on stock engines. If you are on stock HLDS in 2026, the better move is to switch to ReHLDS + Reunion.

Both are Metamod plugins, so you need a working Metamod-r first — verify with meta list.

2. Install Reunion (ReHLDS)

Reunion ships as a Metamod plugin plus a config. Place the plugin binary under the addons tree and register it in Metamod's plugin list:

cstrike/addons/reunion/reunion_mm_i386.so     <-- the plugin
cstrike/addons/reunion/reunion.cfg            <-- its config

Add it to cstrike/addons/metamod/plugins.ini above AMXX:

linux addons/reunion/reunion_mm_i386.so

3. Set the mandatory SteamIdHashSalt

This is the step people miss, and Reunion will not load without it. In reunion.cfg:

SteamIdHashSalt = your_long_random_salt_at_least_16_chars

The salt must be at least 16 characters. Shorter and Reunion refuses to start, which shows up as Reunion missing from meta list. The salt is what turns a non-Steam player's identity into a stable STEAM_ID-style string — change it later and every non-Steam player's ID changes with it, which resets their stats and their admin access. Set it once and never touch it.

4. Decide who is allowed in

Reunion's config controls which client types are accepted — Steam, non-Steam (Steam emulators / Revolution Emulator), or both. Configure the authentication providers in reunion.cfg to match your policy. The common setups are "both Steam and non-Steam" (maximum audience) or "non-Steam only" (a purely no-Steam community). Read the shipped config's comments for the exact provider keys in your build rather than guessing.

5. Fix admin identification

This is the real operational consequence. A non-Steam player's SteamID is generated from their name and your salt, not issued by Valve — so it is only as trustworthy as the name is unique. For admins on a non-Steam-friendly server you have two choices:

• Name + password auth in users.ini — the reliable option for non-Steam admins:

; users.ini
"AdminName"  "adminpassword"  "abcdefghijklmnopqrstu"  "a"

with the matching flags including the "requires password" flag, so an impostor with the same name but no password gets nothing. Relying on the generated SteamID alone for admin access on a non-Steam server is how admin gets stolen.

Common errors

• Reunion missing from meta list — the SteamIdHashSalt is unset or shorter than 16 characters, or the plugins.ini path/architecture is wrong (Linux line must point at the .so).
• Non-Steam clients still get STEAM validation rejected — Reunion/dproto is not actually loading, or you left VAC/secure mode fighting it. See the validation-rejected fix.
• Running Reunion and dproto together — they both answer validation and conflict. Pick one.
• All non-Steam players share one SteamID — the salt is empty or the provider config is collapsing identities. Set a proper salt and correct providers.
• Admins lost access after a config change — you changed the salt, which changed every generated ID. Move admins to name+password auth.

Verification

Restart and confirm the plugin loaded:

meta list

Reunion (or dproto) must show as RUN. Then connect with an actual non-Steam client and, in the server console, run status — the player must appear with a STEAM_ ID, not be rejected. Have that player disconnect and reconnect: their ID must stay the same across sessions (this is what the salt guarantees). Finally, log an admin in via name+password and confirm amx_who shows their flags. When a non-Steam player connects, keeps a stable ID, and a non-Steam admin authenticates, the setup is complete.

What accepting non-Steam actually costs you

It is worth being clear-eyed about the trade, because it is not free. A Valve-issued SteamID is cryptographically tied to an account; a Reunion-generated ID is a hash of a name and your salt, so on a non-Steam-friendly server, identity is roughly "whoever types this name". That has three practical consequences you should plan for from the start:

• Stats and reserved slots keyed on SteamID are spoofable by name. If you run a ranking or shop system, expect people to impersonate each other's names to claim progress. Password-gating the things that matter is the only real defence.
• Bans by SteamID are weaker — a banned non-Steam player changes their name and returns with a new ID. Non-Steam servers lean harder on IP bans as a result; see your ban manager for combining the two.
• Admin must be password-based, as above, because SteamID-only admin is trivially stolen.

None of this is a reason not to accept non-Steam players — for most CS 1.6 communities it is where the audience is. It is a reason to build your admin, ban and stats systems assuming identity is weak, rather than discovering it the first time someone wears an admin's name.