Xash3D Clients: What Server Owners Should Know

If you run a non-Steam CS 1.6 server, a large share of your players are not running the original GoldSrc client at all — they are on Xash3D FWGS, an open-source, GoldSrc-compatible engine that powers most of the popular Android and non-Steam PC builds. They connect over the same protocol and play the same maps, but they announce themselves differently, and if your server is not set up to tolerate them they either bounce at connect or show up with mangled identities. Here is what actually matters when they hit your server.

1. What Xash3D is

Xash3D (and its actively maintained fork, Xash3D FWGS) is a clean-room reimplementation of the Half-Life engine. It runs the CS 1.6 game logic, loads standard .bsp maps and models, and speaks the GoldSrc network protocol, so from the wire's point of view it looks like a Half-Life client. It is what the ubiquitous "CS 1.6 for Android" packages are built on, and there are desktop builds too. Because it is not the Steam client, it does not present a real Steam ticket — it connects as a non-Steam client on protocol 48, exactly like an old WON/no-steam PC client.

2. Why your server needs dproto or Reunion

A stock server expects a Steam authentication handshake. Non-Steam clients — including every Xash3D player — cannot provide one, so you need the tolerance layer that lets them in and assigns them an identity:

• dproto on original HLDS.
• Reunion on ReHLDS.

Without one of these, an Xash client either fails to authenticate or is handed a useless STEAM_ID_LAN/VALVE_ identity that breaks bans and stats. Reunion in particular has explicit handling for Xash clients: it can be told to accept them and how to brand the SteamID they receive. Reunion also still requires its SteamIdHashSalt to be at least 16 characters or it refuses to load — that applies whether the connecting client is a PC no-steam build or Xash.

3. Labelling Xash clients with Reunion

Reunion assigns an authentication provider to each connection and lets you decide what SteamID prefix a given provider gets. Xash clients report a distinct identity, so you can route them to their own ID namespace instead of mixing them with revEmu or Steam players. That separation is what keeps two different players from colliding on one SteamID-keyed record — ranks, bans and admin flags all key off the SteamID, so a stable, per-provider ID is what makes them reliable. Configure the provider list and salt in Reunion's config, change the map, and confirm the IDs your Xash players receive are stable across reconnects.

4. Build and version strings differ

Xash3D does not report the same build number as the Valve client. If you gate connections on a specific protocol or build — or run a plugin that inspects the client's version string — expect Xash clients to carry their own values. Do not hard-block on an exact GoldSrc build unless you intend to exclude every Xash player, which on a non-Steam server is usually a large fraction of your population. Some client-info cvars an Xash build reports can also be spoofed or absent, so treat client-reported strings as advisory, never as trust.

5. Cheats and exploits behave differently

Because Xash is a separate engine, some client-side anti-cheat assumptions do not hold: a few exploits that only exist against the Valve client do not apply, and conversely some Xash-specific behaviours (custom cvars, different memory layout) mean a screenshot/consistency check written for GoldSrc may not fire the same way. Server-side detection — sv_consistency, engine-side rate and command validation, and ReHLDS/ReGameDLL sanity checks — is more reliable across both engines than anything that reaches into the client. Keep your anti-cheat server-side and it covers Xash players the same as PC players.

Common issues

• Xash players cannot connect at all — you have no dproto/Reunion loaded, or Reunion failed to load because SteamIdHashSalt is under 16 characters. Check the startup log for Reunion's load line.
• Two Xash players share one rank or ban — they are colliding on an unstable ID. Configure Reunion to give the Xash provider its own SteamID namespace.
• A version/build check kicks them — a plugin or cvar is gating on the Valve build string. Loosen it or exclude the check for non-steam clients.
• Bans do not stick to Xash clients — you are banning a STEAM_ID_LAN placeholder. Ban the real per-provider SteamID Reunion assigns, and see firewall an abusive IP as a fallback.

Verification

Connect once with an Xash3D FWGS build and once with the Steam client, then read the identities the server logged for each — both should get usable, distinct SteamIDs, and reconnecting should return the same ID each time. Type status in the server console during both sessions and confirm neither shows a bare STEAM_ID_LAN. If ranks, bans, and admin flags all work for the Xash session the same as the Steam one, your tolerance layer is configured correctly. If you are choosing an engine, note that Reunion's richer Xash handling is one more reason many non-Steam admins prefer ReHLDS with Reunion over legacy HLDS with dproto.