Add 7 tutorials (7 files)
Browse Source
Daemon666 committed
parent 13654c6d9c
commit 489d5597a706ce95437dda7d328fda939a626b55
7 changed files
with 75 additions and 0 deletions
A
amxx-not-loading-install-checklist/en.md
+10 -0
A
cheap-hosting-vs-real-vps/en.md
+9 -0
A
fix-libstdcpp-so-6-not-found/en.md
+16 -0
A
fix-no-access-to-that-command/en.md
+9 -0
A
fix-server-is-full-when-empty/en.md
+10 -0
A
fix-sys-error-fatal/en.md
+11 -0
A
list-server-on-tsarvar/en.md
+10 -0
amxx-not-loading-install-checklist/en.md
A
| @@ -0,0 +1,10 @@ | ||
| 1 | +--- | |
| 2 | +title: "AMX Mod X Installed but Not Loading: The Install Checklist" | |
| 3 | +excerpt: "A top-to-bottom checklist for when AMX Mod X is copied in but amx_version does nothing: Metamod chain, plugins.ini, module architecture, and reading the exact load lines." | |
| 4 | +category: "installation" | |
| 5 | +tags: "amxmodx, troubleshooting" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>You copied AMX Mod X into <code>addons/</code>, restarted, typed <code>amx_version</code>, and got nothing. AMX Mod X not loading is almost never mysterious — it is a broken link in a fixed chain: the engine loads Metamod, Metamod loads the AMX Mod X core, the core loads its modules and then your plugins. If any link fails, everything above it silently does nothing. This checklist walks the chain from the bottom up so you find the broken link instead of guessing.</p><h2>1. Confirm Metamod is loaded first</h2><p>AMX Mod X is a Metamod plugin, so if <a href="/tutorials/install-metamod-r">Metamod</a> is not loaded, AMX Mod X cannot be either. Metamod is enabled by a <code>gamedll</code> line in <code>liblist.gam</code> (or <code>metamod.dll</code>/<code>.so</code> referenced there). At startup the console prints Metamod's banner; if you never see Metamod announce itself, fix that before touching AMX Mod X. See <a href="/tutorials/fix-metamod-bad-load">Metamod bad load</a>. Confirm at runtime from the server console:</p><pre>meta list</pre><p>AMX Mod X must appear in that list with a <code>RUN</code> status. If it is not in <code>meta list</code> at all, Metamod is not being told to load it — check <code>addons/metamod/plugins.ini</code> (the Metamod one, not the AMXX one) for the line pointing at the AMX Mod X core:</p><pre>linux addons/amxmodx/dlls/amxmodx_mm_i386.so | |
| 10 | +win32 addons\amxmodx\dlls\amxmodx_mm.dll</pre><h2>2. Verify the core actually initialised</h2><p>If AMX Mod X is in <code>meta list</code> but shows a bad status, the core loaded but failed. Check the console at boot for the AMX Mod X banner and any error, and run:</p><pre>amxx version</pre><p>No response here means the core is not running even though Metamod referenced it — usually a wrong path in the Metamod <code>plugins.ini</code> or a 32/64-bit mismatch (below).</p><h2>3. The 32-bit trap on Linux</h2><p>HLDS/ReHLDS and the AMX Mod X binaries are 32-bit. On a 64-bit Linux host without the i386 C libraries, the <code>.so</code> cannot be loaded and Metamod reports it failed. The tell is a load error mentioning the library cannot be opened or wrong ELF class. Install the 32-bit libraries as in <a href="/tutorials/install-32bit-libraries-cs16-linux">32-bit libraries on Linux</a>. This is the single most common reason a fresh AMX Mod X install "does nothing" on a modern 64-bit server, and it produces no obvious message unless you read the load lines carefully, so check it early rather than reinstalling everything in frustration.</p><h2>4. Check plugins.ini and the plugins folder</h2><p>The core can load fine while your plugins do not. Plugins are listed in <code>addons/amxmodx/configs/plugins.ini</code> and the <code>.amxx</code> files live in <code>addons/amxmodx/plugins/</code>. Run:</p><pre>amxx plugins</pre><p>Each plugin shows <code>running</code>, <code>paused</code>, or <code>bad load</code>. A <code>bad load</code> means the file is missing, corrupt, or needs a module you do not have — see <a href="/tutorials/fix-plugins-bad-load-after-19">plugins bad load</a>. If the list is empty, <code>plugins.ini</code> is not being read: wrong path, or you edited a copy in the wrong <code>configs</code> folder. Remember the list is only re-read on map change, so change the map after editing.</p><h2>5. Check the modules the plugins need</h2><p>Plugins that need a module (cstrike, fun, csx, sqlx) fail to load if that module is not enabled in <code>addons/amxmodx/configs/modules.ini</code>. Confirm the modules are running:</p><pre>amxx modules</pre><p>A module reading <code>bad load</code> here cascades into every plugin that depends on it; see <a href="/tutorials/fix-amxx-module-failed-to-load">module failed to load</a> and <a href="/tutorials/install-amxx-modules">installing modules</a>.</p><h2>Common errors</h2><ul><li><strong><code>amx_version</code> unknown command</strong> — the core is not running. Work up from <code>meta list</code>; AMX Mod X is not in Metamod's chain.</li><li><strong>AMX Mod X missing from <code>meta list</code></strong> — the Metamod <code>plugins.ini</code> line is wrong or absent, or the path points at a file that does not exist.</li><li><strong>Load error mentioning the <code>.so</code> cannot be opened</strong> — missing 32-bit libraries on a 64-bit host. Install i386 libs.</li><li><strong>Core runs but no admin commands</strong> — plugins loaded but you are not recognised as admin; that is a <a href="/tutorials/fix-admin-not-recognized">users.ini/auth</a> problem, not a load problem.</li><li><strong>Edited plugins.ini, nothing changed</strong> — it is re-read on map change only. Change the map.</li></ul><h2>Verification</h2><p>Walk the chain in order and confirm each rung: <code>meta list</code> shows AMX Mod X as <code>RUN</code>, <code>amxx version</code> prints a version, <code>amxx modules</code> shows your modules running, and <code>amxx plugins</code> shows your plugins <code>running</code>. When all four are clean, <code>amx_version</code> in the console returns the version string and admin commands respond. If any rung is broken, that rung is your problem — everything above it will stay silent until you fix it. For a clean install from scratch, follow <a href="/tutorials/install-amx-mod-x-1-9">installing AMX Mod X 1.9</a>.</p> |
cheap-hosting-vs-real-vps/en.md
A
| @@ -0,0 +1,9 @@ | ||
| 1 | +--- | |
| 2 | +title: "Cheap Game Hosting vs a Real VPS: What Breaks" | |
| 3 | +excerpt: "The concrete limits of a shared cheap game-hosting slot versus a real VPS -- root access, custom builds, FPS, and DDoS handling -- and which one your server actually needs." | |
| 4 | +category: "hosting" | |
| 5 | +tags: "hosting, vps" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>You can rent a CS 1.6 server two ways: a cheap "game hosting" slot from a control-panel provider for a few dollars, or a real VPS you administer yourself. Both run a server; they are not the same product. The cheap slot trades control for convenience, and the things it takes away are exactly the things a serious server eventually needs. This is a concrete list of what breaks on shared game hosting, so you can decide before you are locked in, not after.</p><h2>1. Root access and what you can install</h2><p>The defining difference is root. A VPS gives you a full Linux box — you <code>ssh</code> in, install what you want, and control every file. Cheap game hosting gives you a web panel and a restricted file manager over one server instance. That restriction is the source of most "why can't I" tickets:</p><ul><li>You cannot swap the engine for <a href="/tutorials/install-rehlds-on-linux">ReHLDS</a> or install <a href="/tutorials/install-regamedll-cs16">ReGameDLL</a> if the panel does not offer it — and many do not.</li><li>You cannot install a system package, a 32-bit library, or a custom module that needs shell access.</li><li>You cannot run a helper process — a stats web panel, a Discord RCON bot, an HLTV proxy — alongside the server.</li></ul><p>On a VPS all of that is just "install it." On a panel slot, if the provider did not build it in, you are stuck.</p><h2>2. Server FPS and shared CPU</h2><p>CS 1.6 server smoothness is a function of server FPS, and server FPS is a function of CPU you actually get. A cheap slot is one tenant among many on a shared box, so your FPS depends on what your neighbours are doing — a noisy neighbour steals cycles and your server stutters at peak with nothing you can fix. A VPS with dedicated or fairly-allocated vCPU lets you tune for <a href="/tutorials/stable-1000-fps-linux-server">stable high server FPS</a> and the <a href="/tutorials/rehlds-performance-cvars">performance cvars</a> that need a real engine build. If your mod is movement-sensitive — bhop, KZ, surf, deathrun — the shared-CPU jitter is felt directly by players, and it is the most common reason a cheap slot "feels laggy" while the ping looks fine.</p><h2>3. DDoS handling</h2><p>CS 1.6 servers get attacked — A2S query floods and UDP floods are routine. On a VPS you can apply your own <a href="/tutorials/block-udp-flood-iptables">iptables rules</a> and <a href="/tutorials/stop-a2s-query-flood">A2S flood mitigation</a>, and choose a <a href="/tutorials/ddos-protected-hosting">DDoS-protected host</a>. On a locked-down panel slot you get whatever protection the provider bundles and no ability to add your own firewall rules. For a small server this may never matter; for a popular one it is the difference between riding out an attack and being offline every evening someone decides to hit you.</p><h2>4. When cheap hosting is the right call</h2><p>None of this makes shared hosting wrong — it makes it a specific tool. It is the right choice when: you are testing whether a server idea will even attract players and do not want to learn Linux yet; you run a stock mod the panel supports out of the box; and your player count is small enough that shared CPU never saturates. For a first server that might be dead in a month, paying for and administering a VPS is over-investment. The mistake is staying on the slot after you have outgrown it — when you are fighting the panel's limits weekly, that friction is the signal to move.</p><h2>5. Choosing a VPS when you move up</h2><p>When you do graduate, the VPS choice is mostly about single-thread CPU performance and network location, not core count — one CS 1.6 server is effectively single-threaded, so a fast core beats many slow ones. Pick a datacentre close to your players for low ping, confirm the provider allows game servers and offers DDoS filtering, and size the box for the number of servers you plan to run. The full checklist is in <a href="/tutorials/choose-vps-for-cs16">choosing a VPS for CS 1.6</a>, and running several servers on one box is covered in <a href="/tutorials/multiple-cs16-servers-one-vps">multiple servers on one VPS</a>.</p><h2>Common problems</h2><ul><li><strong>Cannot install ReHLDS/ReGameDLL</strong> — the panel does not expose it and you lack shell access. This needs a VPS.</li><li><strong>Server stutters at peak despite good ping</strong> — shared-CPU contention on a cheap slot. A noisy neighbour is stealing cycles.</li><li><strong>Offline every time you are attacked</strong> — no ability to add firewall rules on a locked panel. Move to a VPS with DDoS filtering.</li><li><strong>Cannot run a stats panel or RCON bot</strong> — no room for a second process on a slot. A VPS runs helpers alongside.</li><li><strong>Overpaying for an idle VPS</strong> — the opposite mistake: a tiny test server does not need one. Match the tool to the stage.</li></ul><h2>Verification</h2><p>Before committing to a cheap slot, ask the provider directly whether you get ReHLDS/ReGameDLL, whether you can add firewall rules, and whether you can run a second process — if any answer is no and you will need it, the slot is a dead end. On a VPS, verify what you are paying for: measure your actual <a href="/tutorials/measure-server-fps">server FPS</a> under load and confirm it holds steady at peak. Steady FPS on a busy server with your own firewall rules in place is the concrete payoff of the VPS; if a cheap slot delivers that for your player count, you did not need to move yet.</p> |
fix-libstdcpp-so-6-not-found/en.md
A
| @@ -0,0 +1,16 @@ | ||
| 1 | +--- | |
| 2 | +title: "Fix: error while loading shared libraries: libstdc++.so.6" | |
| 3 | +excerpt: "Why a 32-bit CS 1.6 server can't find libstdc++.so.6 on a 64-bit host, enabling the i386 architecture, installing the right packages, using ldd to find every missing dependency, and LD_LIBRARY_PATH." | |
| 4 | +category: "errors" | |
| 5 | +tags: "linux, libraries" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>You start <code>hlds_run</code> and it dies immediately with:</p><blockquote>error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory</blockquote><p>The library is almost certainly installed — but the <strong>32-bit</strong> copy the server needs is not. HLDS, ReHLDS, Metamod and the game DLL are all 32-bit binaries, and on a modern 64-bit Linux host the i386 versions of their dependencies are not present by default. This is the most common first-boot error on a fresh server. Here is the fix.</p><h2>1. Confirm the binary is 32-bit</h2><p>Verify what you are actually running:</p><pre>file hlds_linux</pre><p>It should report <code>ELF 32-bit LSB executable, Intel 80386</code>. A 32-bit binary needs 32-bit (<code>:i386</code>) libraries; the 64-bit <code>libstdc++.so.6</code> already on your system does not satisfy it, which is why the file "exists" yet is "not found" for this process. The two builds install side by side — the 64-bit copy lives in <code>/usr/lib/x86_64-linux-gnu/</code> and the 32-bit copy in <code>/usr/lib/i386-linux-gnu/</code> — and a 32-bit process only ever looks at the latter. Having one does not give you the other.</p><h2>2. Enable the i386 architecture and update</h2><p>On Debian/Ubuntu, tell dpkg it may install i386 packages, then refresh:</p><pre>sudo dpkg --add-architecture i386 | |
| 10 | +sudo apt-get update</pre><p>Without <code>--add-architecture i386</code>, the i386 packages are not even installable and the next step fails to find them.</p><h2>3. Install the 32-bit runtime</h2><p>Install the core 32-bit libraries the server stack needs:</p><pre>sudo apt-get install -y libstdc++6:i386 libc6:i386 lib32gcc-s1 libncurses5:i386</pre><p>On RHEL/CentOS/AlmaLinux the equivalent is the <code>.i686</code> packages:</p><pre>sudo dnf install -y libstdc++.i686 glibc.i686 libgcc.i686</pre><p>The <code>:i386</code> / <code>.i686</code> suffix is the whole point — it pulls the 32-bit build alongside the 64-bit one, and the loader then finds <code>libstdc++.so.6</code> for a 32-bit process.</p><h2>4. Use ldd to find every missing dependency</h2><p>Do not fix one library and rediscover the next by trial and error. Ask the loader what is missing:</p><pre>ldd hlds_linux | |
| 11 | +ldd cstrike/dlls/cs.so</pre><p>Any line ending in <code>=> not found</code> is a dependency you still lack. Each corresponds to an <code>:i386</code> package — install it and re-run <code>ldd</code> until nothing reports <code>not found</code>. Run <code>ldd</code> on the game DLL and on Metamod too, since <a href="/tutorials/fix-failed-to-open-metamod-so">a metamod.so load failure</a> and <a href="/tutorials/fix-failed-to-load-server-dll">a cs.so load failure</a> are frequently the same missing-32-bit-lib problem seen from a different binary.</p><h2>5. Point LD_LIBRARY_PATH at bundled libraries if needed</h2><p>Some server packages ship their own copies of certain libraries in the install directory. If a needed library only exists there, tell the loader to look:</p><pre>export LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH | |
| 12 | +./hlds_run -game cstrike -console +map de_dust2</pre><p>This is also how the AMXX compiler image resolves its 32-bit <code>amxxpc</code> dependencies. Prefer installing the proper system package where one exists; use <code>LD_LIBRARY_PATH</code> only for libraries genuinely bundled with the server and not available as a package.</p><h2>6. Make it stick under systemd or Docker</h2><p>A fix that works in your interactive shell but not when the server runs as a service almost always comes down to environment. A systemd unit does not inherit your login shell's <code>LD_LIBRARY_PATH</code>, so set it in the unit itself:</p><pre>[Service] | |
| 13 | +WorkingDirectory=/home/cs/hlds | |
| 14 | +Environment=LD_LIBRARY_PATH=/home/cs/hlds:. | |
| 15 | +ExecStart=/home/cs/hlds/hlds_run -game cstrike -console +map de_dust2 +maxplayers 20 | |
| 16 | +</pre><p>For a container, install the <code>:i386</code> packages in the image build so every rebuild has them — do not install them into a running container, since that change is lost on the next <code>docker compose up --build</code>. Baking the dependency into the Dockerfile is what stops <a href="/tutorials/fix-docker-hlds-exits-immediately">the container exiting immediately</a> on a fresh host.</p><h2>Common errors</h2><ul><li><strong><code>libstdc++.so.6: cannot open shared object file</code></strong> — the 32-bit lib is missing. Install <code>libstdc++6:i386</code>.</li><li><strong><code>libc6:i386</code> won't install / not found</strong> — you skipped <code>dpkg --add-architecture i386</code> then <code>apt-get update</code>.</li><li><strong>Fixed one lib, now another is missing</strong> — run <code>ldd</code> and install every <code>not found</code> at once.</li><li><strong><code>./hlds_linux: No such file or directory</code></strong> on a file that exists — the 32-bit loader/libs are missing entirely; same fix.</li><li><strong>Works from one shell, fails from a service</strong> — the service unit lacks your <code>LD_LIBRARY_PATH</code>; set it in the unit file.</li></ul><h2>Verification</h2><p>Re-run the dependency check and confirm nothing is missing:</p><pre>ldd hlds_linux | grep -i 'not found'</pre><p>No output means every dependency resolves. Then start the server in the foreground and confirm it reaches a map instead of dying at load:</p><pre>./hlds_run -game cstrike -console +map de_dust2</pre><p>A clean boot past the shared-library stage means the 32-bit runtime is complete. If a container keeps exiting at this stage, fold these packages into the image build — see <a href="/tutorials/fix-docker-hlds-exits-immediately">the Docker exits-immediately fix</a>.</p> |
fix-no-access-to-that-command/en.md
A
| @@ -0,0 +1,9 @@ | ||
| 1 | +--- | |
| 2 | +title: "Fix: 'You have no access to that command' on amx_ban" | |
| 3 | +excerpt: "Why an admin command is refused, how AMXX flags map to commands, the users.ini SteamID and password auth traps, and reloading admins so your access takes effect." | |
| 4 | +category: "errors" | |
| 5 | +tags: "admin, access" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>You type an admin command and AMX Mod X refuses it:</p><pre>You have no access to that command</pre><p>This means AMXX either does not recognize you as an admin at all, or it recognizes you but your access flags do not include the one that specific command requires. Every admin command is gated by a flag; being "an admin" is not enough — you need the right flag for that command. The fix is to get your admin entry recognized and give it the flags the command demands.</p><h2>1. Check whether AMXX sees you as an admin</h2><p>From in-game, list the recognized admins:</p><pre>amx_who</pre><p>This shows every connected player and their access flags. If your name shows no flags (or you are not listed as admin), AMXX did not match you to an admin entry — an authentication problem (step 3). If you <em>are</em> listed but missing a flag, it is a permissions problem (step 2). Read <code>amx_who</code> before assuming which one you have.</p><h2>2. Map the command to its flag</h2><p>AMXX commands require specific access flags, defined by letter. The relevant ones for moderation:</p><ul><li><strong><code>b</code></strong> — reservation / slot access.</li><li><strong><code>c</code></strong> — kick access (<code>amx_kick</code>).</li><li><strong><code>d</code></strong> — ban access (<code>amx_ban</code>, <code>amx_banip</code>).</li><li><strong><code>e</code></strong> — slay/slap access.</li><li><strong><code>f</code></strong> — map change access.</li></ul><p>So <code>amx_ban</code> specifically needs flag <code>d</code>. An admin set up with only <code>c</code> can kick but will get "no access" on a ban. The commonly assigned "full admin" flag string bundles most of these; if your entry has a narrow flag set, widen it to include <code>d</code> for banning.</p><h2>3. Fix the users.ini entry and its auth mode</h2><p>Admins are defined in:</p><pre>addons/amxmodx/configs/users.ini</pre><p>Each line is an identity, a password, an access-flags string, and an account-flags string that says <em>how</em> to authenticate:</p><pre>"STEAM_0:1:12345678" "" "abcdefghijklmnopqrstu" "ce"</pre><p>The last field is where recognition breaks. The account flag decides the auth method:</p><ul><li><strong><code>c</code></strong> means "this is a SteamID" — authenticate by Steam ID, no password. This is the reliable method for a Steam server.</li><li><strong><code>d</code></strong> in the account field means match by IP.</li><li>Without <code>c</code>/<code>d</code>/<code>e</code> set appropriately, AMXX expects a <strong>password</strong> and you must set <code>setinfo _pw "yourpass"</code> in your client config — forget that and you are never authenticated.</li></ul><p>The most common failure is a SteamID entry whose account flag does not include <code>c</code>, so AMXX waits for a password that never comes and treats you as a non-admin. Set the account flag to authenticate by SteamID and make sure the SteamID string matches your real ID exactly — find yours with <a href="/tutorials/find-player-steamid">the SteamID guide</a>.</p><h2>4. Reload admins so the change takes effect</h2><p>Editing <code>users.ini</code> does nothing until AMXX re-reads it. From the console:</p><pre>amx_reloadadmins</pre><p>This reloads the admin list without a map change. Reconnect if your access still is not picked up, since some setups match admins on connect. Then run <code>amx_who</code> again and confirm your flags now include what the command needs.</p><h2>5. Check the immunity and default-access cvars</h2><p>Two settings quietly change who can do what. <code>amx_default_access</code> grants a baseline flag string to <em>every</em> connecting player — leave it empty on a public server, because a stray value here can either hand out access you did not intend or, if misconfigured, interfere with how entries are matched. Separately, a target's immunity flag (<code>a</code>) blocks lower admins from acting on them, so a ban that is refused because the target is immune reads differently from "no access to that command" — the command ran but the action was denied. If <code>amx_who</code> shows you hold flag <code>d</code> yet a specific ban still fails, check whether the target carries immunity rather than assuming your own access is broken. Keeping the flag model explicit — who is an admin, what flags they hold, and who is immune — is what stops these three separate refusals from blurring together.</p><h2>Troubleshooting</h2><ul><li><strong>Not listed as admin in <code>amx_who</code></strong> — auth failed. The SteamID does not match, or the account flag does not say to auth by SteamID, or a required password is unset.</li><li><strong>Listed but missing flag <code>d</code></strong> — you are an admin without ban access. Add <code>d</code> to your access-flags string.</li><li><strong>Worked before, broke on a non-Steam server</strong> — IDs there depend on Reunion/dproto; an unstable ID no longer matches your <code>users.ini</code> line. Pin the auth method to what those hand out.</li><li><strong>Edited users.ini, still refused</strong> — you did not run <code>amx_reloadadmins</code> or reconnect. The file is cached.</li><li><strong>Password mode never authenticates</strong> — you set the account flag to expect a password but never set <code>setinfo _pw</code> on your client. Switch to SteamID auth (<code>c</code>) instead.</li></ul><h2>Verification</h2><p>After editing <code>users.ini</code>, run <code>amx_reloadadmins</code>, reconnect, and check <code>amx_who</code> — your name should show the full flag string including <code>d</code>. Then run the command that was refused, such as <code>amx_ban</code> on a test target, and confirm it executes instead of printing the access error. If <code>amx_who</code> shows the flags but the command still refuses, the command needs a different flag than you think — re-check the flag it requires. A managed admin suite like the <a href="/plugins/csb-admin-menu">CSB Admin Menu</a> surfaces these flags in a menu so you are not editing the raw file by hand.</p> |
fix-server-is-full-when-empty/en.md
A
| @@ -0,0 +1,10 @@ | ||
| 1 | +--- | |
| 2 | +title: "Fix: 'Server is full' Message on an Empty Server" | |
| 3 | +excerpt: "Why players get 'Server is full' when the server clearly has open slots, how reserved-slot plugins hide the last slot, the maxplayers vs sv_visiblemaxplayers mismatch, and how to confirm the real slot count." | |
| 4 | +category: "errors" | |
| 5 | +tags: "slots, reserved" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>Players report <code>Server is full</code> or are dropped with a full-server message, yet the scoreboard shows open slots — sometimes the server looks completely empty. This is almost never a real capacity problem; it is a reserved-slots plugin holding slots back, a mismatch between the advertised and actual slot count, or a hung slot that is occupied by nobody. Here is how to find which, because the symptom is identical for all three.</p><h2>1. Check the real maxplayers</h2><p>Start from ground truth: how many slots does the server actually have? In the console:</p><pre>maxplayers</pre><p>This is set at startup (the <code>-maxplayers</code> / <code>+maxplayers</code> launch value) and <strong>cannot be raised without a restart</strong>. If it reads lower than you think — someone launched with <code>maxplayers 10</code> — then the server genuinely is small and fills fast. If it reads a healthy number but players still get rejected on an apparently empty server, the cause is a plugin or a hidden-slot cvar below.</p><h2>2. Look at reserved slots</h2><p>The most common cause is a reserved-slots plugin (AMX Mod X ships <code>adminslots.amxx</code>). It keeps one or more slots free for admins by <em>kicking a non-admin</em> or <em>refusing the connection</em> when the server reaches capacity minus the reserved count. Its cvars:</p><pre>amx_reservation 1 // number of slots reserved for admins | |
| 10 | +amx_hideslots 1 // hide the reserved slots from the public count</pre><p>With <code>amx_reservation 1</code>, the last public slot is closed to non-admins — so a 12-slot server effectively fills at 11 for regular players, and the 12th shows <code>Server is full</code> to them. That is working as designed; the confusion is only if you did not know it was enabled. Lower <code>amx_reservation</code> to <code>0</code> if you do not want reserved slots, or explain the reservation.</p><h2>3. Understand sv_visiblemaxplayers</h2><p>The <code>amx_hideslots</code> feature works by lowering the advertised slot count so the reserved slots are invisible in the browser. That is done through <code>sv_visiblemaxplayers</code>:</p><pre>sv_visiblemaxplayers 11</pre><p>If this is set below your real <code>maxplayers</code>, the server browser shows fewer slots than exist — a 12-slot server advertising 11. Combined with a reservation this is intentional; set by accident, it makes the server look full or smaller than it is. Set <code>sv_visiblemaxplayers</code> to <code>-1</code> to advertise the true count, or match it to your intended public capacity.</p><h2>4. Clear a hung / ghost slot</h2><p>Occasionally a slot is occupied by a connection that never fully joined or never cleaned up — a client that crashed mid-connect, a bot slot not released. The server counts it as occupied even though no player is visible. List who the engine thinks is connected:</p><pre>status</pre><p>Compare the player count in <code>status</code> against the scoreboard. If <code>status</code> shows connections with no name or a stuck <code>connecting</code> state consuming slots, that is your phantom capacity. A map change usually clears them; if a specific slot stays wedged, restart the server. Bots also occupy real slots — a bot-filler plugin set to keep the server "full" will do exactly that and reject humans once its quota fills.</p><h2>5. Rule out a bot filler</h2><p>Plugins that add bots to make a server look populated consume real player slots. If such a plugin fills to <code>maxplayers</code>, humans get <code>Server is full</code> even though the "players" are bots. Check its quota cvar and ensure it leaves headroom, or that it kicks a bot when a human connects. This is the one case where an "empty"-looking server (only bots, easy to overlook as empty) genuinely has no room.</p><h2>Troubleshooting</h2><ul><li><strong>Full at maxplayers-minus-one for non-admins</strong> — reserved slots. Lower <code>amx_reservation</code> or accept the reservation.</li><li><strong>Browser shows fewer slots than real</strong> — <code>sv_visiblemaxplayers</code> is below <code>maxplayers</code>. Set it to <code>-1</code> or the intended count.</li><li><strong>maxplayers itself is low</strong> — the server was launched small; change the launch value and restart.</li><li><strong><code>status</code> shows stuck 'connecting' slots</strong> — ghost connections. Change map or restart to release them.</li><li><strong>Full but only bots inside</strong> — a bot filler took every slot. Adjust its quota to leave room for humans.</li><li><strong>Full message only for some players</strong> — they are non-admins hitting the reserved slot while admins get in. Expected with reservations.</li></ul><h2>Verification</h2><p>Read the three numbers that matter together: <code>maxplayers</code> (real capacity), <code>sv_visiblemaxplayers</code> (advertised), and the <code>amx_reservation</code> value. They should describe the situation you intend — for a plain 12-slot public server with no reservation, <code>maxplayers 12</code>, <code>sv_visiblemaxplayers -1</code>, <code>amx_reservation 0</code>. Then have a non-admin connect to what looks like a full-but-really-open server and confirm they get in. If they connect and the counts match your intent, the phantom-full is resolved. If it recurs only at peak, it is the reserved slot doing its job — document it so it stops looking like a bug. For advertising the server correctly to the master list, confirm <code>sv_lan 0</code> as covered in <a href="/tutorials/essential-server-cvars">the essential cvars guide</a>.</p> |
fix-sys-error-fatal/en.md
A
| @@ -0,0 +1,11 @@ | ||
| 1 | +--- | |
| 2 | +title: "Fix: 'Sys_Error' Fatal Server Errors" | |
| 3 | +excerpt: "How to read a Sys_Error crash line, the common variants like 'Couldn't get DLL API' and hunk overflow, and a method to find which module, DLL or plugin took the server down." | |
| 4 | +category: "errors" | |
| 5 | +tags: "sys_error, crash" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p><code>Sys_Error</code> is GoldSrc's fatal-error path: when the engine hits a condition it cannot recover from, it prints <code>Sys_Error: <reason></code> and exits. The server does not limp on — it dies. The good news is that the reason string after <code>Sys_Error:</code> is specific and tells you almost exactly what failed. This explains how to read it and the most common variants CS 1.6 admins hit.</p><h2>1. Read the whole error line</h2><p>Never act on just "it crashed with Sys_Error". Capture the full line and the lines above it. On Linux run the server in the foreground or tail the log:</p><pre>./hlds_run -game cstrike +map de_dust2 | |
| 10 | +# or watch the server log / console output as it dies</pre><p>The text after <code>Sys_Error:</code> is the diagnosis. A few lines <em>above</em> it usually show what the engine was doing when it died — loading a module, precaching a map, running a plugin. Read both. Everything below hinges on that reason string.</p><h2>2. 'Couldn't get DLL API' — a bad module or mod DLL</h2><p>One of the most common variants:</p><pre>Sys_Error: Couldn't get DLL API from <path>.so!</pre><p>This means the engine tried to load a game/Metamod library and the library was the wrong architecture, corrupt, or built for a different engine. Typical causes: a 64-bit <code>.so</code> on a 32-bit engine (GoldSrc is 32-bit — everything must be 32-bit), a mismatched Metamod/ReGameDLL, or a truncated file from a failed upload. Reinstall the offending library and make sure engine, Metamod, and mod DLL are the matching flavour and architecture. If it names Metamod, the <code>liblist.gam</code> <code>gamedll</code> line or the Metamod path is pointing at the wrong file.</p><h2>3. Hunk / cache overflow — too much content</h2><p>Variants like a hunk allocation failure or <code>ED_Alloc: no free edicts</code> mean the map or plugins asked for more of a fixed resource than exists. A content-heavy map with many entities, or too many precached models/sounds, can exhaust the engine's memory hunk. Fixes: raise the heap size on the command line and trim content:</p><pre>./hlds_run -game cstrike -heapsize 128000 +map de_dust2</pre><p><code>-heapsize</code> (in kilobytes) enlarges the engine's memory pool; a common value is <code>128000</code> (128 MB). If the crash is <em>edicts</em>, the map spawns too many entities — that is a map problem, not a heap one. The same over-budget pattern behind the <a href="/tutorials/fix-sound-slots-overflow">sound-slot overflow</a> can surface here as a fatal.</p><h2>4. Crash during a plugin or on a specific map</h2><p>If <code>Sys_Error</code> fires only on a certain map, that map is corrupt or references something missing — re-download the <code>.bsp</code> and its resources. If it fires shortly after a plugin loads or on a plugin action, bisect: disable plugins in <a href="/tutorials/plugins-ini-load-order">plugins.ini</a> and find which one precedes the crash. A plugin needing a module you do not have throws its own error (see <a href="/tutorials/fix-amxx-module-failed-to-load">module failed to load</a>), but a plugin doing something the engine rejects can escalate to a <code>Sys_Error</code>.</p><h2>5. Isolate a clean baseline</h2><p>When the reason string is unfamiliar, strip the server to bare metal and add pieces back. Start with no Metamod, no plugins, a stock map:</p><pre>./hlds_run -game cstrike +map de_dust2 +maxplayers 12 | |
| 11 | +# no metamod line in liblist.gam, empty plugins.ini</pre><p>If the stock server runs, add Metamod, then AMX Mod X, then plugins in groups, changing map between each. The step that reintroduces the <code>Sys_Error</code> is the culprit. This is slower than guessing but it always finds it, and it distinguishes an engine/DLL fault from a content or plugin fault.</p><h2>Troubleshooting</h2><ul><li><strong><code>Couldn't get DLL API</code></strong> — wrong-architecture or corrupt library, or a Metamod/ReGameDLL mismatch. Reinstall matching 32-bit binaries and check <code>liblist.gam</code>.</li><li><strong>Hunk allocation / memory fatal</strong> — raise <code>-heapsize</code> and trim heavy content.</li><li><strong><code>no free edicts</code></strong> — the map spawns too many entities. It is a map issue, not heap.</li><li><strong>Only on one map</strong> — corrupt or incomplete <code>.bsp</code>/resources. Re-download that map.</li><li><strong>Right after a plugin loads</strong> — bisect <code>plugins.ini</code>; the plugin may need a missing module or do something illegal.</li><li><strong>Random and rare</strong> — strip to a stock baseline and add components back to isolate it.</li></ul><h2>Verification</h2><p>After a fix, start the server in the foreground and watch it reach a running console without a <code>Sys_Error</code> line, then load through several maps — especially the one that crashed — and let it run under real player load for a while. Because <code>Sys_Error</code> is fatal and usually deterministic for its cause, a server that survives the previously-crashing map and a full plugin load has resolved it. Keep the server's console output logged so that if it ever recurs you capture the exact reason string instead of a vague "it went down".</p> |
list-server-on-tsarvar/en.md
A
| @@ -0,0 +1,10 @@ | ||
| 1 | +--- | |
| 2 | +title: "Listing Your Server on Tsarvar" | |
| 3 | +excerpt: "How to add a CS 1.6 server to Tsarvar, why it matters for the CIS audience, the IP-and-port requirements, and how the site's favourites and rating drive players to you." | |
| 4 | +category: "hosting" | |
| 5 | +tags: "tsarvar, listing" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>Tsarvar is one of the most-used CS 1.6 server monitors in the CIS region, and since the CIS region is where much of the game's remaining population lives, being listed there can matter more than any Western site for a large slice of servers. Like every monitor, it works by querying your server and publishing live status; getting on it is a form, not a plugin. Here is how to list correctly and get value from the page.</p><h2>1. Confirm your server is publicly queryable</h2><p>Tsarvar discovers and updates servers by sending A2S queries to your <code>IP:port</code>. If your server is not reachable from the public internet — not in the master list, port closed, LAN-only — the listing will show offline the moment it is created. Verify first:</p><pre>sv_lan 0 | |
| 10 | +sv_region 3 // 3 = Europe; set the region your players are in</pre><p>Make sure the server appears in the in-game browser and answers queries. If it does not, resolve that with <a href="/tutorials/get-server-in-master-list">getting into the master list</a> and <a href="/tutorials/fix-server-not-in-master-list">the missing-from-master-list fix</a> before adding it anywhere.</p><h2>2. Add the server by IP and port</h2><p>On Tsarvar, use the add-server form and submit your server as <code>IP:port</code> for Counter-Strike 1.6. The site starts querying it and builds a page with the live map, current and historical player count, and a status indicator. As with every monitor, a non-default port must be entered exactly — the site cannot guess it, and listing the wrong port produces a permanently "offline" entry pointing at nothing.</p><h2>3. Understand favourites and rating</h2><p>Tsarvar lets logged-in users add servers to favourites and contributes to a rating/position based on activity and user interest. The mechanics that move you up are the familiar ones: real, sustained population and genuine user interest. Encourage your regulars to favourite the server on Tsarvar the same way you would ask them to vote on GameTracker — it is a legitimate signal, unlike inflating the player count. Point them at it from your <a href="/tutorials/motd-txt-html-guide">MOTD</a> and Discord.</p><h2>4. Match your listing to your identity</h2><p>The page pulls your live <code>hostname</code> and map, so keep those clean and descriptive — the hostname is your advert on the list. Publish a stable connect address; a <a href="/tutorials/domain-name-for-server">domain</a> means the listing keeps working when your IP changes, whereas a raw IP entry dies on a move and you have to re-add and rebuild history. Consistency between your Tsarvar entry, GameTracker page, and in-game name makes the server recognisable across every place a player might find it.</p><h2>5. Do not pay for placement or hand over access</h2><p>Treat Tsarvar the way you treat every monitor: it needs nothing from you but your public <code>IP:port</code> to query. Be sceptical of anyone offering paid rank boosts, guaranteed placement, or tools that require your RCON password or a plugin install to "promote" the server on it. A monitor rank earned by real activity and favourites survives; one bought or faked is fragile and can get the entry flagged. The only legitimate levers are the same everywhere — genuine players and genuine user interest — so spend the effort on population, not on shortcuts that put your server at risk.</p><h2>6. Keep it accurate</h2><p>A monitor listing is only useful while it is accurate. If the server moves IP or port, update the entry, or Tsarvar shows it offline and eventually stops surfacing it. Because monitors query by IP, the underlying address on the listing must be current even if you advertise a domain to humans. Check the page periodically to confirm it reflects the live server.</p><h2>Common errors</h2><ul><li><strong>Listing shows offline immediately</strong> — the server is not publicly queryable or the port is wrong. Confirm it is in the browser and the exact <code>IP:port</code> was entered.</li><li><strong>Wrong region shown</strong> — <code>sv_region</code> is set to a region that does not match where you host. Set it to your actual region.</li><li><strong>Player count looks fake and gets ignored</strong> — padding produces a flat count monitors distrust; run real players or real bots (<a href="/tutorials/fake-players-bot-padding">fake players and bot padding</a>).</li><li><strong>Entry died after an IP change</strong> — the listing still points at the old address. Update it; advertise a domain to humans so their connect string is unaffected.</li><li><strong>Duplicate entries</strong> — the server was re-added instead of updated. Maintain one entry so its history accumulates.</li></ul><h2>Verification</h2><p>After adding the server, wait for Tsarvar's next query cycle and confirm the page shows the correct hostname, map, and live player count. Change the map in-game and confirm the listing follows. From a CIS-region perspective — ask a regional regular to check — confirm the server is discoverable in searches there, since that reachability is the whole reason to be on Tsarvar. Once it tracks reality and your regulars have favourited it, the listing is doing its job. For the full picture across sites, see <a href="/tutorials/cs16-toplists-worth-joining">toplists worth joining</a> and <a href="/tutorials/gametracker-claim-server">claiming your GameTracker page</a>.</p> | |
| 0 | 11 |
