Fix: dproto Installed but Non-Steam Clients Are Still Rejected

You dropped dproto in to allow non-Steam clients, restarted, and non-Steam players are still refused — kicked at connect, or shown as invalid. dproto is a Metamod plugin (or a direct engine module) that lets original HLDS accept non-Steam clients, but it only works when it is the right tool for your engine, is actually loaded, and is configured to accept the client type your players run. Here is the checklist that resolves it.

1. Use the right emulator for your engine

This is the most common mistake. The rule:

• Original HLDS — use dproto.
• ReHLDS — use Reunion, not dproto.

If you are running ReHLDS and installed dproto, it may load but misbehave or refuse clients, because the two projects target different engines. On ReHLDS, remove dproto and install Reunion instead; note that Reunion needs a SteamIdHashSalt of at least 16 characters in its config or it refuses to load at all. See the ReHLDS install guide for which stack you are actually on.

2. Confirm dproto is actually loaded

An installed file is not a loaded module. If you run dproto through Metamod, it must be listed in addons/metamod/plugins.ini:

linux addons/dproto/dproto_i386.so

Check at runtime from the server console:

meta list

dproto must appear with a running/ok status. If it is absent, the path in plugins.ini is wrong or the .so is missing. If Metamod itself is not loading, that is upstream — see the metamod.so load fix first, because nothing dproto-related works until Metamod runs.

3. Set dproto.cfg to accept non-Steam clients

dproto is configured through dproto.cfg. The setting that decides which client types are allowed governs whether Steam-only, non-Steam-only, or both can connect. The client-type value must permit non-Steam:

# dproto.cfg (values control accepted client types)
client_ss_check 0
# accept both Steam and non-Steam clients rather than Steam-only

If dproto is set to accept only validated Steam clients, non-Steam players are rejected by design — exactly the symptom. Set it to allow non-Steam (or both) client types, and restart the server so the config is re-read.

4. Align the protocol version

dproto exposes a protocol setting. If it is pinned to a protocol your clients do not speak, they are bounced with a version-style rejection. If your community runs a specific client build, match dproto's protocol to it; if in doubt, allow the protocol your players actually use rather than forcing one. A protocol mismatch here presents almost identically to the different-version error, so if the rejection mentions the game version, suspect the protocol setting.

5. Do not run two emulators at once

Running dproto and Reunion (or dproto twice under different names) simultaneously makes them fight over the same connection hooks, and clients get rejected unpredictably. Pick one emulator for your engine and remove the other from plugins.ini entirely. Confirm with meta list that exactly one non-Steam emulator is loaded.

6. Restart, do not just change map

dproto hooks the engine at load, so config changes to dproto.cfg and edits to plugins.ini are only picked up on a full server restart, not a changelevel. Admins often edit the config, change the map, see no difference, and conclude dproto is broken — when in fact the old configuration is still resident. Stop the server process fully and start it again after any dproto config change, then re-check meta list. If you edit the client-type or protocol setting live, nothing takes effect until that restart, which explains a great many "I changed it and it still rejects them" reports.

Common errors

• dproto loaded but non-Steam still rejected — the client-type setting in dproto.cfg only accepts Steam clients. Allow non-Steam.
• dproto not in meta list — wrong path in plugins.ini or a missing/mis-architecture .so.
• Rejected with a game-version message — protocol mismatch. Align dproto's protocol to the clients.
• Running ReHLDS, dproto flaky — wrong tool; switch to Reunion (with a 16+ char SteamIdHashSalt).
• Random rejections — two emulators loaded at once. Keep exactly one.

Verification

From the console, confirm the module is live:

meta list

dproto should show as running. Then connect with a non-Steam client and confirm it joins and appears in status with a valid ID. Because ranks and bans key off SteamID, also confirm non-Steam players get stable IDs rather than all sharing one — if they collide, revisit the ID-hashing settings, the same concern covered in finding a player's SteamID. A clean non-Steam join plus a distinct ID per player means the emulator is doing its job.