Add 7 tutorials (7 files)
Browse Source
Daemon666 committed
parent 56e2dca704
commit 993385f970245ecbee3677834fb78b6455ddbbf7
7 changed files
with 76 additions and 0 deletions
A
boosting-vs-organic-growth/en.md
+9 -0
A
fix-fastdl-404-bz2/en.md
+16 -0
A
fix-mysql-cant-connect-111/en.md
+9 -0
A
fix-server-fps-drops-with-players/en.md
+11 -0
A
fix-sv-maxrate-ignored/en.md
+13 -0
A
gametracker-ranking-explained/en.md
+9 -0
A
vote-rewards-toplists/en.md
+9 -0
boosting-vs-organic-growth/en.md
A
| @@ -0,0 +1,9 @@ | ||
| 1 | +--- | |
| 2 | +title: "Boosting vs Organic Growth: What Actually Sticks" | |
| 3 | +excerpt: "What server boosting actually does, why fake players fill a server but do not retain real ones, and how to combine an initial push with the content that turns joiners into regulars." | |
| 4 | +category: "hosting" | |
| 5 | +tags: "boosting, growth" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>Every new-server admin hits the same wall: the server list sorts by player count, so an empty server stays empty because nobody joins an empty server. "Boosting" promises to break that loop by putting bodies on the server. The honest question is not whether boosting works — it can — but what part of the problem it solves and what it leaves untouched. This separates the mechanic from the myth so you spend effort where it compounds.</p><h2>1. What boosting actually does</h2><p>Boosting fills the player-count column so your server stops being invisible. There are two broad kinds and they are not equal. <strong>Fake-player boosting</strong> inserts bot-like entries that pad the count — the server <em>looks</em> populated in the browser. <strong>Real-traffic boosting</strong> (the model behind services like the one this site runs) routes actual player connections toward listed servers so real people land on yours. The first manipulates a number; the second manufactures the cold-start moment where a real browser sees real activity and joins. Only one of them survives contact with a player who actually connects. We wrote a fuller breakdown in <a href="/tutorials/do-server-boost-services-work">do server boost services work</a>.</p><h2>2. Why fake players fill but do not retain</h2><p>A padded count gets the first real player through the door — and then the illusion works against you. They join expecting a game, find the "players" do not shoot back or behave like humans, and leave, often for good. Worse, the browser then shows your count dropping, which signals "dying server" to the next browser. Fake players can win the click and lose the session. Retention is a property of what happens <em>after</em> someone connects, and no amount of count-padding touches that. If the gameplay is not there, boosting just raises the number of people who bounce.</p><h2>3. Why organic growth is slow but compounding</h2><p>Organic growth is the reverse trade: painfully slow at zero, self-reinforcing once it catches. A real player who has fun stays the hour, comes back tomorrow, and — the compounding part — brings the friends they play with. Two real regulars are worth more than twenty fake slots because regulars generate the genuine activity that pulls the next browser in and keeps them. The whole game of growth is converting a first-time joiner into a second-time joiner; everything that does that (a fun mod, low ping, no lag, an admin who is present) is organic growth infrastructure. See <a href="/tutorials/get-players-on-new-server">getting players on a new server</a>.</p><h2>4. Combine the push with the content</h2><p>The two are not opposites — the working strategy uses boosting as ignition and organic content as the engine. The sequence that sticks:</p><ol><li><strong>Get the fundamentals right first.</strong> A fun, well-chosen mod (<a href="/tutorials/pick-a-mod-with-players">pick a mod with players</a>), low ping for your region, and zero lag. Boosting a broken server just buys you more witnesses to the breakage.</li><li><strong>Use a boost to break the cold-start.</strong> A real-traffic push during your peak hours gets the first handful of genuine players on so the server crosses the threshold where it looks alive.</li><li><strong>Convert them.</strong> Adverts pointing at your Discord, a stats/rank system so players have a reason to return, and an admin present at peak so the server feels run.</li><li><strong>Let it carry itself.</strong> Once you hold a regular core at peak, real activity does the boosting for free.</li></ol><h2>5. Set honest expectations</h2><p>Boosting is ignition, not a business model. If you boost and the numbers collapse the moment you stop, that is the signal that steps 1 and 3 are missing — the server has no retention to carry. A boost that leaves behind even a small real core has done its job; a boost you have to run forever to show any count is masking a server nobody actually wants to play. Judge it by what remains an hour after the push ends, not by the peak number during it.</p><h2>Common errors</h2><ul><li><strong>Numbers vanish the instant boosting stops</strong> — no retention underneath. Fix the mod, ping, and reasons-to-return first.</li><li><strong>Real players join then immediately leave</strong> — fake-player padding oversold the server. Real activity is what holds them.</li><li><strong>Boosting a laggy or empty-of-content server</strong> — you are buying witnesses to the problem. Get fundamentals right before any push.</li><li><strong>Treating boost count as success</strong> — the metric that matters is real regulars retained, not peak displayed count.</li><li><strong>No path off the server</strong> — without a Discord or rank hook, even happy players do not come back. Give them a reason.</li></ul><h2>Verification</h2><p>Run a boost during one peak window with your fundamentals in place, then look at the server 24 hours later with no boost running. Count the real players who returned on their own. If a handful come back unprompted, the ignition worked and the engine is real — repeat and let the core grow. If the count is back to zero, stop boosting and fix retention, because you are pouring traffic into a server that cannot hold it. Track the trend over a week, not a single evening: growth that sticks shows a rising floor of regulars, not just repeated peaks.</p> |
fix-fastdl-404-bz2/en.md
A
| @@ -0,0 +1,16 @@ | ||
| 1 | +--- | |
| 2 | +title: "Fix: FastDL 404 / Missing .bz2 File Errors" | |
| 3 | +excerpt: "Why FastDL requests 404, the cstrike path the engine appends, how bzip2 pre-compression works and when the client falls back, MIME-type blocks, and testing the exact URL in a browser." | |
| 4 | +category: "errors" | |
| 5 | +tags: "fastdl, bzip2" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>You set up <a href="/tutorials/fastdl-setup-guide">FastDL</a>, but clients still fail to download and the console shows repeated <code>404</code> responses, or the server never offloads to HTTP at all. FastDL is just a web server hosting your game files at the URL in <code>sv_downloadurl</code>; a 404 means the client asked for a path that does not resolve on that web server. The fix is making the on-disk layout, the URL, and the file compression line up exactly with what the engine requests.</p><h2>1. Know the exact URL the client builds</h2><p>Given <code>sv_downloadurl "http://dl.example.com/cs"</code>, the engine appends the full game-relative path <strong>including <code>cstrike/</code></strong>. So for a map it requests:</p><pre>http://dl.example.com/cs/cstrike/maps/de_rats.bsp</pre><p>The single most common 404 cause is a web root missing that <code>cstrike/</code> level, or doubling it (<code>cs/cstrike/cstrike/...</code>). Your document root under <code>/cs</code> must contain a <code>cstrike/</code> directory that mirrors the server's, so the path above resolves to a real file.</p><h2>2. Understand the .bz2 fallback</h2><p>FastDL is faster when files are pre-compressed with bzip2. The client first asks for the <code>.bz2</code>, and only if that 404s does it ask for the raw file:</p><pre>GET /cs/cstrike/maps/de_rats.bsp.bz2 -> 404 | |
| 10 | +GET /cs/cstrike/maps/de_rats.bsp -> 200</pre><p>A 404 on the <code>.bz2</code> alone is <em>not</em> fatal — the client falls back to the uncompressed file. A problem exists only when <strong>both</strong> 404. So if downloads work but your logs are full of <code>.bz2</code> 404s, you simply have not pre-compressed the files; the transfers still succeed, just larger. To get the speed benefit, compress each servable file (keeping the original too):</p><pre>bzip2 -k cstrike/maps/de_rats.bsp | |
| 11 | +# produces de_rats.bsp.bz2 alongside the original</pre><p>Then copy both to the mirror. The <code>-k</code> keeps the source file so the raw fallback still exists.</p><h2>3. Fix the web server MIME/type handling</h2><p>Some web servers refuse to serve <code>.bsp</code> or <code>.bz2</code> because the extension is not in their MIME map, returning a 403 or a broken transfer. Serve them as generic binary. For Nginx:</p><pre>location /cs/ { | |
| 12 | + types { } | |
| 13 | + default_type application/octet-stream; | |
| 14 | + autoindex off; | |
| 15 | +} | |
| 16 | +</pre><p>For Apache, ensure the directory allows access and that no handler intercepts these extensions. The goal is that the web server treats <code>.bsp</code>, <code>.bz2</code>, <code>.mdl</code>, <code>.spr</code>, <code>.wav</code> as plain downloadable files.</p><h2>4. Match case and path exactly</h2><p>Linux web servers are case-sensitive. If the map is <code>de_rats.bsp</code> on the game server but <code>De_Rats.bsp</code> on the mirror, every request 404s. The map name the server references, the file on the mirror, and the URL must match character for character. This also bites when a plugin references a sound in one case and the file is stored in another.</p><h2>5. Confirm the file is actually on the mirror</h2><p>FastDL cannot serve what is not there. Every custom resource — maps, models, sprites, sounds, skyboxes — that the game server has must also be copied to the mirror under the same relative path. A file present on the game server but not synced to the web root 404s for every client. Keep the mirror in step with your <a href="/tutorials/fix-custom-map-download-fails">custom-content</a> as you add maps.</p><p>A reliable pattern is to sync the game server's <code>cstrike/maps</code>, <code>cstrike/models</code>, <code>cstrike/sound</code>, <code>cstrike/sprites</code> and <code>cstrike/gfx</code> folders to the mirror with <code>rsync</code> after every content change, and to run the bzip2 compression step as part of that sync so the <code>.bz2</code> variants never drift out of date. If you compress once and then add maps, the new maps have no <code>.bz2</code> — harmless, but you lose the speed benefit until you recompress.</p><h2>Common errors</h2><ul><li><strong>Every file 404s</strong> — the <code>cstrike/</code> level is missing or doubled in the web root. The URL must resolve to a real file including <code>cstrike/</code>.</li><li><strong>Only <code>.bz2</code> 404s, downloads still work</strong> — files are not pre-compressed. Harmless, but compress them for speed.</li><li><strong>403 instead of 404</strong> — the web server blocks the extension or directory. Serve as <code>application/octet-stream</code> and allow the path.</li><li><strong>Some maps 404, others fine</strong> — case mismatch or a file never synced to the mirror.</li><li><strong>Server never uses HTTP at all</strong> — <code>sv_downloadurl</code> is empty or unreachable; it fell back to the slow UDP transfer.</li></ul><h2>Verification</h2><p>Paste the exact URL the client would request into a browser:</p><pre>http://dl.example.com/cs/cstrike/maps/de_rats.bsp</pre><p>It must download (200), not 404. Try the <code>.bz2</code> too — if it 200s, compression is in place; if it 404s but the raw file downloads, you are fine but uncompressed. Then delete the map from a test client and connect: the console should show a <code>200</code> fetch over HTTP rather than a slow in-game transfer. When the browser resolves the path and the client pulls the file fast, FastDL is correct.</p> |
fix-mysql-cant-connect-111/en.md
A
| @@ -0,0 +1,9 @@ | ||
| 1 | +--- | |
| 2 | +title: "Fix: Can't Connect to MySQL Server (errno 111) from the Game Server" | |
| 3 | +excerpt: "Why errno 111 is connection refused and not a password problem, the bind-address and skip-networking traps, opening port 3306, and proving the path before blaming the plugin." | |
| 4 | +category: "errors" | |
| 5 | +tags: "mysql, networking" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>An AMX Mod X SQL plugin logs that it cannot connect to the MySQL server with error 111. Unlike an access-denied error, this one never even reached the login stage: <strong>errno 111 is ECONNREFUSED</strong>, the operating system telling you nothing is listening at that address and port, or a firewall dropped the connection. No password is involved. The fix is entirely about the network path between the game server and MySQL — making MySQL listen where the plugin is dialing, and letting the packet through.</p><h2>1. Read the error and what 111 means</h2><p>The AMXX log shows something like:</p><pre>Can't connect to MySQL server on '203.0.113.10' (111)</pre><p>The <code>(111)</code> is the system error code for "connection refused." It means the game server sent a connection to that host and port and got an immediate rejection — there was no service accepting it. Common causes, in order of likelihood: MySQL is bound to loopback only, MySQL is not running, the wrong port is being dialed, or a firewall is blocking 3306.</p><h2>2. Check MySQL's bind-address</h2><p>By default many MySQL/MariaDB installs listen only on <code>127.0.0.1</code>. That is fine when the game server and database are the same box and the plugin connects to <code>127.0.0.1</code>. But if the plugin connects to a LAN or public IP, MySQL bound to loopback refuses it — errno 111. In the server config (commonly <code>my.cnf</code> / <code>50-server.cnf</code>):</p><pre>bind-address = 0.0.0.0</pre><p>Binding to <code>0.0.0.0</code> makes it listen on all interfaces; restart MySQL afterward. Also make sure <code>skip-networking</code> is <strong>not</strong> set — that option disables TCP entirely and guarantees a refused connection from anything but a local socket.</p><h2>3. Confirm MySQL is actually running and on which port</h2><p>A refused connection can simply mean the service is down or on a non-default port. On the database host, confirm MySQL is up and listening on the port the plugin dials (default <strong>3306</strong>). If the plugin's <code>amx_sql_host</code> includes a non-standard port, it must match where MySQL listens. A mismatched port produces the exact same errno 111.</p><h2>4. Open the firewall between the two hosts</h2><p>Even with MySQL listening on all interfaces, a firewall between the game server and the database will refuse or drop 3306. Allow it:</p><ul><li>On the database host, permit inbound TCP 3306 from the game server's IP (prefer a specific source IP over opening it to the world).</li><li>Check both a local firewall (<code>ufw</code>/<code>iptables</code>) and any provider/cloud security group.</li><li>Do not expose 3306 to the whole internet — scope it to the game server's address.</li></ul><h2>5. Prove the path independently of the plugin</h2><p>Before touching the plugin again, test raw connectivity from the game server host to the database. A simple TCP probe to the database IP on 3306, or the MySQL command-line client pointed at that host, will either connect (proving the path is open, so the remaining issue is credentials) or be refused (confirming 111 is still a network problem). This separates "can I even reach MySQL" from "will MySQL let me log in," and stops you debugging the wrong layer. If the probe from the game server is refused but the same probe from the database host itself succeeds, you have proven the problem is between the two machines — a firewall or a loopback-only bind — and not the database being down.</p><h2>Troubleshooting</h2><ul><li><strong>Works with <code>127.0.0.1</code>, fails with the real IP</strong> — MySQL is bound to loopback only. Set <code>bind-address = 0.0.0.0</code> and restart.</li><li><strong>Refused even locally</strong> — MySQL is not running, or <code>skip-networking</code> is on. Start the service and remove <code>skip-networking</code>.</li><li><strong>Connects from the DB host but not the game server</strong> — a firewall between them blocks 3306. Allow the game server's IP.</li><li><strong>Intermittent 111</strong> — MySQL restarting/crashing under load, or hitting <code>max_connections</code> and refusing new ones. Check the MySQL error log.</li><li><strong>Reaches MySQL now but is rejected</strong> — that is progress: you moved from errno 111 to an auth error. Continue with <a href="/tutorials/fix-mysql-access-denied-amxx">access denied for user</a>.</li></ul><h2>Verification</h2><p>From the game server host, run the raw connectivity test again — a successful TCP handshake to the database on 3306 means errno 111 is resolved. Then change the map to reconnect the plugin and watch <code>addons/amxmodx/logs/</code>: the <code>(111)</code> line should be gone. If it now shows an access-denied message instead, you have succeeded at the network layer and only need to fix credentials. The definitive success signal is the plugin writing to and reading from the database during normal play — a stats row after a kill, a ban row after a test ban.</p> |
fix-server-fps-drops-with-players/en.md
A
| @@ -0,0 +1,11 @@ | ||
| 1 | +--- | |
| 2 | +title: "Fix: Server FPS Drops When Players Join" | |
| 3 | +excerpt: "Why server FPS collapses as the server fills, how sys_ticrate and the fps_max cap interact, the -pingboost and -sys_ticrate startup options, and how to diagnose whether it is CPU, a plugin, or the timing loop." | |
| 4 | +category: "errors" | |
| 5 | +tags: "fps, performance" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>An empty CS 1.6 server holds a high, steady server FPS, but as players join it sags — movement feels rubbery, hit registration gets worse, and <code>stats</code> shows the FPS falling. Server FPS is how many times per second the engine simulates the world; when it drops below the intended rate the whole server feels laggy even on a fast link. The causes are the timing configuration, CPU contention, and expensive plugins. Here is how to pin it down.</p><h2>1. Measure the real server FPS</h2><p>Do not guess — read it. In the server console:</p><pre>stats</pre><p>This prints the current server FPS, CPU percentage, players, and network in/out. Watch it with the server empty, then again as it fills. If FPS is high when empty and collapses under load, the server is CPU- or timing-bound, not network-bound. Note the FPS numbers at each population; you will compare against them after each change.</p><h2>2. Set the timing rate correctly</h2><p>The engine's simulation rate is governed by <code>sys_ticrate</code> and, on ReHLDS, the FPS cap. On original HLDS the classic way to raise and stabilize server FPS is the startup option:</p><pre>./hlds_run -game cstrike -console -pingboost 1 -sys_ticrate 1000 +map de_dust2</pre><p><code>-sys_ticrate</code> sets the target simulation rate, and <code>-pingboost</code> selects a timing method (modes 1–3) that changes how the engine sleeps between frames. On ReHLDS the FPS is controlled through its own cvar rather than the old pingboost hacks — ReHLDS exposes <code>sys_ticrate</code> and an <code>fps_max</code>-style server cvar; set the target there. The goal is a server FPS that stays at your target under full load, not one that only looks good when empty.</p><h2>3. Rule out CPU contention</h2><p>If <code>stats</code> shows CPU climbing toward 100% as players join, the box cannot sustain the simulation rate for that many players. Two realities of GoldSrc matter here: it is largely single-threaded, so one busy core caps you regardless of how many cores the box has, and shared/oversold hosting gives you inconsistent CPU time. Check the host CPU with <code>top</code> and look for the HLDS process pegging one core:</p><pre>top -p $(pgrep -f hlds_linux)</pre><p>If that process sits near 100% of a core under load, you are CPU-bound — lower the target FPS to something the core can hold, reduce <code>maxplayers</code>, or move to a host with a stronger single-core allocation. No cvar tuning beats a saturated core.</p><h2>4. Find an expensive plugin</h2><p>A plugin doing heavy per-frame or per-player work — a badly written <code>server_frame</code> hook, a plugin running blocking work, or one looping over all players every tick — drags FPS down exactly as population rises, because the cost scales with players. Isolate it by pausing plugins one at a time and watching <code>stats</code>:</p><pre>amxx pause suspect.amxx</pre><p>If FPS recovers when a specific plugin is paused, that plugin is the cost. A frequent culprit is a plugin issuing synchronous database queries on the main thread — see <a href="/tutorials/fix-server-freeze-mysql-query">the blocking MySQL fix</a> for why that stalls the whole server. Replace or fix the offender; do not just leave it paused if you need it.</p><h2>5. Keep rates sane</h2><p>Server-side rate caps that are too generous let a full server flood the simulation with more work than the CPU can process. Set reasonable caps in <a href="/tutorials/essential-server-cvars">server.cfg</a>:</p><pre>sys_ticrate 1000 | |
| 10 | +sv_maxrate 25000 | |
| 11 | +sv_maxupdaterate 100</pre><p>These bound the per-client network and update load so one packed server does not try to push more than the box can handle. Tune them to your player count and link, not to the theoretical maximum.</p><h2>Troubleshooting</h2><ul><li><strong>FPS high empty, collapses full</strong> — CPU-bound or an O(players) plugin. Check <code>top</code> and pause plugins one by one.</li><li><strong>FPS never reaches target even empty</strong> — wrong timing setup. Set <code>-sys_ticrate</code>/<code>-pingboost</code> on HLDS or the ReHLDS FPS cvar.</li><li><strong>One core at 100%</strong> — GoldSrc is single-threaded; you are CPU-limited. Lower target FPS, reduce slots, or upgrade the host.</li><li><strong>FPS recovers when one plugin is paused</strong> — that plugin is the cost; fix or replace it.</li><li><strong>Fine on a dedicated box, bad on shared hosting</strong> — oversold CPU steals time. Move to a host with guaranteed single-core performance.</li><li><strong>Laggy only in big firefights</strong> — rates too high flooding the CPU. Cap <code>sv_maxrate</code>/<code>sv_maxupdaterate</code>.</li></ul><h2>Verification</h2><p>After each change, fill the server (or simulate load) and read <code>stats</code> again, comparing the FPS at full population against your empty-server baseline. A healthy server holds close to its target FPS at full slots with CPU below saturation. If FPS now stays stable as players join, the fix held; if it still sags only under load, the bottleneck is the CPU core or a scaling plugin, not the timing config. For servers that degrade only after long uptime rather than under player load, that is a different pattern — see <a href="/tutorials/fix-server-laggy-after-days">the long-uptime lag fix</a>.</p> |
fix-sv-maxrate-ignored/en.md
A
| @@ -0,0 +1,13 @@ | ||
| 1 | +--- | |
| 2 | +title: "Fix: sv_maxrate / sv_maxupdaterate Settings Ignored" | |
| 3 | +excerpt: "Why your sv_maxrate and sv_maxupdaterate seem to have no effect, which of these cvars need ReHLDS/ReGameDLL, the min/max interplay, and how to confirm clients actually get the rate." | |
| 4 | +category: "errors" | |
| 5 | +tags: "rates, cvars" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>You set <code>sv_maxrate</code> and <code>sv_maxupdaterate</code> high so modern clients can run smooth 100-tick netcode, but players still cap at a low rate or their <code>net_graph</code> shows a modest updaterate no matter what you type. These cvars are frequently "ignored" for concrete reasons: some do not exist on stock HLDS, some are clamped by their min counterparts, and some are being reset later in your config load order. Here is how the rate cvars actually behave.</p><h2>1. Know which cvars are stock and which are not</h2><p>This is the crux. On <strong>stock Valve HLDS</strong>, <code>sv_maxrate</code> and <code>sv_minrate</code> exist, but the fine-grained update-rate ceilings people expect — <code>sv_maxupdaterate</code>, <code>sv_minupdaterate</code>, <code>sv_maxcmdrate</code> — come from <strong>ReHLDS / ReGameDLL_CS</strong>. On a plain HLDS box, setting <code>sv_maxupdaterate 101</code> is a silent no-op: the cvar may not be honoured, and clients are capped by the engine's own defaults instead. If your update-rate ceiling is being ignored, the first question is whether you are even running an engine that implements it. Install <a href="/tutorials/install-rehlds-on-linux">ReHLDS</a> (and ReGameDLL) to get real control over these.</p><h2>2. Set the full, consistent block</h2><p>Rates work as min/max pairs. If you set a max but leave the min at a value that clamps clients, you get surprising results. Set the whole block coherently in <a href="/tutorials/setup-server-cfg-cs16">server.cfg</a>:</p><pre>sv_maxrate 25000 | |
| 10 | +sv_minrate 5000 | |
| 11 | +sv_maxupdaterate 101 | |
| 12 | +sv_minupdaterate 20 | |
| 13 | +sv_maxcmdrate 101</pre><p>A client's effective rate is clamped into the <code>[min, max]</code> window. If <code>sv_minupdaterate</code> is left high, low-rate clients are forced up; if <code>sv_maxupdaterate</code> is low or unimplemented, high-rate clients are pulled down and it looks like your <code>101</code> was ignored. Set both ends deliberately.</p><h2>3. Watch the config execution order</h2><p>A classic "ignored" case is that your value <em>is</em> applied, then overwritten later. ReGameDLL ships a <code>game.cfg</code>, AMX Mod X execs its own configs, and any of these can re-set a rate cvar after your <code>server.cfg</code> runs. If <code>sv_maxrate</code> reverts, something is exec-ing after you. Read the value back at runtime, long after boot:</p><pre>sv_maxrate</pre><p>If the console shows a different number than you set, hunt for the later config that overrides it — check <code>game.cfg</code>, <code>amxx.cfg</code>, and any map-specific config. Put your authoritative rate values where nothing runs after them, or in the config that runs last.</p><h2>4. Remember the client still chooses within your window</h2><p>The server cvars are ceilings and floors, not assignments. A client running <code>cl_updaterate 30</code> gets 30 even if your max is 101 — you cannot force a client <em>up</em> beyond what it requests except via the min floor. So "players are at 30" with <code>sv_maxupdaterate 101</code> is not the server ignoring you; it is the client asking for 30. Raise the floor to lift lazy clients:</p><pre>sv_minupdaterate 60</pre><p>Now a client requesting less than 60 is pulled up to 60. Tell players to set <code>rate 25000; cl_updaterate 101; cl_cmdrate 101</code> to actually use the headroom you provided.</p><h2>5. Rule out an old engine cap</h2><p>Very old HLDS builds cap <code>sv_maxrate</code> lower than modern play expects, and some hosts pre-set a low <code>sv_maxrate</code> in a base config you did not write. If <code>sv_maxrate</code> will not go above, say, <code>20000</code> however you set it, you are likely on an outdated engine or a host template — updating to a current ReHLDS build removes those artificial ceilings and is the same move that stabilises your <a href="/tutorials/fix-server-lags-10-players">server FPS</a>.</p><h2>Troubleshooting</h2><ul><li><strong><code>sv_maxupdaterate</code> does nothing</strong> — you are on stock HLDS where it is not implemented. Move to <a href="/tutorials/install-rehlds-on-linux">ReHLDS</a>/ReGameDLL.</li><li><strong>Value reverts after boot</strong> — a later config (<code>game.cfg</code>, <code>amxx.cfg</code>, map cfg) overrides it. Read it back with <code>sv_maxrate</code> and fix the exec order.</li><li><strong>Clients stuck at a low updaterate</strong> — they are requesting it. Raise <code>sv_minupdaterate</code> and have players set <code>cl_updaterate 101</code>.</li><li><strong><code>sv_maxrate</code> refuses to go high</strong> — an outdated engine or a host base config caps it. Update the engine.</li><li><strong>Only some players benefit</strong> — the others' <code>rate</code>/<code>cl_updaterate</code> are low. Server cvars set the window, not the client's choice.</li></ul><h2>Verification</h2><p>Read every rate cvar back in the console with no argument and confirm each holds the value you set — do this well after startup so a late config would already have overridden it. Then have a player set high client rates, join, and run <code>net_graph 3</code>: the reported updaterate should reach your ceiling and hold. If the server cvars read correctly and a well-configured client hits 101, the rates are being honoured. Lock the final block into the last-executing config so nothing quietly resets it.</p> |
gametracker-ranking-explained/en.md
A
| @@ -0,0 +1,9 @@ | ||
| 1 | +--- | |
| 2 | +title: "How GameTracker Ranking Works (and How to Climb It)" | |
| 3 | +excerpt: "What GameTracker's server rank actually measures, how sustained player activity and user votes feed it, why padding fails, and the honest levers that move you up the list." | |
| 4 | +category: "hosting" | |
| 5 | +tags: "gametracker, ranking" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>GameTracker assigns every tracked server a rank, and a higher rank means more visibility, which means more players — a flywheel worth understanding. The rank is not a mystery and it is not for sale: it is driven by the activity GameTracker observes when it queries your server, plus user votes. This explains what the rank rewards, why the obvious cheats fail, and the levers that genuinely move it.</p><h2>1. What the rank measures</h2><p>GameTracker ranks servers primarily on <strong>observed player activity over time</strong>. It queries your server on a schedule, records how many real players are on, and accumulates that history. A server that is consistently populated ranks above one that spikes occasionally, and a server tracked for months outranks a fresh one with the same current count because it has more accumulated history. The rank is comparative — you are ranked against every other CS 1.6 server GameTracker tracks — so climbing means being busier, more consistently, than the servers above you.</p><h2>2. Why history matters more than a single peak</h2><p>A one-off full server does little; sustained presence does a lot. Because the rank integrates activity over time, the winning pattern is <em>consistent</em> population — the same reliable peak hours every day — rather than a rare packed night. This is exactly why the <a href="/tutorials/first-30-regulars-playbook">first-30-regulars playbook</a> emphasises a fixed seeding hour: predictable daily activity feeds the rank far better than sporadic bursts. Time-in-population is the currency.</p><h2>3. The voting lever</h2><p>GameTracker also lets logged-in users vote for a server, and votes contribute to visibility. This is a legitimate lever you can pull: ask your regulars to vote for the server. Put a reminder in the <a href="/tutorials/motd-txt-html-guide">MOTD</a> and Discord. Unlike faking the player count, voting is a real signal — real people expressing a preference — so it is both allowed and effective. A community of thirty regulars who each vote gives you a durable edge over an unvoted competitor.</p><h2>4. Why padding and faking fail</h2><p>The temptation is to inflate the count so the activity metric reads higher. It does not work, for two reasons. First, GameTracker tracks the <em>shape</em> of activity — genuine servers show players joining and leaving, a count that churns; a padded server shows an unnaturally flat or patternless count that does not resolve into real sessions, which is detectable. Second, flagged servers lose ranking or are removed, so the downside is losing the very position you were gaming. The honest path is slower but compounds; the dishonest one risks a reset to zero. See <a href="/tutorials/fake-players-bot-padding">fake players and bot padding</a> for the full risk picture.</p><h2>5. The levers that actually move you up</h2><p>Everything that raises rank comes back to real, sustained play:</p><ul><li><strong>Consistent peak hours</strong> — the single biggest factor. Be reliably populated at the same times.</li><li><strong>Retention</strong> — ranks, stats, and recognition keep players coming back, raising average population (<a href="/tutorials/setup-stats-system">stats system</a>).</li><li><strong>Votes</strong> — mobilize your regulars to vote.</li><li><strong>A claimed, branded page</strong> — more joiners convert when the page looks alive and links to your community (<a href="/tutorials/gametracker-claim-server">claiming your page</a>).</li><li><strong>Accurate tracking</strong> — a stale IP that shows offline destroys accumulated rank; keep the listing current.</li></ul><h2>Common errors</h2><ul><li><strong>Rank will not move despite good nights</strong> — your activity is spiky. The metric rewards consistency; hold fixed peak hours for weeks.</li><li><strong>Dropped in rank suddenly</strong> — the page went offline (IP change, downtime) and lost tracked activity. Restore uptime and update the connect address.</li><li><strong>Padding "raised" then tanked the rank</strong> — the fake signature was flagged. Remove it; recover with real play.</li><li><strong>Votes not helping</strong> — too few real regulars are voting, or they are not logged in. Votes need real accounts; grow the community first.</li><li><strong>New server ranks low with a full house</strong> — it lacks history. Rank builds from accumulated activity, not a single snapshot; keep it up.</li></ul><h2>Verification</h2><p>Watch your GameTracker page over two weeks with a fixed daily peak hour and confirm the rank trends up as history accumulates — it will move slowly, which is normal. Compare your activity graph to a server ranked just above you; if theirs shows more consistent population, that is the gap to close, not a bigger single peak. When votes come in from your regulars and the graph shows genuine churn, you are climbing on exactly the signals GameTracker is built to reward. Pair this with <a href="/tutorials/cs16-toplists-worth-joining">the toplists overview</a> to spread the same activity across every list.</p> |
vote-rewards-toplists/en.md
A
| @@ -0,0 +1,9 @@ | ||
| 1 | +--- | |
| 2 | +title: "Vote Rewards: Turning Toplist Votes into Real Players" | |
| 3 | +excerpt: "How CS 1.6 server toplists and vote-reward systems work, how to rank higher by rewarding in-game votes, delivering the reward by SteamID, and the pitfalls that get a server delisted." | |
| 4 | +category: "hosting" | |
| 5 | +tags: "voting, growth" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>Server toplists are ranking sites where CS 1.6 servers compete for a spot near the top by collecting votes from players, and a high spot sends a steady trickle of new players your way. The engine that makes it work is the <strong>vote reward</strong>: players vote for your server on the toplist and get a small in-game perk in return. Set up honestly it is one of the better free growth channels; set up greedily it gets you banned from the list. Here is how the loop works and how to build it without crossing the line.</p><h2>1. Understand the loop</h2><p>The cycle is: a player types a command in your server, gets sent to the toplist to cast a vote, the toplist records it (usually keyed to their IP to prevent duplicates), your server climbs the ranking, more browsers of that toplist see you near the top and join, and some of them vote too. The reward is the incentive that keeps the loop spinning — without it, almost nobody bothers to vote. The value you get is the <em>ranking position</em>, which is free advertising to everyone who reads that list.</p><h2>2. Register on a toplist and read its rules</h2><p>Pick a toplist that actually has CS 1.6 traffic in your region and register your server there with your IP and port. Every legitimate list publishes rules about what rewards are allowed and how votes are validated — read them, because they define the boundary you must not cross. Most enforce one vote per IP per day and ban servers that give game-changing rewards or fake votes. Registering also usually gets you a public profile page, similar to a <a href="/tutorials/server-banners-signatures">tracker banner</a>, that is itself a bit of discoverability.</p><h2>3. Reward the vote — but keep it cosmetic</h2><p>The reward must follow the same rule as all <a href="/tutorials/monetize-cs16-server">monetization</a>: never pay-to-win. Good vote rewards are cosmetic or trivially convenient — a temporary chat tag, a small amount of a fun currency, a name colour for the map, a one-time cosmetic effect. Bad rewards — extra HP, money, armour, weapons — both unbalance the round and violate most toplists' rules, getting you delisted. A common clean pattern is a daily vote for a daily cosmetic, so a regular has a small reason to vote each day without ever gaining combat advantage.</p><h2>4. Deliver the reward by SteamID after the vote confirms</h2><p>The reward should only fire when the toplist confirms the vote, and it should be tied to the player's SteamID so it cannot be farmed. In practice a vote-reward plugin exposes a chat command (for example <code>say /vote</code>) that shows the player how to vote, then checks the toplist's confirmation before granting the perk to that <a href="/tutorials/find-player-steamid">SteamID</a>. Advertise the command through your <a href="/plugins/csb-adverts">adverts rotation</a> so players know it exists — a reward nobody hears about is never claimed. Do not grant the reward on the command alone without confirmation, or players collect it without ever voting and your ranking never moves.</p><h2>Common mistakes</h2><ul><li><strong>Ranking never climbs despite rewards</strong> — players get the perk without the vote actually registering. Gate the reward on the toplist's confirmation, not just the command.</li><li><strong>Server delisted from the toplist</strong> — a pay-to-win reward or vote manipulation. Strip advantage rewards to cosmetic and stop any bot voting.</li><li><strong>Nobody votes</strong> — the reward is too small or unadvertised. Make it a visible daily cosmetic and announce it on a timer.</li><li><strong>Same player farms the reward</strong> — you keyed it to name or IP instead of SteamID, or did not enforce once-per-day. Key it to SteamID and respect the toplist's daily limit.</li><li><strong>Reward unbalances the round</strong> — you gave HP or money. Voters must not be stronger than non-voters, only prettier.</li></ul><h2>Verification</h2><p>Vote for your own server from a test account, then run the in-game vote command and confirm the reward is granted only <em>after</em> the toplist shows your vote counted — if it grants before, the confirmation gate is missing and you will get farmed. Check the toplist profile a few hours later and confirm your vote registered and the position moved. Finally, verify a non-voter and a voter play an identical round: same HP, same money, same guns. If the only difference is a tag or a colour, the reward is safe and the loop can run without risking a delist.</p> | |
| 0 | 10 |
