Add 7 tutorials (7 files)
Browse Source
Daemon666 committed
parent 4b6616175a
commit e484633b8f942ba741691f88453c6594bce896d2
7 changed files
with 81 additions and 0 deletions
A
backup-restore-cs16-server/en.md
+14 -0
A
cost-of-running-cs16-server/en.md
+9 -0
A
fix-mapcycle-ignored/en.md
+16 -0
A
fix-plugin-loads-but-does-nothing/en.md
+9 -0
A
fix-server-laggy-after-days/en.md
+12 -0
A
fix-sys-ticrate-not-changing-fps/en.md
+12 -0
A
managed-hosting-vs-self-hosted/en.md
+9 -0
backup-restore-cs16-server/en.md
A
| @@ -0,0 +1,14 @@ | ||
| 1 | +--- | |
| 2 | +title: "How to Back Up and Restore a Full CS 1.6 Server" | |
| 3 | +excerpt: "Exactly which files hold your CS 1.6 server's identity — configs, admins, bans, stats, plugins, maps — how to archive them, restore onto a new box, and verify nothing was lost." | |
| 4 | +category: "installation" | |
| 5 | +tags: "backup, migration" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>Everything that makes your server <em>yours</em> — your configs, admin list, bans, ranks, plugins and custom maps — is a handful of files. The multi-gigabyte HLDS install is replaceable; those files are not. A proper backup lets you rebuild on a new <a href="/tutorials/choose-vps-for-cs16">VPS</a> in minutes after a crash, a host failure, or a bad edit. This is exactly what to back up, how, and how to restore it without losing anything that matters.</p><h2>1. Know what is irreplaceable versus reinstallable</h2><p>Split your server into two buckets. <strong>Reinstallable</strong>: the base HLDS/ReHLDS engine and stock game files — you can re-download these any time with <a href="/tutorials/install-cs16-dedicated-server-linux-steamcmd">SteamCMD</a>. <strong>Irreplaceable</strong>: your configuration and accumulated state. Only the second bucket needs backing up, which keeps the archive small — typically a few megabytes rather than the multi-gigabyte engine tree. The irreplaceable files all live in a few known places under <code>cstrike/</code>, so a targeted backup is both smaller and faster to restore than imaging the whole install.</p><h2>2. The files that hold your server's identity</h2><ul><li><code>cstrike/server.cfg</code> and any config it execs — your cvars, hostname, rcon; see <a href="/tutorials/setup-server-cfg-cs16">server.cfg</a>.</li><li><code>cstrike/mapcycle.txt</code> and <code>cstrike/maps/</code> — your rotation and any custom <code>.bsp</code>/<code>.res</code> files.</li><li><code>cstrike/addons/amxmodx/configs/</code> — <code>users.ini</code> (admins), <code>plugins.ini</code>, <code>modules.ini</code>, <code>amxx.cfg</code>.</li><li><code>cstrike/addons/amxmodx/plugins/</code> — your compiled <code>.amxx</code> plugins.</li><li><code>cstrike/addons/amxmodx/data/</code> — ranks (<code>csstats.dat</code>) and any plugin vault/nvault data.</li><li>The engine ban files — <code>banned_user.cfg</code> and <code>listip.cfg</code> (names vary by build).</li></ul><p>These are the same paths covered in <a href="/tutorials/backup-configs-bans-stats">backing up configs, bans and stats</a>; here we archive the whole set for a full rebuild.</p><h2>3. Archive it in one command</h2><p>Stop or pause writes for a clean snapshot if you can (a running server rewrites <code>csstats.dat</code> and ban files), then tar the important trees with the date in the filename:</p><pre>cd /home/cs/hlds/cstrike | |
| 10 | +tar czf ~/csbackup_$(date +%F).tar.gz \ | |
| 11 | + server.cfg mapcycle.txt maps \ | |
| 12 | + addons/amxmodx/configs addons/amxmodx/plugins addons/amxmodx/data \ | |
| 13 | + banned_user.cfg listip.cfg</pre><p>Copy the resulting archive <strong>off the server</strong> — a backup that lives only on the box you are protecting against is not a backup. Pull it to your own machine or a separate host. Automate it with the same <a href="/tutorials/cron-restart-cs16-server">cron mechanism</a> used for restarts so a fresh archive is made daily.</p><h2>4. If you use MySQL, dump the database too</h2><p>SQL-backed ranks, bans or VIP live in a MySQL database, not in files, so the tar above misses them entirely. Dump the database separately:</p><pre>mysqldump -u csuser -p amxbans_db > ~/csdb_$(date +%F).sql</pre><p>Store the <code>.sql</code> alongside the tarball. Restoring the files but forgetting the database is the classic "my bans and ranks are gone" mistake after a migration.</p><h2>5. Restore onto a fresh box</h2><p>On the new server: install the base engine and AMX Mod X first (<a href="/tutorials/install-cs16-dedicated-server-linux-steamcmd">SteamCMD</a> + <a href="/tutorials/install-amx-mod-x-1-9">AMX Mod X</a>) so the directory structure exists, then unpack your archive over it:</p><pre>cd /home/cs/hlds/cstrike | |
| 14 | +tar xzf ~/csbackup_2026-07-15.tar.gz</pre><p>Import the database dump if you have one (<code>mysql ... < csdb_....sql</code>), then fix the two things that change on a new box: the server's IP/port in any config that hard-codes it, and file ownership so the game user can write to <code>data/</code> and the ban files. A restored server that cannot write <code>data/</code> loses every new rank and ban on the next map.</p><h2>Common errors</h2><ul><li><strong>Ranks/bans reset after restore</strong> — wrong ownership on <code>addons/amxmodx/data/</code> or the ban files, so the server cannot write them. Fix the directory ownership.</li><li><strong>SQL bans and ranks gone</strong> — you tarred the files but never dumped the MySQL database. Restore the <code>.sql</code> too.</li><li><strong>Plugins fail to load after restore</strong> — the new box is missing a module or the 32-bit libraries. See <a href="/tutorials/amxx-not-loading-install-checklist">the AMX Mod X not-loading checklist</a>.</li><li><strong>Server not visible after migration</strong> — a config hard-codes the old IP, or the firewall is closed. Update the IP and open <a href="/tutorials/cs16-server-firewall-ports">the ports</a>.</li><li><strong>Corrupt <code>csstats.dat</code></strong> — you archived it mid-write. Pause the server or stop it before the snapshot for a clean copy.</li></ul><h2>Verification</h2><p>Do a real restore test, not a hopeful one: unpack your backup into a fresh install on a spare box or locally, start it, and confirm the hostname, admin access (<code>amx_who</code> shows you with your flags), a known ban still present in <code>listid</code>, and your rank intact via <code>say /rank</code>. If all four survived, the backup is complete and your restore procedure works. Then check the archive actually exists off-site — open it from your own machine. A backup you have restored once is a backup you can trust when the box actually dies.</p> |
cost-of-running-cs16-server/en.md
A
| @@ -0,0 +1,9 @@ | ||
| 1 | +--- | |
| 2 | +title: "What Does It Really Cost to Run a CS 1.6 Server?" | |
| 3 | +excerpt: "A realistic breakdown of the cost of running a CS 1.6 server -- VPS, FastDL, DDoS protection, domain, and your time -- and where the money actually goes as you scale." | |
| 4 | +category: "hosting" | |
| 5 | +tags: "costs, hosting" | |
| 6 | +image: "" | |
| 7 | +read_time: "9 min read" | |
| 8 | +--- | |
| 9 | +<p>"How much does a CS 1.6 server cost?" has a misleading cheap answer — the game is free and the server files are free, so people assume the running cost is near zero. The real cost is small but not nothing, and it shifts as you grow from a hobby box to a community that people rely on. This breaks down every line item honestly, including the one most guides ignore: your own time. No specific prices — those move — but the shape of the spending, so you can budget your own numbers into it.</p><h2>1. The compute: your biggest line</h2><p>The server itself has to run somewhere, and that is your main recurring cost. The range is wide:</p><ul><li><strong>Cheap game-hosting slot</strong> — a few dollars a month for a stock server, but with the limits covered in <a href="/tutorials/cheap-hosting-vs-real-vps">cheap hosting vs a real VPS</a>.</li><li><strong>A small VPS</strong> — more per month, but full control and room for several servers. Because one CS 1.6 server is effectively single-threaded, you do not need a large box; you need a <em>fast core</em>, which is covered in <a href="/tutorials/choose-vps-for-cs16">choosing a VPS</a>.</li></ul><p>The key economic fact: one VPS can host <a href="/tutorials/multiple-cs16-servers-one-vps">several CS 1.6 servers</a>, so the per-server cost falls the more you run on one box. A single server on a VPS is the most expensive way to buy a slot; five servers on the same VPS is the cheapest.</p><h2>2. FastDL and bandwidth</h2><p>If you run custom content — maps, models, sprites — you need <a href="/tutorials/fastdl-setup-guide">FastDL</a> to serve it, or every map change crawls over the slow in-game transfer. FastDL is a web server hosting your files; it can be a cheap static host, a corner of the same VPS, or a <a href="/tutorials/fastdl-cloudflare-cdn">CDN in front of it</a>. The cost is small — static files are cheap to serve — but it is a real line if your content is heavy and your traffic is high. Compressing files with <a href="/tutorials/fastdl-bzip2-compression">bzip2</a> cuts both the bandwidth bill and the player's wait, so it pays for itself in experience.</p><h2>3. DDoS protection</h2><p>A popular server gets attacked, so DDoS filtering moves from optional to necessary as you grow. Sometimes it is bundled with the VPS or host; sometimes it is a paid add-on or a more expensive protected plan (<a href="/tutorials/ddos-protected-hosting">DDoS-protected hosting</a>). Budget nothing for it while you are small and unknown; budget for it the moment you are popular enough that someone wants you offline. It is insurance — you pay for it before you need it or you pay in downtime when you do.</p><h2>4. The small stuff: domain, tools, extras</h2><p>A handful of minor costs round it out. A <strong>domain name</strong> for your website or a memorable FastDL/redirect address is a few dollars a year — optional but cheap. A <strong>website or Discord</strong> for your community is usually free (Discord) or the cost of basic hosting. Helper services — a stats web panel, an <a href="/tutorials/discord-rcon-bot">RCON Discord bot</a> — run on the VPS you already pay for, so they add no direct cost, only a little CPU. Individually trivial; worth listing so they do not surprise you.</p><h2>5. The cost everyone forgets: your time</h2><p>The largest real cost of a growing server is not money, it is hours. Installing the stack, tuning cvars, moderating players, fighting cheaters, handling migrations, and being present at peak so the server feels run — that is unpaid labour, and it dwarfs the VPS bill for any server that actually succeeds. This is worth saying plainly because it reframes the money: the compute is cheap precisely so that your time is the constraint. A server that dies does so from admin burnout far more often than from cost. Budget your time as deliberately as your dollars — automate what you can (<a href="/tutorials/cron-restart-cs16-server">scheduled restarts</a>, <a href="/tutorials/monitor-server-uptime-alerts">uptime alerts</a>, automated VIP), and share admin duties before you run out of enthusiasm.</p><h2>Where the money goes as you scale</h2><table><thead><tr><th>Stage</th><th>Dominant cost</th></tr></thead><tbody><tr><td>One hobby server</td><td>A cheap slot or small VPS. Money is trivial; your time is the real cost.</td></tr><tr><td>A small community</td><td>VPS with FastDL. Cost per server falls as you add servers to the same box.</td></tr><tr><td>A popular network</td><td>Larger/protected VPS, DDoS filtering, domain. Money grows but so does the need to protect uptime.</td></tr></tbody></table><h2>Common miscalculations</h2><ul><li><strong>Assuming it is free</strong> — the game is free; the compute, bandwidth, and your time are not.</li><li><strong>Buying a big VPS for one server</strong> — CS 1.6 is single-threaded; a fast core beats many cores. Right-size it.</li><li><strong>Ignoring FastDL bandwidth</strong> — heavy custom content on a busy server is a real line item. Compress it.</li><li><strong>Paying for DDoS protection too early — or too late</strong> — unknown servers are not targets; popular ones always are. Add it when you are worth attacking.</li><li><strong>Not counting your hours</strong> — the biggest cost and the usual reason servers die. Automate and delegate before you burn out.</li></ul><h2>Working it out for yourself</h2><p>Add three numbers: your monthly compute (VPS or slot), any FastDL/CDN and DDoS add-ons, and the yearly domain divided by twelve. That is your cash cost, and for a small server it is genuinely low. Then honestly estimate the hours per week you will spend running it — that is the cost that decides whether the server survives. If the cash fits your budget and the time fits your life, the server is sustainable; if either does not, scale down the ambition before you commit, because a server you cannot afford to <em>run</em> — in money or in hours — empties out the same way.</p> |
fix-mapcycle-ignored/en.md
A
| @@ -0,0 +1,16 @@ | ||
| 1 | +--- | |
| 2 | +title: "Fix: mapcycle.txt Ignored / The Same Map Repeats" | |
| 3 | +excerpt: "Why the server loops one map or ignores mapcycle.txt, the mapcyclefile cvar, why maps must end for the cycle to advance, nextmap plugins overriding it, file format traps, and verifying rotation." | |
| 4 | +category: "errors" | |
| 5 | +tags: "mapcycle, config" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>Your server plays <code>de_dust2</code> forever, or ignores the rotation you wrote in <code>mapcycle.txt</code> entirely. The map cycle in CS 1.6 has a subtle dependency that trips everyone: <strong>the cycle only advances when a map ends</strong>, and "ending" is governed by completely separate cvars. So an "ignored" mapcycle is usually either a map that never ends, a file the engine is not reading, or a plugin overriding the next map. Here is how to sort which.</p><h2>1. Confirm the engine is reading the right file</h2><p>The file the engine uses is set by <code>mapcyclefile</code>, defaulting to <code>mapcycle.txt</code> in <code>cstrike/</code>. If you edited a file the server does not use, nothing changes. Check the cvar from the console:</p><pre>mapcyclefile</pre><p>It should print <code>mapcycle.txt</code> (or whatever you intend). Confirm that file actually exists in <code>cstrike/</code> and is the one you edited — not a copy in the wrong directory. Set it explicitly in <a href="/tutorials/setup-server-cfg-cs16">server.cfg</a> if in doubt:</p><pre>mapcyclefile "mapcycle.txt" | |
| 10 | +</pre><h2>2. Make sure maps actually end</h2><p>This is the real cause most of the time. The cycle advances at map end, and a map ends only when one of the end-of-map limits fires. If all of <code>mp_timelimit</code>, <code>mp_maxrounds</code>, <code>mp_winlimit</code> and <code>mp_fraglimit</code> are <code>0</code>, nothing ever ends the map and it loops forever — which looks exactly like a broken mapcycle but is not. Set at least one:</p><pre>mp_timelimit 25 | |
| 11 | +</pre><p>Remember <code>mp_maxrounds</code> and <code>mp_winlimit</code> require <a href="/tutorials/install-regamedll-cs16">ReGameDLL</a>; on stock CS only <code>mp_timelimit</code> and <code>mp_fraglimit</code> work. The full interaction is in <a href="/tutorials/timelimit-maxrounds-flow">the map-flow tuning guide</a>. If your map never changes, check these four cvars <em>before</em> touching the cycle file.</p><h2>3. Check the file format</h2><p><code>mapcycle.txt</code> is one map name per line, no <code>.bsp</code> extension, and every map must exist in <code>cstrike/maps/</code>:</p><pre>de_dust2 | |
| 12 | +de_inferno | |
| 13 | +de_nuke | |
| 14 | +cs_office | |
| 15 | +</pre><p>Traps that break it: a Windows CRLF file with stray characters, a trailing blank/space, a map name misspelled, or a hidden <code>.txt.txt</code> extension. A map listed but missing from <code>maps/</code> is skipped, and if <em>every</em> entry is bad the engine falls back to repeating the current map. Keep names lowercase and exact.</p><h2>4. Rule out a nextmap/RTV plugin override</h2><p>If you run AMX Mod X, the <code>nextmap</code>, <code>mapchooser</code>, or a Rock The Vote plugin frequently <strong>overrides</strong> <code>mapcycle.txt</code> — they pick the next map themselves, sometimes from their own <code>maps.ini</code> or a vote, ignoring the engine cycle. Check what is loaded:</p><pre>amxx plugins</pre><p>If a map-management plugin is running, <em>it</em> decides the next map, and the amx cvar <code>amx_nextmap</code> reflects that choice. This is not a bug — it is the plugin doing its job — but it means editing <code>mapcycle.txt</code> has no visible effect. Configure the rotation in the plugin's file (or its vote list) instead. See <a href="/tutorials/rtv-nextmap-setup">the RTV and nextmap guide</a>.</p><h2>5. Check the current nextmap value</h2><p>You can see what the server thinks is next:</p><pre>amx_nextmap</pre><p>If this shows a map you did not expect, a plugin set it. If you run stock (no AMXX), the engine advances through <code>mapcycle.txt</code> in order and wraps at the end — and the position is remembered, so a restart mid-cycle continues from where it was, which can look like it "skipped" your first map.</p><h2>6. Watch for servercfgfile re-runs</h2><p>If your rotation seems to reset to the same map after each round or map, check whether a config is re-executing and forcing a map. Some setups put a <code>map</code> or <code>changelevel</code> command, or a hard-coded <code>+map</code>, into a config that runs on every load, which overrides the natural cycle. Grep your <code>server.cfg</code>, <code>amxx.cfg</code> and any ReGameDLL <code>game.cfg</code> for stray map-setting lines. The engine cycle, a nextmap plugin, and a config that forces a map can all be fighting each other; only one should be deciding the next map. Decide which authority you want — engine cycle for a plain server, a nextmap/RTV plugin for an AMXX server — and remove the others.</p><h2>Common errors</h2><ul><li><strong>Same map forever</strong> — all four end-of-map limits are <code>0</code>. Set <code>mp_timelimit</code> or another.</li><li><strong>Edited the file, no change</strong> — a nextmap/RTV plugin overrides it, or <code>mapcyclefile</code> points elsewhere.</li><li><strong>A listed map is skipped</strong> — it is missing from <code>cstrike/maps/</code> or misspelled.</li><li><strong>Cycle resets or jumps</strong> — the engine remembers its position; a restart continues mid-cycle.</li><li><strong>File looks right but is ignored</strong> — hidden <code>.txt.txt</code> extension or CRLF/encoding junk. Re-save as clean plain text.</li></ul><h2>Verification</h2><p>Set a short limit on a test server so maps end quickly:</p><pre>mp_timelimit 2 | |
| 16 | +mapcyclefile</pre><p>Confirm <code>mapcyclefile</code> names your file, then let the timelimit expire and watch the server advance to the <em>next</em> entry in <code>mapcycle.txt</code>, not repeat the current one. Run through two or three entries to confirm order and wrap-around. If a plugin is managing rotation, verify <code>amx_nextmap</code> matches your intended sequence instead. Once it advances correctly, restore your real <code>mp_timelimit</code>.</p> |
fix-plugin-loads-but-does-nothing/en.md
A
| @@ -0,0 +1,9 @@ | ||
| 1 | +--- | |
| 2 | +title: "Fix: Plugin Loads but Nothing Happens (No Events Firing)" | |
| 3 | +excerpt: "A plugin shows running in amxx plugins but does nothing. How a missing module, a guard cvar, the wrong mod, or a bad register_event silently kills behavior, and how to trace it." | |
| 4 | +category: "errors" | |
| 5 | +tags: "plugins, events" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p><code>amxx plugins</code> shows your plugin as <code>running</code>, yet it does nothing — no messages, no effects, no reaction to kills or spawns. A plugin can load cleanly and still never do its job, because loading only proves the code compiled and initialized; whether its <em>events actually fire</em> depends on modules, cvars, the mod you run, and correct event registration. This walks the reasons a "running" plugin sits inert and how to find which one applies.</p><h2>1. Confirm it really is running, not paused or bad</h2><pre>amxx plugins</pre><p>Check the status column precisely. <code>running</code> is good; <code>paused</code> means someone or something paused it (it will not fire until unpaused); <code>bad load</code> means it failed and is not running at all. If it is <code>paused</code>, <code>amxx unpause</code> it. This tutorial assumes it genuinely reads <code>running</code> — if it says <code>bad load</code>, that is a different problem covered in <a href="/tutorials/fix-amxx-module-failed-to-load">module failed to load</a>.</p><h2>2. Check for a disabling cvar</h2><p>Many plugins have an on/off cvar that defaults to enabled but is easy to leave at zero in a config:</p><pre>plugin_enabled 0</pre><p>A plugin with its master switch off loads, registers everything, and then does nothing because its handlers bail out immediately. Read the plugin's cvars back in the console and confirm its enable cvar and any mode cvar are set to active values. This is the fastest thing to rule out and a very common cause of "it's running but dead."</p><h2>3. Verify you are on the mod the plugin targets</h2><p>A plugin written for a specific mod — a zombie plugin, a CSDM plugin, a plugin using ReAPI hooks — will load on a plain server but its events never fire because the game it hooks into is not there. If a plugin needs <a href="/tutorials/install-regamedll-cs16">ReGameDLL</a> or a particular game mode and you run stock CS, it initializes and then waits for events that never happen. Match the plugin to your actual engine and mod. A plugin that <code>#include</code>s <code>reapi</code> genuinely needs ReGameDLL to do anything, even though it loads without it.</p><h2>4. Suspect a missing optional module or wrong event</h2><p>If a plugin hard-requires a module it is missing, it usually fails at load — but some plugins register events conditionally, so a subtly wrong registration leaves the plugin running with a handler that never triggers. Two things to look at:</p><ul><li>A <code>register_event</code> with a mistyped event name or wrong flags never fires — the engine never matches it, and there is no error.</li><li>A plugin expecting a game event that your ruleset never produces (an objective event on a map with no objective) waits forever.</li></ul><p>You cannot always see this from outside, but the server console at map load often prints registration warnings. Turn on debug for that plugin and watch what it reports.</p><h2>5. Turn on debug and read the log</h2><p>Load the plugin with the debug flag so runtime problems surface instead of failing silently. In <a href="/tutorials/plugins-ini-load-order">plugins.ini</a>, append <code>debug</code> to the line:</p><pre>myplugin.amxx debug</pre><p>Change the map, trigger the action that should do something, and check <code>addons/amxmodx/logs/</code>. A handler that throws a runtime error on every invocation — a bad array index, a native called with wrong args — will run, error, and abort silently without debug, but with debug it logs the error and the line. That log line usually names the exact reason the plugin "does nothing."</p><h2>Troubleshooting</h2><ul><li><strong>Running but inert, cvar is zero</strong> — the plugin's enable cvar is off. Set it and re-check.</li><li><strong>Works on one server, dead on another</strong> — the dead one lacks the mod/engine the plugin targets (ReGameDLL, a game mode). Match the environment.</li><li><strong>Fires sometimes, not others</strong> — it hooks an event that only some maps or rounds produce. Confirm the event actually occurs.</li><li><strong>Silent runtime errors</strong> — add <code>debug</code> to the plugins.ini line and read the log; an aborting handler looks like "nothing happens."</li><li><strong>No effect at all, no log lines</strong> — the event registration is wrong (mistyped event, wrong flags), so the handler is never called. Re-check the registration or the plugin's requirements.</li></ul><h2>Verification</h2><p>Set the plugin's enable cvar on, add <code>debug</code> to its line, change the map, and perform the exact action the plugin reacts to — a kill, a spawn, a chat trigger. Watch both the game (for the effect) and <code>addons/amxmodx/logs/</code> (for any error). Success is the visible behavior appearing with a clean log. If the behavior appears, remove <code>debug</code> for production. If the log now shows a runtime error you could not see before, you have found why it did nothing — fix that error, or replace the plugin with a maintained equivalent from the <a href="/plugins/">plugin directory</a>.</p> |
fix-server-laggy-after-days/en.md
A
| @@ -0,0 +1,12 @@ | ||
| 1 | +--- | |
| 2 | +title: "Fix: Server Becomes Laggy After Running for Days" | |
| 3 | +excerpt: "Why a CS 1.6 server that runs fine on boot degrades after days of uptime, how memory growth and log bloat cause it, spotting a leaking plugin, and setting up a scheduled restart to stay ahead of it." | |
| 4 | +category: "errors" | |
| 5 | +tags: "memory, uptime" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>The server is smooth right after a restart, then over days it slowly gets worse — higher server-side lag, choppier movement, occasional hitches — until a restart makes it perfect again. This is a resource-exhaustion pattern: something accumulates over uptime (memory, log files, a growing in-memory structure) until it starts costing performance. The tell is that <em>restarting fixes it</em> and the degradation is gradual, not tied to player count. Here is how to find and manage the accumulation.</p><h2>1. Confirm it is uptime, not load</h2><p>First separate this from a load problem. A server that lags in proportion to <em>players</em> is CPU- or plugin-bound under load — that is <a href="/tutorials/fix-server-fps-drops-with-players">the FPS-under-load case</a>. A server that lags in proportion to <em>uptime</em>, at the same player count that was fine on day one, is accumulating something. Note the server FPS from <code>stats</code> right after a restart, then again after several days at a similar population; a clear decline over time with steady load confirms the pattern.</p><h2>2. Watch memory growth</h2><p>The usual accumulator is memory. Track the HLDS process's resident memory over time from the host:</p><pre>ps -o pid,rss,etime,cmd -p $(pgrep -f hlds_linux)</pre><p>Run this daily and watch the <code>rss</code> column (resident memory in KB). Healthy servers settle at a roughly stable footprint; a steady, unbounded climb over days is a leak — almost always a plugin allocating and never freeing, or caching per-player data without ever pruning it. When memory grows into swap on a small VPS, the whole box starts paging and every frame gets slower, which is exactly the gradual lag you feel.</p><h2>3. Find the leaking plugin</h2><p>If memory climbs, a plugin is usually responsible. Correlate the growth with what is loaded by testing with a reduced plugin set on a staging server, or by pausing suspects and watching whether the growth rate changes:</p><pre>amxx pause suspect.amxx</pre><p>Plugins that build ever-growing arrays or nVault caches, log verbosely to memory, or spawn tasks that never clear are the usual offenders. A plugin doing <a href="/tutorials/fix-server-freeze-mysql-query">unbounded SQL result handling</a> or keeping every connected player's history forever will leak. Update the plugin to a maintained version, or replace it — a leak in a plugin is a bug in that plugin, and the durable fix is fixing the plugin, not restarting around it forever.</p><h2>4. Rotate logs and clear disk bloat</h2><p>Two on-disk accumulators bite long-running servers. AMX Mod X and the engine write logs continuously; over weeks these grow to hundreds of megabytes and, on a small or nearly-full disk, slow every write the server makes. Check and manage them:</p><pre>du -sh addons/amxmodx/logs/ | |
| 10 | +du -sh cstrike/logs/ | |
| 11 | +df -h</pre><p>If the log directories are huge or the disk is near full, archive and truncate old logs and set up rotation so they do not grow unbounded. A disk at 100% causes writes to fail and the server to stall unpredictably — check <code>df -h</code> whenever a long-uptime server misbehaves. Also confirm demo recordings or a runaway crash-log are not filling the disk.</p><h2>5. Schedule a restart as a safety net</h2><p>Even with leaks fixed, a scheduled restart during off-peak hours is standard practice for long-lived GoldSrc servers — it resets memory, clears any slow accumulation, and reloads plugins cleanly. Set a cron job on the host to restart the server at a quiet time:</p><pre># restart daily at 06:00 (adjust to your process manager) | |
| 12 | +0 6 * * * /path/to/restart-cs-server.sh</pre><p>Use your actual start script or process manager (systemd, a screen/tmux wrapper) in the job. A nightly restart is a pragmatic backstop, not a substitute for fixing an identified leak — but combined with a fixed plugin set it keeps the server permanently in its fresh-boot performance band.</p><h2>Troubleshooting</h2><ul><li><strong>RSS climbs steadily over days</strong> — a plugin leaks memory. Isolate it by pausing suspects and fix or replace it.</li><li><strong>Lag scales with uptime, not players</strong> — accumulation, not load. Track memory and logs.</li><li><strong>Box starts swapping</strong> — memory grew past RAM on a small VPS. Fix the leak or add RAM; a restart clears it temporarily.</li><li><strong>Disk near full in <code>df -h</code></strong> — log or demo bloat. Rotate logs and clear old files.</li><li><strong>Restart always fixes it</strong> — classic resource exhaustion; schedule a restart while you hunt the leak.</li><li><strong>Only one plugin present makes it grow</strong> — that plugin is the leak. Update or remove it.</li></ul><h2>Verification</h2><p>After fixing the suspected plugin and setting up log rotation, leave the server running under normal load and sample <code>ps -o rss</code> and <code>stats</code> daily for a week. A healthy server holds a roughly flat memory footprint and steady FPS across the whole period at consistent population. If memory stays flat and the day-seven FPS matches day-one, the accumulation is resolved and the scheduled restart is now just insurance. If it still climbs, a plugin you have not isolated yet is leaking — keep pausing candidates until the growth stops. Pair the restart job with the plugin-update discipline in <a href="/tutorials/update-plugins-live-server">updating plugins on a live server</a>.</p> |
fix-sys-ticrate-not-changing-fps/en.md
A
| @@ -0,0 +1,12 @@ | ||
| 1 | +--- | |
| 2 | +title: "Fix: sys_ticrate Doesn't Change Server FPS" | |
| 3 | +excerpt: "Why raising sys_ticrate does not raise the server FPS shown by stats, the HLDS loop limitation behind it, and why ReHLDS is the real fix for a stable high tickrate." | |
| 4 | +category: "errors" | |
| 5 | +tags: "sys_ticrate, fps" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>You set <code>sys_ticrate 1000</code> expecting a buttery 1000-FPS server, but <code>stats</code> shows the FPS parked at a few hundred or bouncing around, unchanged by whatever number you type. This is one of the most misunderstood settings in CS 1.6: <code>sys_ticrate</code> is a <em>ceiling</em>, not a throttle you can crank, and on stock HLDS the engine simply cannot hold that ceiling. Here is what the cvar really does and how to get a genuinely high, stable server FPS.</p><h2>1. What sys_ticrate actually controls</h2><p><code>sys_ticrate</code> is set on the command line and defines the <strong>maximum</strong> rate the server loop is allowed to run:</p><pre>./hlds_run -game cstrike +sys_ticrate 1000 +map de_dust2</pre><p>Crucially, it is an upper bound. Setting it to <code>1000</code> does not <em>make</em> the loop run at 1000 — it merely permits up to 1000. Whether the loop reaches that depends on the engine, the OS timer, and the CPU. Raising the number above what the engine can achieve changes nothing, which is exactly why "I set it to 1000 and FPS didn't move" is so common. First, measure the real number:</p><pre>stats | |
| 10 | +# read the FPS column</pre><h2>2. The stock HLDS limitation</h2><p>On Valve's original HLDS, the server loop is tied to the OS scheduler in a way that makes it unable to hold a steady high FPS. It oscillates and typically will not sit anywhere near <code>1000</code> no matter how high <code>sys_ticrate</code> is set. This is not a misconfiguration you can cvar your way out of — it is a property of the old engine's timing loop. So the honest answer to "why doesn't sys_ticrate change my FPS" is often: because you are on stock HLDS, and it cannot deliver the FPS you are asking for. The unstable FPS is also what makes a lightly-populated server feel laggy, covered in <a href="/tutorials/fix-server-lags-10-players">why a server lags with only 10 players</a>.</p><h2>3. The real fix: ReHLDS</h2><p>The reliable way to get a high, <em>stable</em> server FPS is to replace HLDS with <strong>ReHLDS</strong>, the reverse-engineered engine that reworks the timing loop so it actually holds your target ticrate steadily. On ReHLDS, <code>sys_ticrate 1000</code> genuinely produces a loop pinned near 1000 with far less oscillation, and that steadiness — not the raw number — is what improves movement and hit registration. Follow the <a href="/tutorials/install-rehlds-on-linux">ReHLDS install guide</a>; it keeps your existing <code>cstrike/</code>, so it is a low-risk swap and it is the single most effective server-side performance change you can make.</p><h2>4. Do not rely on sketchy FPS boosters</h2><p>You will find old "FPS booster" tricks — wrapper libraries, forced high-precision timers, LD_PRELOAD hacks — that claim to lift stock HLDS FPS. Some raise the <em>number</em> in <code>stats</code> without making the loop genuinely stable, and several are unmaintained or unsafe on modern kernels. A misleading high FPS reading with an unstable underlying loop is worse than an honest low one because it hides the real problem. Prefer the supported route: ReHLDS on a host that is not oversold. If <code>stats</code> shows the CPU column near 100, no ticrate setting will help — the loop has no spare time.</p><h2>5. Give the loop real CPU</h2><p>Even on ReHLDS, the loop needs CPU cycles it actually owns. A cheap VPS that oversells cores will steal time from your server and cap the achievable FPS regardless of <code>sys_ticrate</code>. On Linux check for stolen time:</p><pre>top | |
| 11 | +# watch the %st (steal) column | |
| 12 | +# also compare stats FPS on an idle vs full server</pre><p>Sustained non-zero <code>%st</code> means the hypervisor is handing your cycles to other tenants — the fix is a better host or a dedicated core, not a cvar. A dedicated box or a VPS with guaranteed CPU is what lets ReHLDS hold your ticrate under load.</p><h2>Troubleshooting</h2><ul><li><strong>FPS unchanged by any <code>sys_ticrate</code> value</strong> — you are on stock HLDS, which cannot hold a high loop rate. Move to <a href="/tutorials/install-rehlds-on-linux">ReHLDS</a>.</li><li><strong>FPS high but movement still stutters</strong> — the number is inflated by a booster while the loop is unstable. Use ReHLDS for genuine stability.</li><li><strong>FPS drops as players join</strong> — the CPU is saturated or stolen. Check the <code>stats</code> CPU column and <code>top</code> <code>%st</code>.</li><li><strong>FPS steady on idle, collapses on a full server</strong> — not enough dedicated CPU. A better host, not a cvar, fixes it.</li><li><strong>Set sys_ticrate in a config, no effect</strong> — it is a command-line parameter, not a runtime cvar. Put <code>+sys_ticrate</code> on the launch line.</li></ul><h2>Verification</h2><p>Run <code>stats</code> on an idle server and note the FPS, then again under a full load. On a healthy ReHLDS box with real CPU the number should sit close to your <code>sys_ticrate</code> target and stay <em>steady</em> in both cases — steadiness matters more than the peak. If the FPS holds under load, the loop is genuinely fast and further tuning belongs in the <a href="/tutorials/fix-server-lags-10-players">rate and CPU checks</a>. If it still sags under players, you are CPU-bound and no ticrate value will change that.</p> |
managed-hosting-vs-self-hosted/en.md
A
| @@ -0,0 +1,9 @@ | ||
| 1 | +--- | |
| 2 | +title: "Managed Game Hosting vs Self-Hosted VPS" | |
| 3 | +excerpt: "A practical comparison of renting a managed CS 1.6 game server versus running your own on a VPS, covering control, cost, DDoS protection, tickrate, and which fits your situation." | |
| 4 | +category: "hosting" | |
| 5 | +tags: "hosting, comparison" | |
| 6 | +image: "" | |
| 7 | +read_time: "9 min read" | |
| 8 | +--- | |
| 9 | +<p>There are two honest ways to host a CS 1.6 server: rent a managed slot from a game-server provider who hands you a control panel, or rent a VPS and install everything yourself. Neither is universally right — they trade control against convenience in opposite directions. This lays out the real differences so you can pick based on your skills, your budget, and how much you want to own.</p><h2>1. What each model actually gives you</h2><p>The core distinction is what you manage:</p><ul><li><strong>Managed game hosting</strong> — the provider runs the machine, the OS, and often the CS binaries. You get a web panel to start/stop, edit configs, install plugins, and change maps. You never touch the shell.</li><li><strong>Self-hosted VPS</strong> — the provider gives you a bare Linux box with root. You install <a href="/tutorials/install-cs16-dedicated-server-linux-steamcmd">the dedicated server via SteamCMD</a>, ReHLDS, Metamod, AMX Mod X, and everything else, and you own every layer.</li></ul><h2>2. Control and flexibility</h2><p>This is where a VPS wins decisively. On managed hosting you are limited to what the panel exposes — some providers block custom binaries, restrict which mods you can run, or lag behind on ReHLDS/ReGameDLL versions. On a VPS you can install ReHLDS, ReAPI, custom modules, run <a href="/tutorials/multiple-cs16-servers-one-vps">multiple servers on one box</a>, script cron restarts, and tune the kernel. If you want to run anything non-standard — a custom mod, a specific toolchain, sub-tick FPS tuning — the VPS is the only option that will not fight you.</p><h2>3. Effort and expertise</h2><p>Managed hosting wins here. It exists precisely so you do not need to know Linux, systemd, firewalls, or FastDL. If the words <a href="/tutorials/hlds-systemd-service">systemd service</a> or <a href="/tutorials/cs16-server-firewall-ports">firewall ports</a> make you nervous, a panel that just works is worth paying for. A VPS assumes you can administer Linux, secure it, and fix it at 2am when it segfaults on map change — that is a real skill set, and if you do not have it or want it, self-hosting becomes a second job.</p><h2>4. Cost</h2><p>The comparison is not simple. Managed slots are usually priced per player slot and often cost more per unit of capacity, but include the labour. A VPS is cheaper for raw resources — you can run several servers on one box — but the "savings" assume your time is free. For one small server run by a non-technical owner, managed is often cheaper all-in once you value your hours. For multiple servers or a technical owner, a VPS is dramatically more cost-effective.</p><h2>5. DDoS protection and network quality</h2><p>CS 1.6 servers attract attacks, and filtering matters. Good managed providers include DDoS protection in the price; on a VPS you must arrange it yourself (<a href="/tutorials/ddos-protected-hosting">DDoS-protected hosting</a>). Check either way — an unprotected server of either kind can be knocked offline by a single annoyed player. Also weigh location: you want the server physically near your target region for low ping, which for CS 1.6 usually means near the CIS or your regional audience.</p><h2>6. Performance and tickrate</h2><p>Both models can deliver a good server, but the ceiling differs. Serious FPS/tickrate tuning — a stable 1000 FPS server on Linux — needs kernel and scheduler control you only get on a VPS or dedicated box (<a href="/tutorials/stable-1000-fps-linux-server">stable 1000 FPS Linux server</a>). Many managed panels run fine for a normal public but cap what you can tune. If competitive-grade server performance matters, self-host.</p><h2>Choosing</h2><table><thead><tr><th>If you...</th><th>Choose</th></tr></thead><tbody><tr><td>are non-technical and want one server that works</td><td>Managed hosting</td></tr><tr><td>want full control, custom binaries, or several servers</td><td>Self-hosted VPS</td></tr><tr><td>need deep FPS/tickrate tuning</td><td>Self-hosted VPS</td></tr><tr><td>value convenience over cost for a single server</td><td>Managed hosting</td></tr><tr><td>can administer Linux and want the best cost-per-capacity</td><td>Self-hosted VPS</td></tr></tbody></table><h2>Common errors</h2><ul><li><strong>Bought managed, then hit a wall installing a custom mod</strong> — the panel blocked it. Check mod/binary freedom before buying if you have plans beyond vanilla.</li><li><strong>Rented a VPS with no Linux skills</strong> — it sat broken. Be honest about your ability; managed exists for a reason.</li><li><strong>Ignored DDoS protection</strong> — the server was trivially knocked offline. Confirm filtering on either model.</li><li><strong>Chose a distant datacentre for price</strong> — high ping killed the population. Host near your region.</li><li><strong>Assumed a VPS is always cheaper</strong> — not once you count your own hours for a single small server.</li></ul><h2>Verification</h2><p>Before committing, test the fit. On managed, confirm during a trial that you can install the exact mod and plugins you need and edit the configs you care about — not just the ones the panel highlights. On a VPS, stand up the server following <a href="/tutorials/install-cs16-dedicated-server-linux-steamcmd">the SteamCMD install</a>, measure its FPS, and confirm you can restart and recover it yourself. Whichever you pick, verify DDoS protection is real and the datacentre ping to your target region is low before you advertise the address. And if a "boost service" promises to fill it, read <a href="/tutorials/do-server-boost-services-work">do server boost services work</a> first.</p> | |
| 0 | 10 |
