Fix links to tutorials that do not exist (5 files)
Browse SourceEach link pointed at a slug that never existed; it now points to the tutorial that covers it.
5 changed files
with 5 additions and 5 deletions
M
cs16-missing-map-when-joining/en.md
+1 -1
M
fix-meta-list-no-amxx/en.md
+1 -1
M
fix-pterodactyl-cs16-wont-start/en.md
+1 -1
M
fix-reunion-wrong-steamids/en.md
+1 -1
M
install-mysql-module-amxx/en.md
+1 -1
cs16-missing-map-when-joining/en.md
M
| @@ -29,7 +29,7 @@ cstrike_downloads\maps\ (custom/downloaded content on some builds)</pre> | ||
| 29 | 29 | <p>After the 2023 25th Anniversary update, some servers and download setups broke against the new client. If custom-content servers consistently fail for you but simple <code>de_dust2</code> servers work, try rolling the client back to the <strong>steam_legacy</strong> beta branch (right-click Counter-Strike in Steam, Properties, Betas). Legacy behaves like the pre-2023 client that most 1.6 servers were built and tested against.</p> |
| 30 | 30 | |
| 31 | 31 | <h2>5. Understand the server side (so you can tell the admin)</h2> |
| 32 | -<p>When the download is merely slow rather than failing, the server admin has not set up FastDL. FastDL is an HTTP mirror declared on the server with <code>sv_downloadurl</code>; the client pulls maps, models and sounds over HTTP at full speed instead of the throttled UDP channel. The in-game channel is capped at a few KB/s by <code>sv_downloadurl</code>'s absence, so a 10 MB map can take minutes and frequently times out before it finishes. If you run the server yourself, see <a href="/tutorials/fix-fastdl-not-working">FastDL not working</a> and <a href="/tutorials/setup-fastdl-http-server">setting up a FastDL server</a>.</p> | |
| 32 | +<p>When the download is merely slow rather than failing, the server admin has not set up FastDL. FastDL is an HTTP mirror declared on the server with <code>sv_downloadurl</code>; the client pulls maps, models and sounds over HTTP at full speed instead of the throttled UDP channel. The in-game channel is capped at a few KB/s by <code>sv_downloadurl</code>'s absence, so a 10 MB map can take minutes and frequently times out before it finishes. If you run the server yourself, see <a href="/tutorials/fix-fastdl-not-working">FastDL not working</a> and <a href="/tutorials/install-cs16-server-nginx-fastdl">setting up a FastDL server</a>.</p> | |
| 33 | 33 | |
| 34 | 34 | <h3>Why the map is "missing" even after downloading</h3> |
| 35 | 35 | <p>The engine validates each downloaded file against a checksum the server sends. If your on-disk copy differs by even one byte — a truncated download, or an older version of the same map name — the client rejects it and reports the map as missing rather than loading a mismatched file. This is why deleting the local copy (step 2) is so often the fix: it forces a fresh, checksum-matched download from the server or its mirror.</p> |
fix-meta-list-no-amxx/en.md
M
| @@ -6,5 +6,5 @@ tags: "metamod, amxmodx" | ||
| 6 | 6 | image: "" |
| 7 | 7 | read_time: "7 min read" |
| 8 | 8 | --- |
| 9 | -<p>Metamod itself is working — <code>meta version</code> answers and <code>meta list</code> prints something — but AMX Mod X is not in that list, so none of your admin commands, stats, or plugins exist. This is almost always a registration problem: AMX Mod X is itself a Metamod plugin, and Metamod only loads it if it is correctly listed in Metamod's own plugin file with a valid path to the right binary. Metamod loading does not imply AMXX loading; they are two separate steps.</p><h2>1. Confirm what meta list actually shows</h2><p>From the server console:</p><pre>meta list</pre><p>Every Metamod plugin appears here with a status. AMX Mod X should show as a running plugin. If it is missing entirely, Metamod never tried to load it — the line is absent or wrong. If it appears but with a bad status, the file was found but failed to load (wrong architecture, corrupt, or missing dependency). Those are different fixes, so read the status before changing anything.</p><h2>2. Check the Metamod plugins.ini entry</h2><p>AMX Mod X is registered in Metamod's plugin list, not the engine's:</p><pre>addons/metamod/plugins.ini</pre><p>This file must contain a line pointing at the AMXX Metamod binary. The format is a platform tag followed by the path. On Linux:</p><pre>linux addons/amxmodx/dlls/amxmodx_mm_i386.so</pre><p>On Windows:</p><pre>win32 addons\amxmodx\dlls\amxmodx_mm.dll</pre><p>Do not confuse this with <code>addons/amxmodx/configs/plugins.ini</code>, which lists your <code>.amxx</code> scripts. That file is only ever read <em>after</em> AMXX loads. If AMXX is not in <code>meta list</code>, editing the AMXX plugins.ini does nothing — you are one layer too high.</p><h2>3. Fix the filename and platform traps</h2><p>Three things break this line constantly:</p><ul><li><strong>Wrong platform tag</strong> — a <code>win32</code> line on a Linux box (or vice versa) is silently ignored, so AMXX never loads and there is no error. Match the tag to the OS.</li><li><strong>Wrong architecture suffix</strong> — the Linux binary is typically the 32-bit <code>amxmodx_mm_i386.so</code>. If your line points at a name that does not exist on disk, nothing loads. List the <code>addons/amxmodx/dlls/</code> folder and use the exact filename that is there.</li><li><strong>Wrong relative path</strong> — the path is relative to the mod folder (<code>cstrike/</code>). A leading slash or an extra <code>cstrike/</code> breaks it.</li></ul><h2>4. Confirm Metamod is loaded via the game DLL, not the reverse</h2><p>Because <code>meta list</code> works, Metamod is loaded correctly (through <code>liblist.gam</code> or the plus-set gamedll override). That rules out the Metamod-side install and points the finger squarely at the AMXX line. If instead <code>meta version</code> failed too, you would have a Metamod problem, not an AMXX one — see the broader <a href="/tutorials/install-metamod-amxmodx">Metamod and AMX Mod X install guide</a> for that case.</p><h2>5. Match the AMXX build to the engine</h2><p>The classic GoldSrc engine is 32-bit, so the AMXX Metamod binary must be the 32-bit build. Mixing a 64-bit <code>.so</code> against a 32-bit engine gives a bad load rather than a missing entry, and the reverse (a 32-bit binary the OS cannot load because the 32-bit runtime libraries are absent on a 64-bit-only host) fails the same way. If <code>meta list</code> shows AMXX with a bad status rather than as running, this architecture mismatch is the usual reason — re-copy the AMXX release that matches your engine, and on a 64-bit Linux host make sure the i386 C runtime is installed so a 32-bit <code>.so</code> can load at all. The Windows build has no such split, but the <code>win32</code> tag must still match the OS.</p><h2>Troubleshooting</h2><ul><li><strong>AMXX absent from <code>meta list</code></strong> — the line in <code>addons/metamod/plugins.ini</code> is missing, commented, or has the wrong platform tag.</li><li><strong>Line present but status is bad load</strong> — the binary exists but is the wrong architecture (a 64-bit <code>.so</code> against a 32-bit engine) or corrupt. Re-copy the matching build.</li><li><strong>Edited the wrong plugins.ini</strong> — you added your scripts to <code>addons/amxmodx/configs/plugins.ini</code>, but AMXX is registered in <code>addons/metamod/plugins.ini</code>. Fix the Metamod one first.</li><li><strong>Nothing changed after editing</strong> — the file is only read at map load. Change the map or restart the server.</li><li><strong><code>amxx version</code> is an unknown command</strong> — AMXX genuinely did not load, confirming the <code>meta list</code> finding; keep working the Metamod line, not the AMXX config.</li></ul><h2>Verification</h2><p>Change the map so both plugin files are re-read, then run <code>meta list</code> again — AMX Mod X should now appear as running. Confirm from the other side with:</p><pre>amxx version | |
| 9 | +<p>Metamod itself is working — <code>meta version</code> answers and <code>meta list</code> prints something — but AMX Mod X is not in that list, so none of your admin commands, stats, or plugins exist. This is almost always a registration problem: AMX Mod X is itself a Metamod plugin, and Metamod only loads it if it is correctly listed in Metamod's own plugin file with a valid path to the right binary. Metamod loading does not imply AMXX loading; they are two separate steps.</p><h2>1. Confirm what meta list actually shows</h2><p>From the server console:</p><pre>meta list</pre><p>Every Metamod plugin appears here with a status. AMX Mod X should show as a running plugin. If it is missing entirely, Metamod never tried to load it — the line is absent or wrong. If it appears but with a bad status, the file was found but failed to load (wrong architecture, corrupt, or missing dependency). Those are different fixes, so read the status before changing anything.</p><h2>2. Check the Metamod plugins.ini entry</h2><p>AMX Mod X is registered in Metamod's plugin list, not the engine's:</p><pre>addons/metamod/plugins.ini</pre><p>This file must contain a line pointing at the AMXX Metamod binary. The format is a platform tag followed by the path. On Linux:</p><pre>linux addons/amxmodx/dlls/amxmodx_mm_i386.so</pre><p>On Windows:</p><pre>win32 addons\amxmodx\dlls\amxmodx_mm.dll</pre><p>Do not confuse this with <code>addons/amxmodx/configs/plugins.ini</code>, which lists your <code>.amxx</code> scripts. That file is only ever read <em>after</em> AMXX loads. If AMXX is not in <code>meta list</code>, editing the AMXX plugins.ini does nothing — you are one layer too high.</p><h2>3. Fix the filename and platform traps</h2><p>Three things break this line constantly:</p><ul><li><strong>Wrong platform tag</strong> — a <code>win32</code> line on a Linux box (or vice versa) is silently ignored, so AMXX never loads and there is no error. Match the tag to the OS.</li><li><strong>Wrong architecture suffix</strong> — the Linux binary is typically the 32-bit <code>amxmodx_mm_i386.so</code>. If your line points at a name that does not exist on disk, nothing loads. List the <code>addons/amxmodx/dlls/</code> folder and use the exact filename that is there.</li><li><strong>Wrong relative path</strong> — the path is relative to the mod folder (<code>cstrike/</code>). A leading slash or an extra <code>cstrike/</code> breaks it.</li></ul><h2>4. Confirm Metamod is loaded via the game DLL, not the reverse</h2><p>Because <code>meta list</code> works, Metamod is loaded correctly (through <code>liblist.gam</code> or the plus-set gamedll override). That rules out the Metamod-side install and points the finger squarely at the AMXX line. If instead <code>meta version</code> failed too, you would have a Metamod problem, not an AMXX one — see the broader <a href="/tutorials/install-metamod-r">Metamod-r install guide</a> for that case.</p><h2>5. Match the AMXX build to the engine</h2><p>The classic GoldSrc engine is 32-bit, so the AMXX Metamod binary must be the 32-bit build. Mixing a 64-bit <code>.so</code> against a 32-bit engine gives a bad load rather than a missing entry, and the reverse (a 32-bit binary the OS cannot load because the 32-bit runtime libraries are absent on a 64-bit-only host) fails the same way. If <code>meta list</code> shows AMXX with a bad status rather than as running, this architecture mismatch is the usual reason — re-copy the AMXX release that matches your engine, and on a 64-bit Linux host make sure the i386 C runtime is installed so a 32-bit <code>.so</code> can load at all. The Windows build has no such split, but the <code>win32</code> tag must still match the OS.</p><h2>Troubleshooting</h2><ul><li><strong>AMXX absent from <code>meta list</code></strong> — the line in <code>addons/metamod/plugins.ini</code> is missing, commented, or has the wrong platform tag.</li><li><strong>Line present but status is bad load</strong> — the binary exists but is the wrong architecture (a 64-bit <code>.so</code> against a 32-bit engine) or corrupt. Re-copy the matching build.</li><li><strong>Edited the wrong plugins.ini</strong> — you added your scripts to <code>addons/amxmodx/configs/plugins.ini</code>, but AMXX is registered in <code>addons/metamod/plugins.ini</code>. Fix the Metamod one first.</li><li><strong>Nothing changed after editing</strong> — the file is only read at map load. Change the map or restart the server.</li><li><strong><code>amxx version</code> is an unknown command</strong> — AMXX genuinely did not load, confirming the <code>meta list</code> finding; keep working the Metamod line, not the AMXX config.</li></ul><h2>Verification</h2><p>Change the map so both plugin files are re-read, then run <code>meta list</code> again — AMX Mod X should now appear as running. Confirm from the other side with:</p><pre>amxx version | |
| 10 | 10 | amxx plugins</pre><p><code>amxx version</code> should print the AMXX build, and <code>amxx plugins</code> should list your scripts loading. Once AMXX shows in <code>meta list</code> and answers <code>amxx version</code>, the two-layer chain — engine loads Metamod, Metamod loads AMXX, AMXX loads your plugins — is intact, and any remaining issue is with an individual script, which is a different problem covered in <a href="/tutorials/fix-amxx-module-failed-to-load">module failed to load</a>.</p> |
fix-pterodactyl-cs16-wont-start/en.md
M
| @@ -7,4 +7,4 @@ image: "" | ||
| 7 | 7 | read_time: "8 min read" |
| 8 | 8 | --- |
| 9 | 9 | <p>You imported a CS 1.6 egg into Pterodactyl, deployed a server, and it either sits on <strong>Starting</strong> forever or flips straight back to <strong>Offline</strong>. Pterodactyl adds two layers on top of a plain HLDS install — the Wings daemon running the container and the egg defining the startup command and detection strings — and a failure in either looks identical from the panel. This walks through the real causes in the order they actually occur.</p><h2>1. Read the console, not the status pill</h2><p>The status pill lies; the console tells the truth. Open the server's <strong>Console</strong> tab and start it, watching the raw output. HLDS prints its own errors there before Wings gives up. The lines you are looking for are the loader errors, for example:</p><pre>./hlds_run: line 123: ./hlds_linux: not found |
| 10 | -error while loading shared libraries: libstdc++.so.6: cannot open shared object file</pre><p>That <code>not found</code> on a file that plainly exists is the classic 32-bit symptom — the binary is there but the loader for it is not. Note the exact line and move to the matching step below rather than restarting blindly.</p><h2>2. Fix the missing 32-bit libraries</h2><p>HLDS ships a 32-bit <code>hlds_linux</code> binary. If the Docker image the egg points to is 64-bit-only, the kernel cannot load it and you get the <code>not found</code> above. Check the egg's <strong>Docker Image</strong> under the server's <strong>Startup</strong> tab; it must be an image with i386 libraries. A minimal fix is an image based on Debian with <code>libc6:i386</code>, <code>libstdc++6:i386</code>, and <code>libncurses5:i386</code> installed. If you built your own image, add the i386 architecture and those packages; if you used a community egg, switch the Docker image field to the one its documentation specifies. This is the same 32-bit dependency problem covered for bare-metal installs in <a href="/tutorials/install-hlds-on-linux">the HLDS Linux install guide</a>.</p><h2>3. Check the startup command variables</h2><p>Pterodactyl builds the launch line from the egg's startup command plus per-server variables. A wrong variable produces a server that starts and immediately exits. On the <strong>Startup</strong> tab confirm the command resolves to something like:</p><pre>./hlds_run -game cstrike -console +ip 0.0.0.0 -port {{SERVER_PORT}} +map {{SRCDS_MAP}} +maxplayers {{MAX_PLAYERS}}</pre><p>Two variables break servers most often: an empty or misspelled <code>SRCDS_MAP</code> (set it to a map you actually have, e.g. <code>de_dust2</code>), and a <code>MAX_PLAYERS</code> above 32, which CS 1.6 rejects. Bind to <code>0.0.0.0</code> and use <code>{{SERVER_PORT}}</code> so the port matches the allocation Pterodactyl assigned — hardcoding <code>27015</code> when the panel gave you a different port means the container never binds where Wings expects.</p><h2>4. Confirm the install script finished</h2><p>The egg's install script runs SteamCMD to download HLDS into <code>/mnt/server</code> before the first boot. If that install failed — Steam rate-limiting, a full disk, a network block — you have a server directory with no <code>hlds_run</code> in it. In <strong>Settings → Reinstall Server</strong>, trigger the install again and watch the install log. It must end without SteamCMD errors and leave <code>hlds_run</code> and the <code>cstrike/</code> folder in the root. A half-populated directory is why a freshly created server refuses to boot with no obvious HLDS error at all.</p><h2>5. Fix the 'started' detection string</h2><p>Wings decides a server is <strong>running</strong> by matching a configured string in the console output. If the egg's <strong>Startup Configuration</strong> looks for text HLDS never prints, the process runs fine but the panel shows <strong>Starting</strong> forever and eventually kills it. The reliable marker HLDS emits once it is up is its address line; set the egg's startup detection to a stable substring such as:</p><pre>"Server IP address"</pre><p>Edit this under the egg (Admin area → Nests → your egg → Configuration → Startup) as valid JSON in the <code>done</code> field. After saving, the next start transitions to <strong>Running</strong> the moment HLDS prints that line.</p><h2>Troubleshooting</h2><ul><li><strong><code>./hlds_linux: not found</code></strong> — the Docker image lacks 32-bit libraries. Switch to an i386-capable image (step 2).</li><li><strong>Sits on 'Starting' but the console shows the map loaded</strong> — the Wings detection string does not match HLDS output. Fix the egg's <code>done</code> string (step 5).</li><li><strong>'Container marked as running but process not responding'</strong> — the process exited immediately; scroll the console up for the real error, usually a bad variable or missing map.</li><li><strong>Flaps between Offline and Starting</strong> — the install never completed. Reinstall and read the install log (step 4).</li><li><strong>Starts but nobody can connect</strong> — the port bound does not match the allocation. Use <code>{{SERVER_PORT}}</code> and check the primary allocation. See <a href="/tutorials/fix-rcon-not-working-remote">remote connectivity</a> for the firewall side.</li><li><strong><code>Only 32 player slots supported</code> or silent exit</strong> — <code>MAX_PLAYERS</code> exceeds 32. Lower it.</li></ul><h2>Verification</h2><p>Start the server and confirm the console reaches the map load and the address line, and that the status pill turns green. From another machine, query the server with <code>status</code> over <a href="/tutorials/fix-rcon-not-working-remote">RCON</a> or connect directly on the panel's allocated IP and port. If it runs cleanly in the console but Wings still will not mark it online, the problem is always the detection string, not HLDS — and if HLDS itself errors, the first line of that error names the exact cause. Once it boots reliably, layer your plugins on with <a href="/tutorials/install-amx-mod-x-1-9">AMX Mod X</a>.</p> | |
| 10 | +error while loading shared libraries: libstdc++.so.6: cannot open shared object file</pre><p>That <code>not found</code> on a file that plainly exists is the classic 32-bit symptom — the binary is there but the loader for it is not. Note the exact line and move to the matching step below rather than restarting blindly.</p><h2>2. Fix the missing 32-bit libraries</h2><p>HLDS ships a 32-bit <code>hlds_linux</code> binary. If the Docker image the egg points to is 64-bit-only, the kernel cannot load it and you get the <code>not found</code> above. Check the egg's <strong>Docker Image</strong> under the server's <strong>Startup</strong> tab; it must be an image with i386 libraries. A minimal fix is an image based on Debian with <code>libc6:i386</code>, <code>libstdc++6:i386</code>, and <code>libncurses5:i386</code> installed. If you built your own image, add the i386 architecture and those packages; if you used a community egg, switch the Docker image field to the one its documentation specifies. This is the same 32-bit dependency problem covered for bare-metal installs in <a href="/tutorials/install-cs16-dedicated-server-linux-steamcmd">the HLDS Linux install guide</a>.</p><h2>3. Check the startup command variables</h2><p>Pterodactyl builds the launch line from the egg's startup command plus per-server variables. A wrong variable produces a server that starts and immediately exits. On the <strong>Startup</strong> tab confirm the command resolves to something like:</p><pre>./hlds_run -game cstrike -console +ip 0.0.0.0 -port {{SERVER_PORT}} +map {{SRCDS_MAP}} +maxplayers {{MAX_PLAYERS}}</pre><p>Two variables break servers most often: an empty or misspelled <code>SRCDS_MAP</code> (set it to a map you actually have, e.g. <code>de_dust2</code>), and a <code>MAX_PLAYERS</code> above 32, which CS 1.6 rejects. Bind to <code>0.0.0.0</code> and use <code>{{SERVER_PORT}}</code> so the port matches the allocation Pterodactyl assigned — hardcoding <code>27015</code> when the panel gave you a different port means the container never binds where Wings expects.</p><h2>4. Confirm the install script finished</h2><p>The egg's install script runs SteamCMD to download HLDS into <code>/mnt/server</code> before the first boot. If that install failed — Steam rate-limiting, a full disk, a network block — you have a server directory with no <code>hlds_run</code> in it. In <strong>Settings → Reinstall Server</strong>, trigger the install again and watch the install log. It must end without SteamCMD errors and leave <code>hlds_run</code> and the <code>cstrike/</code> folder in the root. A half-populated directory is why a freshly created server refuses to boot with no obvious HLDS error at all.</p><h2>5. Fix the 'started' detection string</h2><p>Wings decides a server is <strong>running</strong> by matching a configured string in the console output. If the egg's <strong>Startup Configuration</strong> looks for text HLDS never prints, the process runs fine but the panel shows <strong>Starting</strong> forever and eventually kills it. The reliable marker HLDS emits once it is up is its address line; set the egg's startup detection to a stable substring such as:</p><pre>"Server IP address"</pre><p>Edit this under the egg (Admin area → Nests → your egg → Configuration → Startup) as valid JSON in the <code>done</code> field. After saving, the next start transitions to <strong>Running</strong> the moment HLDS prints that line.</p><h2>Troubleshooting</h2><ul><li><strong><code>./hlds_linux: not found</code></strong> — the Docker image lacks 32-bit libraries. Switch to an i386-capable image (step 2).</li><li><strong>Sits on 'Starting' but the console shows the map loaded</strong> — the Wings detection string does not match HLDS output. Fix the egg's <code>done</code> string (step 5).</li><li><strong>'Container marked as running but process not responding'</strong> — the process exited immediately; scroll the console up for the real error, usually a bad variable or missing map.</li><li><strong>Flaps between Offline and Starting</strong> — the install never completed. Reinstall and read the install log (step 4).</li><li><strong>Starts but nobody can connect</strong> — the port bound does not match the allocation. Use <code>{{SERVER_PORT}}</code> and check the primary allocation. See <a href="/tutorials/fix-rcon-not-working-remote">remote connectivity</a> for the firewall side.</li><li><strong><code>Only 32 player slots supported</code> or silent exit</strong> — <code>MAX_PLAYERS</code> exceeds 32. Lower it.</li></ul><h2>Verification</h2><p>Start the server and confirm the console reaches the map load and the address line, and that the status pill turns green. From another machine, query the server with <code>status</code> over <a href="/tutorials/fix-rcon-not-working-remote">RCON</a> or connect directly on the panel's allocated IP and port. If it runs cleanly in the console but Wings still will not mark it online, the problem is always the detection string, not HLDS — and if HLDS itself errors, the first line of that error names the exact cause. Once it boots reliably, layer your plugins on with <a href="/tutorials/install-amx-mod-x-1-9">AMX Mod X</a>.</p> |
fix-reunion-wrong-steamids/en.md
M
| @@ -6,4 +6,4 @@ tags: "reunion, steamid" | ||
| 6 | 6 | image: "" |
| 7 | 7 | read_time: "8 min read" |
| 8 | 8 | --- |
| 9 | -<p>You installed Reunion so non-Steam players get stable, unique Steam IDs, but players still show <code>STEAM_ID_LAN</code>, share one ID, or get a different ID every reconnect — which breaks admin flags, bans, and <a href="/tutorials/setup-stats-system">stats</a> that are all keyed by SteamID. Reunion works, but only when its salt and ID-generation mode are configured correctly, and a common failure is that it silently did not load at all. Here is how to get real, stable IDs.</p><h2>1. Confirm Reunion actually loaded</h2><p>Reunion is a Metamod plugin. If it is not listed in Metamod's plugin list, nothing it does is happening and the engine falls back to <code>STEAM_ID_LAN</code> for non-Steam clients. From the server console:</p><pre>meta list</pre><p>Reunion must appear with status <code>running</code>. If it is absent, its line is missing from <code>addons/metamod/plugins.ini</code>; if it shows <code>bad load</code>, the most common cause is the salt problem in the next step — Reunion refuses to start without a valid salt.</p><h2>2. Set a SteamIdHashSalt of at least 16 characters</h2><p>This is the single most common reason Reunion does not load. Its config, <code>reunion.cfg</code> in the server root, must define a hash salt of <strong>16 characters or more</strong>. Anything shorter and Reunion refuses to initialize:</p><pre>SteamIdHashSalt = a-long-random-secret-salt-value</pre><p>The salt is what makes generated IDs both unique and stable — it is mixed into the hash that turns a non-Steam client's identity into a persistent <code>STEAM_</code> ID. Once set, <strong>never change it</strong>: changing the salt regenerates every non-Steam player's ID, orphaning their admin access, bans, and rank. Pick one long random value at setup and leave it.</p><h2>3. Choose the right cid (client id) generation mode</h2><p>Reunion generates the ID for non-Steam clients from a source you select in <code>reunion.cfg</code>. The mode decides whether IDs are stable. A mode that keys off something the client can change or that many clients share produces collisions; a mode that keys off the client's stored authentication produces stable, distinct IDs. Set the generation mode per Reunion's documented options in <code>reunion.cfg</code> and prefer the mode that derives the ID from the client's own stored token rather than from an easily-shared value. If two different people consistently get the same ID, your mode is deriving IDs from something they share — switch modes and have them reconnect.</p><h2>4. Match Reunion to your engine</h2><p>Reunion is the non-Steam provider for <strong>ReHLDS</strong>. On original Valve HLDS you use <strong>dproto</strong> instead. Running Reunion on stock HLDS, or an old Reunion build against a newer ReHLDS, can load but misbehave — wrong IDs, or clients that authenticate as Steam when they are not. Confirm you are on ReHLDS (its banner prints at boot) and that Reunion is a build current with your engine, as covered in <a href="/tutorials/fix-regamedll-rehlds-incompatible">the ReHLDS compatibility guide</a>.</p><h2>5. Understand Steam vs non-Steam clients</h2><p>Reunion handles the non-Steam side; genuine Steam clients keep their real Steam ID regardless. If a legitimate Steam player shows a wrong ID, that is not a Reunion issue — check that the server is validating Steam tickets and that <code>sv_lan</code> is <code>0</code>, since a LAN server issues <code>STEAM_ID_LAN</code> to everyone. Mixing this up sends admins chasing Reunion config when the real cause is a LAN-mode server. Set <code>sv_lan 0</code> and confirm real Steam clients resolve to their own IDs before blaming Reunion for non-Steam ones.</p><h2>Troubleshooting</h2><ul><li><strong>Reunion <code>bad load</code> in <code>meta list</code></strong> — <code>SteamIdHashSalt</code> is shorter than 16 characters or missing. Set a long salt (step 2).</li><li><strong>Everyone is <code>STEAM_ID_LAN</code></strong> — Reunion is not loaded at all, or <code>sv_lan 1</code>. Check <code>meta list</code> and set <code>sv_lan 0</code>.</li><li><strong>Two players share one ID</strong> — the cid generation mode derives the ID from a shared value. Change the mode (step 3).</li><li><strong>ID changes every reconnect</strong> — the mode keys off something non-persistent, or the salt was changed. Fix the mode and leave the salt alone.</li><li><strong>All non-Steam bans stopped working after an edit</strong> — you changed <code>SteamIdHashSalt</code> and regenerated every ID. Restore the original salt.</li><li><strong>Wrong engine</strong> — Reunion on stock HLDS. Use <a href="/tutorials/setup-dproto-non-steam">dproto</a> there instead.</li></ul><h2>Verification</h2><p>Have a non-Steam player connect and run <code>status</code> in the console; note their <code>STEAM_</code> ID. Have them reconnect and confirm the ID is identical — stable across sessions is the whole point. Then have a second non-Steam player join and confirm they get a <em>different</em> ID. If IDs are stable per player and distinct between players, Reunion is configured correctly and admin flags, bans and <a href="/tutorials/setup-stats-system">rank</a> will now key reliably. Finally, add a non-Steam admin by their resolved ID and confirm the flag applies on their next connect. Guard <code>reunion.cfg</code> and its salt like a password.</p> | |
| 9 | +<p>You installed Reunion so non-Steam players get stable, unique Steam IDs, but players still show <code>STEAM_ID_LAN</code>, share one ID, or get a different ID every reconnect — which breaks admin flags, bans, and <a href="/tutorials/setup-stats-system">stats</a> that are all keyed by SteamID. Reunion works, but only when its salt and ID-generation mode are configured correctly, and a common failure is that it silently did not load at all. Here is how to get real, stable IDs.</p><h2>1. Confirm Reunion actually loaded</h2><p>Reunion is a Metamod plugin. If it is not listed in Metamod's plugin list, nothing it does is happening and the engine falls back to <code>STEAM_ID_LAN</code> for non-Steam clients. From the server console:</p><pre>meta list</pre><p>Reunion must appear with status <code>running</code>. If it is absent, its line is missing from <code>addons/metamod/plugins.ini</code>; if it shows <code>bad load</code>, the most common cause is the salt problem in the next step — Reunion refuses to start without a valid salt.</p><h2>2. Set a SteamIdHashSalt of at least 16 characters</h2><p>This is the single most common reason Reunion does not load. Its config, <code>reunion.cfg</code> in the server root, must define a hash salt of <strong>16 characters or more</strong>. Anything shorter and Reunion refuses to initialize:</p><pre>SteamIdHashSalt = a-long-random-secret-salt-value</pre><p>The salt is what makes generated IDs both unique and stable — it is mixed into the hash that turns a non-Steam client's identity into a persistent <code>STEAM_</code> ID. Once set, <strong>never change it</strong>: changing the salt regenerates every non-Steam player's ID, orphaning their admin access, bans, and rank. Pick one long random value at setup and leave it.</p><h2>3. Choose the right cid (client id) generation mode</h2><p>Reunion generates the ID for non-Steam clients from a source you select in <code>reunion.cfg</code>. The mode decides whether IDs are stable. A mode that keys off something the client can change or that many clients share produces collisions; a mode that keys off the client's stored authentication produces stable, distinct IDs. Set the generation mode per Reunion's documented options in <code>reunion.cfg</code> and prefer the mode that derives the ID from the client's own stored token rather than from an easily-shared value. If two different people consistently get the same ID, your mode is deriving IDs from something they share — switch modes and have them reconnect.</p><h2>4. Match Reunion to your engine</h2><p>Reunion is the non-Steam provider for <strong>ReHLDS</strong>. On original Valve HLDS you use <strong>dproto</strong> instead. Running Reunion on stock HLDS, or an old Reunion build against a newer ReHLDS, can load but misbehave — wrong IDs, or clients that authenticate as Steam when they are not. Confirm you are on ReHLDS (its banner prints at boot) and that Reunion is a build current with your engine, as covered in <a href="/tutorials/fix-regamedll-rehlds-incompatible">the ReHLDS compatibility guide</a>.</p><h2>5. Understand Steam vs non-Steam clients</h2><p>Reunion handles the non-Steam side; genuine Steam clients keep their real Steam ID regardless. If a legitimate Steam player shows a wrong ID, that is not a Reunion issue — check that the server is validating Steam tickets and that <code>sv_lan</code> is <code>0</code>, since a LAN server issues <code>STEAM_ID_LAN</code> to everyone. Mixing this up sends admins chasing Reunion config when the real cause is a LAN-mode server. Set <code>sv_lan 0</code> and confirm real Steam clients resolve to their own IDs before blaming Reunion for non-Steam ones.</p><h2>Troubleshooting</h2><ul><li><strong>Reunion <code>bad load</code> in <code>meta list</code></strong> — <code>SteamIdHashSalt</code> is shorter than 16 characters or missing. Set a long salt (step 2).</li><li><strong>Everyone is <code>STEAM_ID_LAN</code></strong> — Reunion is not loaded at all, or <code>sv_lan 1</code>. Check <code>meta list</code> and set <code>sv_lan 0</code>.</li><li><strong>Two players share one ID</strong> — the cid generation mode derives the ID from a shared value. Change the mode (step 3).</li><li><strong>ID changes every reconnect</strong> — the mode keys off something non-persistent, or the salt was changed. Fix the mode and leave the salt alone.</li><li><strong>All non-Steam bans stopped working after an edit</strong> — you changed <code>SteamIdHashSalt</code> and regenerated every ID. Restore the original salt.</li><li><strong>Wrong engine</strong> — Reunion on stock HLDS. Move to <a href="/tutorials/install-rehlds-on-linux">ReHLDS</a> (Reunion needs it); dproto is only the old option for stock HLDS.</li></ul><h2>Verification</h2><p>Have a non-Steam player connect and run <code>status</code> in the console; note their <code>STEAM_</code> ID. Have them reconnect and confirm the ID is identical — stable across sessions is the whole point. Then have a second non-Steam player join and confirm they get a <em>different</em> ID. If IDs are stable per player and distinct between players, Reunion is configured correctly and admin flags, bans and <a href="/tutorials/setup-stats-system">rank</a> will now key reliably. Finally, add a non-Steam admin by their resolved ID and confirm the flag applies on their next connect. Guard <code>reunion.cfg</code> and its salt like a password.</p> |
install-mysql-module-amxx/en.md
M
| @@ -86,7 +86,7 @@ public QueryHandler(failstate, Handle:query, error[], errnum, data[], size, Floa | ||
| 86 | 86 | } |
| 87 | 87 | // read rows here with SQL_ReadResult / SQL_MoreResults |
| 88 | 88 | }</pre> |
| 89 | -<p>The rules: build the tuple once in <code>plugin_init()</code>, never inside a per-frame or per-spawn handler; always check <code>failstate</code>; never call <code>SQL_FreeHandle()</code> on a handle you did not create in that callback. Getting the last one wrong crashes the server — see <a href="/tutorials/fix-sqlx-thread-crash">crash in SQLx threaded queries</a>.</p> | |
| 89 | +<p>The rules: build the tuple once in <code>plugin_init()</code>, never inside a per-frame or per-spawn handler; always check <code>failstate</code>; never call <code>SQL_FreeHandle()</code> on a handle you did not create in that callback. Getting the last one wrong crashes the server — see <a href="/tutorials/sqlx-threaded-queries">threaded SQLx queries</a>.</p> | |
| 90 | 90 | |
| 91 | 91 | <h2>Common errors</h2> |
| 92 | 92 | <ul> |
| 93 | 93 |
