--- title: "How to Make Your Server Accept Non-Steam Players" excerpt: "Let non-Steam CS 1.6 clients connect: Reunion on ReHLDS or dproto on HLDS, the mandatory SteamIdHashSalt, and how admin identification changes when SteamIDs are not real." category: "installation" tags: "non-steam, reunion" image: "" read_time: "8 min read" ---

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

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:

; 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

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:

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.