Add 7 tutorials (7 files)
Browse Source
Daemon666 committed
parent 2b7491814c
commit 1e8ef01d18d846231e8179073a0fd7d66c28438b
7 changed files
with 76 additions and 0 deletions
A
change-server-ip-keep-players/en.md
+9 -0
A
fix-invalid-plugin-amxx/en.md
+11 -0
A
fix-nextmap-not-advancing/en.md
+11 -0
A
fix-server-freeze-mysql-query/en.md
+17 -0
A
fix-svc-bad/en.md
+10 -0
A
is-cs16-still-alive-2026/en.md
+9 -0
A
where-to-advertise-cs16-server/en.md
+9 -0
change-server-ip-keep-players/en.md
A
| @@ -0,0 +1,9 @@ | ||
| 1 | +--- | |
| 2 | +title: "Changing Your Server IP Without Losing Players" | |
| 3 | +excerpt: "How to migrate a CS 1.6 server to a new IP without losing your regulars, using a redirect on the old address, favorites, and re-registration in the master list." | |
| 4 | +category: "hosting" | |
| 5 | +tags: "migration, growth" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>Changing your server's IP — a new VPS, a new host, a DDoS-forced move — is the moment a healthy community can quietly bleed out. Players have your old IP in their favorites and their muscle memory; when it stops answering, most do not go hunting for the new one. They just play somewhere else. The migration itself is easy; keeping the people is the real task. Here is how to move the address and carry the regulars with you.</p><h2>1. Stand up the new server before touching the old one</h2><p>Never migrate by tearing down first. Build the new server fully — same mod, same configs, same maps — and get it running and listed on the new IP while the old one is still live. Copy the whole config set across so the experience is identical: <a href="/tutorials/backup-configs-bans-stats">back up configs, bans and stats</a> and restore them on the new box, including <code>csstats.dat</code> so ranks survive and <code>users.ini</code>/ban files so admins and bans carry over. A player who reconnects and finds their rank intact barely notices the move; one who finds a blank server feels like they lost their home.</p><h2>2. Turn the old IP into a signpost</h2><p>The players who will be lost are the ones who connect to the old IP and get nothing. So do not give them nothing. For as long as you control the old address, keep something there that points them onward. Two options:</p><ul><li><strong>A redirect.</strong> The cleanest is a real connection redirect that bounces a joining client to the new address automatically — this is exactly the mechanism a boosting/redirect control plane provides, sending A2S queries and connections from the old endpoint to the live one.</li><li><strong>A message.</strong> If you cannot redirect, keep a bare server on the old IP whose <code>hostname</code> is the new address, so anyone who looks sees where to go:</li></ul><pre>hostname "MOVED -> connect 203.0.113.50:27015"</pre><p>The worst outcome is a dead old IP that times out with no clue. Any signpost beats silence.</p><h2>3. Re-register in the master list</h2><p>A new IP is a new listing — the master list does not follow you. Confirm the new server appears: <code>sv_lan 0</code>, the correct ports open, and the heartbeat reaching the master, all covered in <a href="/tutorials/get-server-in-master-list">getting into the master list</a> and <a href="/tutorials/fix-server-not-in-master-list">fixing a server not in the master list</a>. Until the new IP is listed, browsers cannot find you at all, so this is not optional — a migrated server that is not in the list is invisible to everyone who did not have the direct address.</p><h2>4. Push the new address everywhere players look</h2><p>Announce the move on every channel your community uses before and after the switch: your Discord, your website, and in-game on the old server while it is still up. On the new server, run an <a href="/plugins/csb-adverts">adverts plugin</a> that repeats the connect address and your Discord in chat, so even a player who found you by luck can save the right place. Ask regulars to update their favorites — a one-time <code>connect 203.0.113.50</code> and an "add to favorites" is all it takes, and reminding them is the single highest-return thing you can do during a move.</p><h2>5. Keep the old IP alive as long as you can</h2><p>Do not release the old address the day you migrate. The redirect or signpost on it is catching your slowest-returning regulars — the person who plays once a fortnight will hit the old IP weeks later. Hold it for as long as the host allows, ideally a month or more, so the long-tail of your community funnels across. Only when connections to the old address have dried up is it safe to let it go.</p><h2>Common errors</h2><ul><li><strong>Regulars vanished after the move</strong> — the old IP went dark with no redirect or message. Always leave a signpost.</li><li><strong>New server not in the browser</strong> — it was never re-registered on the new IP. Re-check <code>sv_lan 0</code>, ports, and the heartbeat.</li><li><strong>Ranks and admins reset</strong> — you migrated configs but not <code>csstats.dat</code>, <code>users.ini</code>, or ban files. Copy the full data set.</li><li><strong>Released the old IP too soon</strong> — infrequent players still had it saved. Hold it for weeks.</li><li><strong>Announced only after the switch</strong> — players hit a dead server before they heard. Announce before, during, and after.</li></ul><h2>Verification</h2><p>Before cutting over, connect to the new IP yourself and confirm the mod, maps, ranks, and admin access all behave exactly like the old server. Search the in-game browser for your hostname and confirm the new listing is present with a healthy ping. Then test the old address the way a returning player would — connect to the old IP and confirm you are redirected or clearly told where to go, not met with a timeout. When both the new listing works and the old address funnels players forward, the migration is safe to complete.</p> |
fix-invalid-plugin-amxx/en.md
A
| @@ -0,0 +1,11 @@ | ||
| 1 | +--- | |
| 2 | +title: "Fix: 'Plugin failed to load: Invalid Plugin' (AMX Mod X)" | |
| 3 | +excerpt: "What 'Invalid Plugin' means in AMX Mod X, the version and architecture mismatch between .amxx and your AMXX build, corrupted uploads, wrong compiler, and reading amxx plugins status." | |
| 4 | +category: "errors" | |
| 5 | +tags: "amxmodx, plugins" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>AMX Mod X loads your plugin list and one line reports:</p><blockquote>Plugin failed to load: Invalid Plugin</blockquote><p>and <code>amxx plugins</code> shows it as <code>bad load</code>. "Invalid Plugin" specifically means AMX Mod X could not recognise the <code>.amxx</code> as a plugin it can run — the file is corrupt, compiled for the wrong AMXX version, or not a real <code>.amxx</code> at all. This is distinct from a plugin that loads but errors at runtime. Here is how to pin it down.</p><h2>1. Read the exact status</h2><p>Get the per-plugin verdict from the server console:</p><pre>amxx plugins</pre><p>Each plugin shows <code>running</code>, <code>paused</code>, <code>bad load</code>, or <code>debug</code>. "Invalid Plugin" corresponds to <code>bad load</code> with an invalid-format reason. Note which plugin and pair it with the load line in the AMXX log under <code>addons/amxmodx/logs/</code>, which often adds a more specific reason such as a bad file magic or version.</p><h2>2. Check the file is a real, complete .amxx</h2><p>A truncated or corrupted upload — interrupted transfer, or FTP in ASCII mode mangling a binary — produces an invalid plugin. Confirm the file has real size and is binary:</p><pre>ls -l addons/amxmodx/plugins/myplugin.amxx</pre><p>A near-zero-byte file, or a file that opens as text/HTML (you accidentally saved a web page), is invalid. Re-upload in <strong>binary</strong> mode. If you compiled it yourself, make sure you copied the <code>.amxx</code> output, not the <code>.sma</code> source — a <code>.sma</code> renamed to <code>.amxx</code> is invalid because it is Pawn text, not compiled bytecode.</p><h2>3. Match the plugin's AMXX version to your server</h2><p>A plugin compiled for a newer AMX Mod X than you run can be rejected as invalid, and one compiled for a much older branch may also fail. The safe path is to compile against the version you run — <strong>1.9</strong> is the stable default. If you downloaded a precompiled <code>.amxx</code> that will not load, recompile the <code>.sma</code> with the matching compiler. On this platform the <a href="/plugins/">plugin directory</a> compiles source on demand against pinned 1.8.2 / 1.9 / 1.10 toolchains, which sidesteps the mismatch entirely.</p><h2>4. Rule out an architecture/format mismatch</h2><p>The <code>.amxx</code> format carries a version tag AMX Mod X checks on load. If someone hand-edited the file, or it was produced by an incompatible or unofficial compiler, the tag will not match and it loads as invalid. Recompile from clean source with the official <code>amxxpc</code> for your target version rather than trusting a mystery binary.</p><h2>5. Confirm the line in plugins.ini is right</h2><p>The plugin is listed in <code>addons/amxmodx/configs/plugins.ini</code>. A line pointing at a filename that does not exist, or a stray path, produces a load failure too. Keep it to the bare filename:</p><pre>myplugin.amxx | |
| 10 | +; not a path, not myplugin.sma, not a commented mess | |
| 11 | +</pre><p>Plugins load only at map change, so after fixing the file or the line, change the map (or restart) to reload — editing on a live map changes nothing until then, as covered in <a href="/tutorials/update-plugins-live-server">updating plugins on a live server</a>.</p><h2>6. Compile against the version you run</h2><p>The cleanest way to avoid "Invalid Plugin" for good is to never ship a binary compiled for a version you do not run. If you maintain your own plugins, keep a copy of the <code>amxxpc</code> compiler that matches your server — 1.8.2, 1.9 or 1.10 — and compile there. A plugin that uses a native introduced in 1.9 (for example the coloured chat natives) will not even compile on 1.8.2, and a 1.10-compiled binary can be rejected by a 1.8.2 loader as an invalid format. Pin one AMXX version across your whole server and compile everything against it; mixing compilers is the fastest route back to this error.</p><h2>Common errors</h2><ul><li><strong><code>bad load</code> / Invalid Plugin</strong> — wrong AMXX version or a corrupt file. Recompile against your version, re-upload in binary.</li><li><strong>Renamed <code>.sma</code> to <code>.amxx</code></strong> — that is source, not bytecode. Compile it first.</li><li><strong>File is tiny or opens as text</strong> — a truncated or ASCII-mangled upload. Transfer in binary mode.</li><li><strong>Precompiled download will not load</strong> — it targets a different AMXX branch. Recompile the <code>.sma</code>.</li><li><strong>Fixed the file but nothing changed</strong> — plugins reload at map change; change the map.</li></ul><h2>Verification</h2><p>After recompiling/re-uploading and changing the map, re-check:</p><pre>amxx plugins</pre><p>The plugin should now read <code>running</code> instead of <code>bad load</code>. Cross-check the AMXX log for the load line — a clean load with no invalid-format entry confirms the fix. If it loads but then throws runtime errors, that is a different layer (a missing module or a code bug); a plugin that needs a module you lack shows as <code>bad load</code> for a different reason, addressed in the module-load troubleshooting. Test the plugin's actual feature in-game to be sure it is genuinely working, not merely listed.</p> |
fix-nextmap-not-advancing/en.md
A
| @@ -0,0 +1,11 @@ | ||
| 1 | +--- | |
| 2 | +title: "Fix: nextmap / mapcycle Not Advancing to the Next Map" | |
| 3 | +excerpt: "Why a server loops one map forever, the mp_timelimit-is-zero trap, how mapcycle.txt and the nextmap plugin decide what comes next, and pointing the engine at the right cycle file." | |
| 4 | +category: "errors" | |
| 5 | +tags: "nextmap, mapcycle" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>Your server plays the same map endlessly, or ignores the order in <code>mapcycle.txt</code> and jumps somewhere unexpected. Two separate things govern map flow and people conflate them: something has to <em>end</em> the current map, and then something has to <em>choose</em> the next one. If the map never ends, the cycle never advances no matter how perfect the file is; if the map ends but the next-map logic is wrong, it advances to the wrong place. Diagnose which half is broken before editing files.</p><h2>1. Confirm the map can even end</h2><p>A map that never ends can never advance. The clock is the usual culprit:</p><pre>mp_timelimit 30</pre><p>If <code>mp_timelimit</code> is <code>0</code> and you have no round or frag limit set, nothing tells the map to end and it loops forever — which looks exactly like a broken cycle but is not. Set a non-zero <code>mp_timelimit</code>, or a round/win limit on ReGameDLL, so there is an end event at all. The full interaction of the end-of-map limits is in <a href="/tutorials/timelimit-maxrounds-flow">the map-flow tuning guide</a>. Fix this first; the rest is moot until the map ends.</p><h2>2. Understand who picks the next map</h2><p>Once a map ends, the next one is chosen by one of two systems, and they can fight:</p><ul><li><strong>The engine's mapcycle</strong> — the engine reads <code>mapcycle.txt</code> and advances to the next entry.</li><li><strong>The AMXX nextmap plugin</strong> (<code>nextmap.amxx</code>) — it manages the next map itself, sets the <code>amx_nextmap</code> cvar, and announces "Next map:" in chat.</li></ul><p>When <code>nextmap.amxx</code> is loaded, it is the authority — it reads the mapcycle and drives the transition. If you also have a map-chooser or RTV plugin, that can override the plain cycle with a vote. Two plugins both trying to set the next map is a classic reason it jumps somewhere you did not expect.</p><h2>3. Check the mapcycle file the engine actually uses</h2><p>The engine reads the file named by the <code>mapcyclefile</code> cvar, which defaults to <code>mapcycle.txt</code> in the mod folder:</p><pre>mapcyclefile "mapcycle.txt"</pre><p>Two things break here: the cvar points at a file that does not exist (so the engine falls back and loops the current map), or the file exists but is malformed. A valid <code>mapcycle.txt</code> is one map name per line, no <code>.bsp</code> extension, and every map must exist in <code>maps/</code>:</p><pre>de_dust2 | |
| 10 | +de_inferno | |
| 11 | +cs_office</pre><p>A single-entry file loops that one map by definition. A file full of maps you do not have makes the engine skip or stall. Confirm each listed map file is present.</p><h2>4. Watch for the config that resets the map</h2><p>If the map reloads itself rather than advancing, a config executed at map start may be forcing it. Check that no <code>server.cfg</code> line, ReGameDLL config, or plugin is calling <code>changelevel</code> back to the same map, and that <code>amx_nextmap</code> is not being pinned. Read the live next map with:</p><pre>amx_nextmap</pre><p>If it shows the current map, the nextmap plugin computed the wrong target — usually because the current map is not found in the mapcycle, so the plugin defaults to repeating it.</p><h2>5. Reconcile the vote with the plain cycle</h2><p>If you run an end-of-map vote or Rock The Vote, it deliberately overrides the sequential cycle — the winning map becomes the next map regardless of what comes next in <code>mapcycle.txt</code>. That is not a bug, it is the point of the vote, but it surprises admins who expect strict file order and instead see the map players voted for. Two consequences to hold in mind: the vote is scheduled off <code>mp_timelimit</code>, so a purely round-based flow with <code>mp_timelimit 0</code> gives it nothing to hook onto and it never appears; and if two plugins both try to set the next map, the last one to run wins and the result looks random. Decide which system owns the next-map decision — the plain engine cycle, the nextmap plugin, or a vote — and do not run two that fight. The timing details are in <a href="/tutorials/timelimit-maxrounds-flow">the map-flow guide</a>.</p><h2>Troubleshooting</h2><ul><li><strong>Same map forever, no end at all</strong> — <code>mp_timelimit 0</code> with no other limit. Set a limit so the map ends.</li><li><strong>Map ends but repeats itself</strong> — the current map is not listed in <code>mapcycle.txt</code>, so the nextmap logic falls back to it. Add it to the cycle.</li><li><strong>Advances but ignores your order</strong> — an RTV/map-chooser plugin is overriding the plain cycle with a vote. That is expected; configure the chooser, not the file.</li><li><strong>Cycle file edits do nothing</strong> — <code>mapcyclefile</code> points at a different file, or the file is read only at map end. Check the cvar and change the map.</li><li><strong>Skips maps</strong> — listed maps are missing from <code>maps/</code>; the engine passes over what it cannot load.</li></ul><h2>Verification</h2><p>Set a short limit on a test server — <code>mp_timelimit 2</code> — put three known-present maps in <code>mapcycle.txt</code>, and let it run. Confirm the map ends on time and advances to the second entry, then the third, then wraps. Read <code>amx_nextmap</code> mid-map and confirm it names the next entry, not the current one. If the ends and the order both behave, both halves — ending and choosing — are correct. Restore your real <code>mp_timelimit</code> once the flow is proven.</p> |
fix-server-freeze-mysql-query/en.md
A
| @@ -0,0 +1,17 @@ | ||
| 1 | +--- | |
| 2 | +title: "Fix: Server Freezes When a Plugin Queries MySQL (Blocking Queries)" | |
| 3 | +excerpt: "Why the whole server stalls the instant a plugin touches MySQL, the difference between blocking and threaded SQLX queries, how SQL_ThreadQuery avoids the freeze, and how to spot the offending plugin." | |
| 4 | +category: "errors" | |
| 5 | +tags: "mysql, sqlx" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>Every time a particular plugin talks to MySQL — a player connects and it loads their VIP status, someone types a command that reads the database — the entire server freezes for a moment: everyone lags, then it resumes. This is not a network problem and not the database being slow in isolation; it is a plugin running a <strong>blocking</strong> query on the main game thread. GoldSrc is single-threaded, so while the engine waits for MySQL to answer, it cannot simulate anything else. Here is why it happens and how to fix it properly.</p><h2>1. Understand the single-threaded stall</h2><p>The CS 1.6 engine runs the game world on one thread. When a plugin calls a blocking SQL function, that thread stops and waits for the database round-trip to complete. If the database is on another host, or under load, or the query is slow, that wait can be tens or hundreds of milliseconds — and for that entire time nothing moves in game. The freeze length equals the query time. A fast local query barely shows; a slow or remote one produces a visible, whole-server hitch.</p><h2>2. Know the two SQLX query styles</h2><p>The AMX Mod X <code>sqlx</code> module offers two ways to run a query, and the difference is the whole issue:</p><ul><li><strong>Blocking</strong> — <code>SQL_Execute</code> on a prepared query runs on the main thread and the engine waits. Simple to write, but it freezes the server for the query's duration.</li><li><strong>Threaded</strong> — <code>SQL_ThreadQuery</code> hands the query to a background thread and calls your handler when the result is ready, without stalling the game. This is the correct choice for anything touching a networked or non-trivial database.</li></ul><p>A plugin that uses blocking queries in a per-player or per-command path is the classic cause of the freeze. The fix is to use threaded queries.</p><h2>3. Convert to threaded queries</h2><p>The threaded pattern registers a callback that receives the result later. In Pawn it looks like this:</p><pre>SQL_ThreadQuery(g_hTuple, "query_handler", "SELECT flags FROM vips WHERE steamid = '%s'", steamid) | |
| 10 | + | |
| 11 | +public query_handler(failstate, Handle:query, error[], errcode, data[], size, Float:queuetime) { | |
| 12 | + if (failstate != TQUERY_SUCCESS) { | |
| 13 | + log_amx("SQL error %d: %s", errcode, error) | |
| 14 | + return | |
| 15 | + } | |
| 16 | + // read rows from query here, no server freeze | |
| 17 | +}</pre><p>The engine keeps simulating while MySQL works, and your handler runs when the answer arrives. If you wrote the plugin, replace every <code>SQL_Execute</code> in a gameplay path with <code>SQL_ThreadQuery</code>. If it is a third-party plugin, this is why it freezes and why you should replace it with one that uses threaded queries — a maintained plugin such as the <a href="/plugins/csb-vip-core">CSB VIP Core</a> does its database work off the main thread.</p><h2>4. Reduce the query cost too</h2><p>Threading hides the latency but does not excuse a bad schema. Make the queries cheap so even the background thread returns fast and connections do not pile up:</p><ul><li>Index the columns you filter on — a <code>SELECT ... WHERE steamid = ?</code> against an unindexed column scans the whole table.</li><li>Cache per-player data in memory on connect and write back on disconnect, rather than querying every action.</li><li>Keep the database close — a MySQL host across the internet turns every query into a slow round-trip. Run it on the same box or LAN.</li></ul><h2>5. Find which plugin is doing it</h2><p>If you do not know which plugin freezes the server, correlate the hitch with events. The freeze on <em>player connect</em> points at a plugin loading data on connect; on a <em>chat command</em> points at that command's handler. Pause suspects one at a time and watch whether the freeze disappears:</p><pre>amxx pause suspect.amxx</pre><p>When the freeze stops after pausing a specific plugin, that plugin's blocking query is the cause. The same pausing technique isolates FPS-draining plugins in <a href="/tutorials/fix-server-fps-drops-with-players">the server FPS guide</a>.</p><h2>Troubleshooting</h2><ul><li><strong>Freeze exactly when a player connects</strong> — a plugin runs a blocking query on connect. Convert it to <code>SQL_ThreadQuery</code>.</li><li><strong>Freeze on a specific chat command</strong> — that command's handler blocks on SQL. Thread it or cache the data.</li><li><strong>Freezes got worse over time</strong> — the table grew and unindexed queries got slower. Add indexes.</li><li><strong>Freezes only when the DB is remote</strong> — network latency per query. Move MySQL local or cache aggressively.</li><li><strong><code>SQL error</code> in logs plus a hang</strong> — the plugin is retrying a failing blocking query, stalling each time. Fix the connection and thread the query.</li><li><strong>Intermittent long freezes under load</strong> — blocking queries queuing behind each other on the main thread. Threaded queries remove the serialization.</li></ul><h2>Verification</h2><p>After moving the plugin to threaded queries, reproduce the trigger — have players connect rapidly, or spam the command — while watching <code>stats</code> in the console. The server FPS should stay steady with no hitch, because the main thread never waits on MySQL. Confirm the data still loads correctly (VIP flags apply, stats save) proving the threaded handler runs. If the freeze is gone and the data is right, the conversion worked. If a residual freeze remains, another plugin still uses blocking queries — pause them one at a time until the last hitch disappears.</p> |
fix-svc-bad/en.md
A
| @@ -0,0 +1,10 @@ | ||
| 1 | +--- | |
| 2 | +title: "Fix: 'SVC_BAD' Kicking Players Off the Server" | |
| 3 | +excerpt: "What the SVC_BAD network error means, why a plugin writing malformed messages is almost always the cause, and how to find and disable the offending plugin." | |
| 4 | +category: "errors" | |
| 5 | +tags: "svc_bad, netcode" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>Players drop with <code>SVC_BAD</code> in the console, sometimes in bursts, sometimes tied to a specific event like a round end or a HUD element appearing. <code>SVC_BAD</code> is the client saying it received a network message it could not parse — the byte stream from the server did not match a valid message type. On CS 1.6 this is almost never the engine's fault and almost always a plugin writing a malformed message. This is how to trace it.</p><h2>1. Understand what SVC_BAD is</h2><p>The server sends the client a stream of typed messages (SVC = server-to-client). Each has a defined structure. When a plugin builds a custom message with the engine message functions and gets the structure wrong — a mismatched begin/end, the wrong argument type, too many or too few writes, an out-of-range value — the following bytes desynchronise and the client reads garbage where the next message header should be. It reports <code>SVC_BAD</code> and disconnects because it can no longer trust the stream. So the trigger is a <em>malformed message</em>, and the source is whatever code built it.</p><h2>2. Correlate the drops with an event</h2><p>SVC_BAD tied to a moment is a huge clue. Note exactly <em>when</em> players drop:</p><ul><li>On <strong>round start/end</strong> → a round-based plugin (round sounds, HUD, money display).</li><li>When a <strong>HUD element or menu appears</strong> → a plugin drawing HUD or menus with raw messages.</li><li>On <strong>spawn</strong> or a <strong>model change</strong> → a models/skins plugin.</li><li>On a <strong>chat command</strong> → whatever plugin handles it.</li></ul><p>The event points straight at a category of plugin. A plugin misusing <code>message_begin</code>/<code>message_end</code>, writing with the wrong <code>write_byte</code>/<code>write_short</code>/<code>write_long</code> type, or sending a bad <code>SendAudio</code>/HUD message is the usual culprit.</p><h2>3. Bisect the plugin list</h2><p>Turn the correlation into a definite answer by disabling plugins and watching the error. In <a href="/tutorials/plugins-ini-load-order">plugins.ini</a>, comment out the suspect category first, change map, and see if SVC_BAD stops:</p><pre>; buggy_hud.amxx | |
| 10 | +; custom_models.amxx</pre><p>If disabling one plugin stops the drops, you have your offender. If the category guess was wrong, bisect the whole list — disable the bottom half, test, then narrow. Because SVC_BAD is deterministic (the same bad message fails every time), this converges fast.</p><h2>4. Replace or fix the offending plugin</h2><p>Once identified, you have two paths. If it is a third-party plugin, replace it with a maintained equivalent — a properly written HUD or models plugin from the <a href="/plugins/csb-admin-menu">plugin directory</a> constructs its network messages correctly and will not corrupt the stream. If it is your own plugin, audit the message code: every <code>message_begin</code> must have a matching <code>message_end</code>, every write must use the correct width for the message argument, and values must be in range. A single stray <code>write_byte</code> or a message sent to a disconnected/invalid client index can be enough to produce SVC_BAD. Never build a message to an invalid <code>id</code>.</p><h2>5. Rule out the rarer causes</h2><p>If no plugin is responsible, consider:</p><ul><li><strong>A corrupt or mismatched game DLL</strong> — a broken ReGameDLL or a mismatch between engine and mod can emit bad messages. Reinstall/align the <a href="/tutorials/install-regamedll-cs16">ReGameDLL</a> and engine versions.</li><li><strong>A bad Metamod plugin</strong> operating at the network layer — disable Metamod plugins as well as AMXX ones.</li><li><strong>Genuinely severe packet loss</strong> — extreme loss/corruption on the wire can occasionally surface as SVC_BAD for one player, but a whole-server pattern is code, not the network.</li></ul><h2>Troubleshooting</h2><ul><li><strong>Drops always on the same event</strong> — the plugin handling that event builds a bad message. Disable that plugin category first.</li><li><strong>Only one player drops on SVC_BAD</strong> — could be that client's link; a server-wide pattern is a plugin.</li><li><strong>Stops when a plugin is disabled</strong> — that is the offender. Replace it or fix its message code.</li><li><strong>No plugin responsible</strong> — suspect a mismatched engine/mod DLL or a Metamod-level plugin.</li><li><strong>Returns after you re-enable a "fixed" plugin</strong> — the message bug is still there; audit <code>message_begin</code>/<code>message_end</code> pairing and write widths.</li></ul><h2>Verification</h2><p>After disabling or fixing the offender, reproduce the exact event that used to trigger the drops — force a round end, open the HUD, run the chat command — several times with players connected, and confirm nobody gets <code>SVC_BAD</code>. Because the fault is deterministic, a handful of clean repetitions of the previously-failing action is strong proof. Re-enable your other plugins one map at a time to make sure none of them reintroduces it, and keep the offending plugin out of <code>plugins.ini</code> until it is genuinely fixed rather than just suspected.</p> |
is-cs16-still-alive-2026/en.md
A
| @@ -0,0 +1,9 @@ | ||
| 1 | +--- | |
| 2 | +title: "Is CS 1.6 Still Alive in 2026? (Real Player Numbers)" | |
| 3 | +excerpt: "An honest look at where CS 1.6's remaining population actually is in 2026, why the numbers are hard to count, which regions and mods still thrive, and what that means if you want to run a server." | |
| 4 | +category: "hosting" | |
| 5 | +tags: "stats, community" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>"Is CS 1.6 dead?" is the wrong question — the right one is "where are the players, and can I reach them?" A game from 2003 obviously is not at its peak, but CS 1.6 in 2026 is not a graveyard either; it is a smaller, concentrated, regionally-skewed population that is very much reachable if you go where it lives. This is an honest read of the numbers and what they mean for running a server.</p><h2>1. Why the numbers are hard to count</h2><p>There is no single authoritative player count, and anyone who quotes one precise figure is guessing. The reasons are structural:</p><ul><li><strong>Non-Steam is huge and invisible.</strong> A large share of CS 1.6 play happens on non-Steam clients that never touch Steam's concurrent-user stats. Steam charts capture only a slice.</li><li><strong>Players cluster on a few busy servers</strong> rather than spreading evenly, so "servers online" understates activity.</li><li><strong>Bots and padding inflate listings</strong>, so raw player counts on monitors are not all real (<a href="/tutorials/fake-players-bot-padding">fake players and bot padding</a>).</li></ul><p>The honest summary: the population is real and non-trivial, but no one number captures it, and the Steam-only figure badly undercounts it.</p><h2>2. Where the players actually are</h2><p>The remaining population is heavily regional. The <strong>CIS region</strong> (Russia, Ukraine, and neighbours) is the largest concentration, followed by pockets in <strong>Latin America</strong>, the <strong>Balkans</strong>, the <strong>Middle East</strong>, and parts of Asia. These communities skew heavily non-Steam, which is exactly why they are invisible to Steam stats and why they matter to you: they are underserved and reachable. If you speak a regional language or can run a server in a regional datacentre, you are aiming at where the players concentrate, not at the thin, saturated Western vanilla scene.</p><h2>3. Which modes still thrive</h2><p>Population is not spread evenly across game types. The consistently busy categories in 2026 are:</p><ul><li><strong>Zombie mods</strong> — Zombie Plague and its descendants remain the single biggest draw (<a href="/tutorials/install-zombie-plague-mod">installing Zombie Plague</a>).</li><li><strong>Public classic and DM</strong> — dust2-only, CSDM, and gungame publics.</li><li><strong>Regional favourites</strong> — specific mods that own a language community.</li></ul><p>Vanilla competitive 5v5 has largely migrated to CS2 and other titles; chasing that audience on 1.6 is fighting the current. Pick where the players are with <a href="/tutorials/pick-a-mod-with-players">picking a mod with players</a>.</p><h2>4. What this means for running a server</h2><p>The population reality dictates strategy. You will not fill a generic English vanilla pub — that audience is gone. You <em>can</em> fill a well-run mod server aimed at a live community: a zombie server in a busy region, a mod with a language niche, a server that seeds reliably. The market is smaller but far less crowded at the top than it looks, because most new servers are generic and empty. Support non-Steam properly (<a href="/tutorials/steam-vs-nonsteam-servers">Steam vs non-Steam servers</a>) or you exclude the majority of the remaining players.</p><h2>5. The realistic outlook</h2><p>CS 1.6 has been "dying" for fifteen years and is still here, sustained by non-Steam accessibility, low hardware requirements, deep mod culture, and regional loyalty. It is not growing, but it is stable enough that a server started in 2026 can absolutely reach a self-sustaining core — if it goes to the players rather than waiting for them. The playbook for that is <a href="/tutorials/get-players-on-new-server">getting players onto a new server</a> and <a href="/tutorials/first-30-regulars-playbook">the first-30-regulars playbook</a>.</p><h2>Common misconceptions</h2><ul><li><strong>"Steam shows only X players, so it's dead"</strong> — Steam misses the large non-Steam population; the real figure is much higher.</li><li><strong>"There are thousands of servers, it's thriving"</strong> — many are empty or padded. Count real activity, not listings.</li><li><strong>"I'll run vanilla competitive and they'll come"</strong> — that audience left for CS2. Run a mod with a living community instead.</li><li><strong>"Region doesn't matter"</strong> — it is the single biggest factor. Aim at a concentrated regional population.</li><li><strong>"Non-Steam is a minor detail"</strong> — it is the majority of the remaining players; supporting it is not optional.</li></ul><h2>Verification</h2><p>Check reality yourself instead of trusting one statistic. Open a monitoring site during a regional evening peak and count servers that are genuinely full (real churn, not flat padded counts). Note which mods and regions dominate the busy list — that is your target market, evidenced rather than assumed. If the busiest servers are zombie and regional publics with dozens of real players, that is proof both that the game is alive and where to point your own server. Then commit to that niche rather than the empty vanilla one.</p> |
where-to-advertise-cs16-server/en.md
A
| @@ -0,0 +1,9 @@ | ||
| 1 | +--- | |
| 2 | +title: "Where to Advertise a CS 1.6 Server (Forums, Discords and Toplists)" | |
| 3 | +excerpt: "The channels that actually bring CS 1.6 players to a new server: community forums, Discord, toplists and trackers, and how to post the connect link so it converts instead of getting deleted." | |
| 4 | +category: "hosting" | |
| 5 | +tags: "marketing, growth" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>A new server is invisible. The in-game browser buries an empty server under the full ones, so nobody discovers you by chance — you have to go where CS 1.6 players already gather and put your connect link in front of them. This is a channel-by-channel guide to the places that still bring real players in 2026, and how to post so you convert clicks instead of getting your thread deleted for spam.</p><h2>1. Have your connect link ready first</h2><p>Every channel needs the same thing: a link that turns a reader into a player in one click. Prepare both the clickable Steam URL and the raw console line before you post anywhere:</p><pre>steam://connect/203.0.113.10:27015</pre><pre>connect 203.0.113.10:27015</pre><p>Use the literal IP and port (default <strong>27015</strong>), not a hostname that may not resolve. See <a href="/tutorials/cs16-connect-via-console">connecting via console</a> for the client side and <a href="/tutorials/server-banners-signatures">banners and signatures</a> for wrapping the link in a live image.</p><h2>2. CS 1.6 community forums</h2><p>The scene still runs on forums — general CS 1.6 communities, mod-specific boards (Zombie, GunGame), and regional-language sites. Most have a "server advertising" or "promote your server" section; post there, not in random threads, or you get removed. A good post has the mode and region in the title, a short description of what makes the server worth joining, your <a href="/tutorials/server-banners-signatures">live banner</a> image, and the connect link. Then set the banner as your forum signature so every normal post you make also advertises the server passively.</p><h2>3. Discord</h2><p>Discord is where active communities live now. Two moves: run your <em>own</em> server Discord (put its invite in the <a href="/tutorials/motd-txt-html-guide">MOTD</a> and adverts so in-game players join it, which gives you a place to announce events and rally regulars at <a href="/tutorials/track-player-counts-peak-hours">peak hours</a>), and post in <em>other</em> CS 1.6 Discords that allow server promotion in their designated channel. A <a href="/tutorials/discord-rcon-bot">Discord RCON/status bot</a> that shows your live player count in your own server keeps members aware of when it is busy. Respect each server's promo rules — posting your link in general chat gets you banned fast.</p><h2>4. Toplists and trackers</h2><p>Register on a server toplist and a tracker that have real CS 1.6 traffic in your region. The tracker gives you a profile page and banner; the toplist gives you a ranking you can climb with <a href="/tutorials/vote-rewards-toplists">vote rewards</a>. Both are passive discovery — people browsing those sites for a server find yours without you posting anything further. This is the highest-leverage channel because it works while you sleep, and it compounds as your rank rises.</p><h2>5. Match the channel to your region and language</h2><p>Where you post must match who you can host for. A server aimed at a Brazilian or Russian audience advertises on that region's forums and Discords in that language; an English-only post on a foreign-language board converts poorly. Line this up with your <a href="/tutorials/popular-mods-by-region">regional mode choice</a> — advertise the mode that region plays, in the language it speaks, on the sites it uses.</p><h2>Common mistakes</h2><ul><li><strong>Posts get deleted or you get banned</strong> — you advertised outside the designated section. Use the promo channel every community provides, and read its rules first.</li><li><strong>Clicks but no joins</strong> — a broken connect link (hostname instead of IP, wrong port) or the server was empty when they arrived. Use the literal IP and seed the server before a push.</li><li><strong>No response at all</strong> — wrong audience: an English post on a region-locked board, or a Zombie ad on a competitive forum. Match channel, region and mode.</li><li><strong>One-time spike then nothing</strong> — you relied on a single forum burst. Passive channels (toplist rank, banner signature, tracker) sustain traffic; posts are one-offs.</li><li><strong>Advertising an unfinished server</strong> — driving traffic to a laggy or empty server wastes the click and burns the impression. Fix <a href="/tutorials/player-retention-cs16">retention</a> first, then advertise.</li></ul><h2>Verification</h2><p>Click your own posted link from a machine with CS installed and confirm it launches and joins the correct server — a link that does not connect wastes every impression. Then advertise on one channel at a time and watch your <a href="/tutorials/track-player-counts-peak-hours">player-count log</a> for the hours after: a real channel produces a visible bump. Keep the channels that move the count and drop the ones that do nothing. The winning pattern is a couple of passive channels (toplist rank plus a banner signature) that feed players continuously, topped up with occasional forum and Discord posts when you have something new to announce.</p> | |
| 0 | 10 |
