Add 4 tutorials (4 files)
Browse Source
Daemon666 committed
parent a91fcd6eda
commit 026687c8f2baa3a12fda61696edb6a8e2a1b1f57
4 changed files
with 203 additions and 0 deletions
A
amxx-admin-flags-reference/en.md
+75 -0
A
amxx-cfg-explained/en.md
+63 -0
A
cs16-fps-boost-guide/en.md
+15 -0
A
get-players-on-new-server/en.md
+50 -0
amxx-admin-flags-reference/en.md
A
| @@ -0,0 +1,75 @@ | ||
| 1 | +--- | |
| 2 | +title: "AMX Mod X Admin Flags (a-z): Full Reference" | |
| 3 | +excerpt: "The complete AMX Mod X access flag table from a to z, what each flag actually unlocks, common role presets, and how flags map to commands." | |
| 4 | +category: "administration" | |
| 5 | +tags: "flags, admin" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>AMX Mod X access control is a single string of lowercase letters. Each letter unlocks a category of commands, and a plugin decides which flag its command requires. This is the full <code>a</code>-<code>z</code> reference exactly as the flags are defined in AMXX, plus the role presets most servers actually use. Keep this next to your <a href="/tutorials/users-ini-explained">users.ini</a>.</p> | |
| 10 | + | |
| 11 | +<h2>1. The complete flag table</h2> | |
| 12 | +<table> | |
| 13 | +<thead><tr><th>Flag</th><th>Unlocks</th></tr></thead> | |
| 14 | +<tbody> | |
| 15 | +<tr><td><code>a</code></td><td>Immunity — cannot be kicked, banned, slayed or slapped by other admins</td></tr> | |
| 16 | +<tr><td><code>b</code></td><td>Reservation — can join a full server on a reserved slot</td></tr> | |
| 17 | +<tr><td><code>c</code></td><td><code>amx_kick</code></td></tr> | |
| 18 | +<tr><td><code>d</code></td><td><code>amx_ban</code>, <code>amx_banip</code>, <code>amx_unban</code>, <code>amx_addban</code></td></tr> | |
| 19 | +<tr><td><code>e</code></td><td><code>amx_slay</code>, <code>amx_slap</code></td></tr> | |
| 20 | +<tr><td><code>f</code></td><td><code>amx_map</code> (change map)</td></tr> | |
| 21 | +<tr><td><code>g</code></td><td><code>amx_cvar</code> — change server cvars (not all are exposed)</td></tr> | |
| 22 | +<tr><td><code>h</code></td><td><code>amx_cfg</code> — execute config files</td></tr> | |
| 23 | +<tr><td><code>i</code></td><td><code>amx_chat</code> and other admin chat commands</td></tr> | |
| 24 | +<tr><td><code>j</code></td><td><code>amx_vote</code> and vote commands</td></tr> | |
| 25 | +<tr><td><code>k</code></td><td>Access to the <code>sv_password</code> cvar (through <code>amx_cvar</code>)</td></tr> | |
| 26 | +<tr><td><code>l</code></td><td><code>amx_rcon</code> and rcon menu access</td></tr> | |
| 27 | +<tr><td><code>m</code></td><td>Custom level A (for additional plugins)</td></tr> | |
| 28 | +<tr><td><code>n</code></td><td>Custom level B</td></tr> | |
| 29 | +<tr><td><code>o</code></td><td>Custom level C</td></tr> | |
| 30 | +<tr><td><code>p</code></td><td>Custom level D</td></tr> | |
| 31 | +<tr><td><code>q</code></td><td>Custom level E</td></tr> | |
| 32 | +<tr><td><code>r</code></td><td>Custom level F</td></tr> | |
| 33 | +<tr><td><code>s</code></td><td>Custom level G</td></tr> | |
| 34 | +<tr><td><code>t</code></td><td>Custom level H (commonly used for VIP)</td></tr> | |
| 35 | +<tr><td><code>u</code></td><td>Menu access (<code>amx_menu</code> and admin menus)</td></tr> | |
| 36 | +<tr><td><code>z</code></td><td>User — no admin access at all</td></tr> | |
| 37 | +</tbody> | |
| 38 | +</table> | |
| 39 | +<p>There is no <code>v</code>, <code>w</code>, <code>x</code> or <code>y</code> in the standard set. The custom levels <code>m</code>-<code>t</code> are yours: a plugin author picks one and documents it, which is how VIP systems (see <a href="/tutorials/build-vip-plugin">building a VIP plugin</a>) attach to flag <code>t</code>.</p> | |
| 40 | + | |
| 41 | +<h2>2. How a flag becomes a command</h2> | |
| 42 | +<p>When a plugin registers a command it names the required flag:</p> | |
| 43 | +<pre>register_concmd("amx_kick", "cmd_kick", ADMIN_KICK) // ADMIN_KICK == flag c</pre> | |
| 44 | +<p>The constants map one to one: <code>ADMIN_IMMUNITY</code> = <code>a</code>, <code>ADMIN_RESERVATION</code> = <code>b</code>, <code>ADMIN_KICK</code> = <code>c</code>, <code>ADMIN_BAN</code> = <code>d</code>, <code>ADMIN_SLAY</code> = <code>e</code>, <code>ADMIN_MAP</code> = <code>f</code>, <code>ADMIN_CVAR</code> = <code>g</code>, up through <code>ADMIN_LEVEL_A</code>-<code>H</code> (<code>m</code>-<code>t</code>), <code>ADMIN_MENU</code> = <code>u</code> and <code>ADMIN_USER</code> = <code>z</code>. So the flags you grant in users.ini line up exactly with the constants plugin authors use.</p> | |
| 45 | +<p>At runtime a plugin reads a player's flags as a bitmask and tests the one it cares about:</p> | |
| 46 | +<pre>if (get_user_flags(id) & ADMIN_BAN) { | |
| 47 | + // player has flag d | |
| 48 | +}</pre> | |
| 49 | +<p>This is why flags stack freely — <code>cdef</code> is just four bits set at once. It is also why a plugin author can convert a string to a mask with <code>read_flags("t")</code> and store it, the approach used when a plugin exposes its own <code>_access</code> cvar so admins can rebind which flag a command needs.</p> | |
| 50 | + | |
| 51 | +<h2>3. Reading and rebinding a command's flag</h2> | |
| 52 | +<p>Well-written plugins do not hard-code the flag; they expose a cvar, so you can change the requirement without recompiling. For example a plugin might register <code>amx_slay</code> against a cvar defaulting to <code>e</code>. Check a plugin's <code>.cfg</code> or its documented cvars before assuming a command's flag — two servers can require different flags for the same command name. When in doubt, the AMXX console command <code>amx_help</code> lists the commands available to <em>you</em> given your current flags, which is the quickest way to see the effective mapping on a live server.</p> | |
| 53 | + | |
| 54 | +<h2>4. Practical role presets</h2> | |
| 55 | +<ul> | |
| 56 | +<li><strong>Full admin / owner</strong>: <code>abcdefghijklmnopqrstu</code> — everything except <code>z</code>.</li> | |
| 57 | +<li><strong>Head admin (no rcon)</strong>: <code>abcdefgijkmnopqrstu</code> — drop <code>l</code> so they cannot run raw rcon.</li> | |
| 58 | +<li><strong>Moderator</strong>: <code>cdefiju</code> — kick, ban, slay/slap, chat, vote, menu. No immunity, no cvars.</li> | |
| 59 | +<li><strong>Trial mod</strong>: <code>ceu</code> — kick and slay/slap through the menu only.</li> | |
| 60 | +<li><strong>VIP</strong>: <code>bt</code> — reserved slot plus custom level H, no admin commands.</li> | |
| 61 | +<li><strong>Reserved slot only</strong>: <code>b</code>.</li> | |
| 62 | +</ul> | |
| 63 | +<p>Give <code>a</code> (immunity) sparingly. An immune troublemaker cannot be removed by your other admins, only by someone with console/rcon.</p> | |
| 64 | + | |
| 65 | +<h2>Common errors</h2> | |
| 66 | +<ul> | |
| 67 | +<li><strong>Granting <code>z</code> and expecting admin power</strong> — <code>z</code> is explicitly "no access". It is used to register a user without privileges, not to grant them.</li> | |
| 68 | +<li><strong>Forgetting <code>u</code></strong> — an admin with kick/ban flags but no <code>u</code> cannot open <code>amx_menu</code>; they must type commands in console. Add <code>u</code> for anyone who should use the menu.</li> | |
| 69 | +<li><strong>Confusing flag <code>l</code> with rcon_password</strong> — flag <code>l</code> grants <code>amx_rcon</code> (send commands through AMXX). It is not the engine <code>rcon_password</code>; see <a href="/tutorials/rcon-setup-secure">RCON setup</a>.</li> | |
| 70 | +<li><strong>Custom-level collision</strong> — two plugins both claiming flag <code>t</code> will both react to it. Check each plugin's docs before reusing <code>m</code>-<code>t</code>.</li> | |
| 71 | +<li><strong>Immunity abused</strong> — a moderator with <code>a</code> cannot be disciplined by peers. Reserve <code>a</code> for trusted senior staff.</li> | |
| 72 | +</ul> | |
| 73 | + | |
| 74 | +<h2>Verification</h2> | |
| 75 | +<p>Assign a preset in users.ini, run <code>amx_reloadadmins</code>, reconnect, and check <code>amx_who</code> — it lists each online player with their resolved flag string. Then test one command from the granted set and one from a set you deliberately withheld: the withheld command should answer <code>You have no access to that command</code>. That negative test is what proves the flags are doing their job. For placing these flags correctly, return to <a href="/tutorials/users-ini-explained">users.ini explained</a>.</p> |
amxx-cfg-explained/en.md
A
| @@ -0,0 +1,63 @@ | ||
| 1 | +--- | |
| 2 | +title: "amxx.cfg: Every Setting Explained" | |
| 3 | +excerpt: "A practical walkthrough of addons/amxmodx/configs/amxx.cfg: access control, admin activity visibility, flood control, intro messages and the cvars worth changing." | |
| 4 | +category: "administration" | |
| 5 | +tags: "amxx.cfg, config" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p><code>addons/amxmodx/configs/amxx.cfg</code> is the core config AMX Mod X executes as it loads, before your plugins settle in. It controls who has access, how much of admin activity players see, flood protection, and the built-in message plugins. Most admins skim it once and never touch it again — but a handful of these cvars decide whether your server feels tight or chaotic, so they are worth understanding line by line.</p> | |
| 10 | + | |
| 11 | +<h2>1. When and where it runs</h2> | |
| 12 | +<p>The file lives at <code>cstrike/addons/amxmodx/configs/amxx.cfg</code> and is executed by the AMXX core at startup, after <code>server.cfg</code> in practice. Because it runs late, a cvar set here overrides the same cvar set in <code>server.cfg</code>. Keep AMXX-specific settings here and engine/gameplay settings in <a href="/tutorials/setup-server-cfg-cs16">server.cfg</a> so you always know which file owns which value.</p> | |
| 13 | + | |
| 14 | +<h2>2. Access control cvars</h2> | |
| 15 | +<pre>amx_default_access "" // flags given to EVERY player; keep empty | |
| 16 | +amx_mode 1 // 1 = admins only load from users.ini | |
| 17 | +amx_password_field "_pw" // setinfo field clients use for password auth | |
| 18 | +amx_vote_ratio 0.02 | |
| 19 | +amx_vote_time 10</pre> | |
| 20 | +<p><strong>Leave <code>amx_default_access</code> empty.</strong> Putting a flag here grants it to everyone on the server, which is how people accidentally hand admin commands to the public. Admin identities and their flags live in <code>configs/users.ini</code>, not here; this file only sets the machinery. <code>amx_password_field</code> is the client <code>setinfo</code> key used when an admin entry authenticates by password rather than SteamID — if you change it, your password admins must change their <code>setinfo</code> to match.</p> | |
| 21 | + | |
| 22 | +<h2>3. Admin activity visibility</h2> | |
| 23 | +<pre>amx_show_activity 2</pre> | |
| 24 | +<p>This governs what players see when an admin acts (ban, slap, kick). The values:</p> | |
| 25 | +<ul> | |
| 26 | +<li><code>0</code> — nobody is told.</li> | |
| 27 | +<li><code>1</code> — players see the action but not the admin's name.</li> | |
| 28 | +<li><code>2</code> — players see the action and the admin's name.</li> | |
| 29 | +<li><code>3</code>–<code>5</code> — variants that show admins more detail than regular players.</li> | |
| 30 | +</ul> | |
| 31 | +<p>On a public server <code>2</code> is the honest default; hiding admin actions entirely (<code>0</code>) breeds accusations you cannot answer. If you run a menu-driven admin workflow, pair this with the <a href="/plugins/csb-admin-menu">CSB Admin Menu</a>.</p> | |
| 32 | + | |
| 33 | +<h2>4. Flood control</h2> | |
| 34 | +<pre>amx_flood_time 0.75</pre> | |
| 35 | +<p>The minimum seconds between chat messages from one client before the anti-flood plugin throttles them. Lower it and chat spam gets through; raise it too far and normal fast chat gets blocked. <code>0.75</code> is a reasonable balance. For heavier spam and bind abuse, a dedicated <a href="/plugins/csb-anti-flood">anti-flood plugin</a> gives you more control.</p> | |
| 36 | + | |
| 37 | +<h2>5. Intro and scrolling messages</h2> | |
| 38 | +<p>AMXX ships small presentation plugins configured here:</p> | |
| 39 | +<pre>amx_scrollmsg "Welcome to %hostname% -- have fun" 600 | |
| 40 | +amx_imessage "Welcome to %hostname%" "0 255 0" | |
| 41 | +amx_imessage "Powered by AMX Mod X" "0 100 200" | |
| 42 | +amx_freq_imessage 180</pre> | |
| 43 | +<p><code>amx_scrollmsg</code> is the scrolling HUD banner and its refresh interval. <code>amx_imessage</code> lines are the center-screen intro messages that rotate, with an RGB color per line, and <code>amx_freq_imessage</code> is how often they cycle. Keep these short and few — a busy HUD is noise. Many admins disable these in favor of a chat-based <a href="/plugins/csb-adverts">adverts plugin</a>.</p> | |
| 44 | + | |
| 45 | +<h2>6. Logging and language</h2> | |
| 46 | +<pre>amx_logging 1 // 1 = per-map AMXX log files under addons/amxmodx/logs | |
| 47 | +amx_language "en" // default language for multilingual plugins | |
| 48 | +amx_mldebug "" // list plugins to debug for missing translations</pre> | |
| 49 | +<p>Leave <code>amx_logging</code> on — the AMXX logs are where plugin run-time errors surface, and you will want them when something misbehaves. <code>amx_language</code> only affects plugins that use the multilingual system; it does not translate everything.</p> | |
| 50 | + | |
| 51 | +<h2>Common errors</h2> | |
| 52 | +<ul> | |
| 53 | +<li><strong>Everyone suddenly has admin</strong> — a flag was left in <code>amx_default_access</code>. Set it back to <code>""</code>.</li> | |
| 54 | +<li><strong>Password admins can no longer authenticate</strong> — <code>amx_password_field</code> was changed but the admins' <code>setinfo</code> was not, or vice-versa. The two must match.</li> | |
| 55 | +<li><strong>Admin actions are invisible and players complain</strong> — <code>amx_show_activity 0</code>. Raise it to <code>1</code> or <code>2</code>.</li> | |
| 56 | +<li><strong>Settings here get overridden</strong> — you also set the same cvar in a plugin config or <code>mapchangecfgfile</code> that runs later. Trace the execution order.</li> | |
| 57 | +<li><strong>Edits do nothing</strong> — you edited a different <code>amxx.cfg</code> (there is only one that matters, under <code>addons/amxmodx/configs/</code>), or the change needs a map change / restart to re-execute.</li> | |
| 58 | +</ul> | |
| 59 | + | |
| 60 | +<h2>Verification</h2> | |
| 61 | +<p>Change one value, restart or change the map, and read it back from the console:</p> | |
| 62 | +<pre>amx_show_activity</pre> | |
| 63 | +<p>The console should echo the new value. Then perform an admin action (a slap on yourself) and confirm the on-screen message matches the visibility level you set. If a cvar refuses to stick, something is executing after <code>amxx.cfg</code> and re-setting it — the load order of <a href="/tutorials/plugins-ini-load-order">plugins.ini</a> and any per-map configs is where to look.</p> |
cs16-fps-boost-guide/en.md
A
| @@ -0,0 +1,15 @@ | ||
| 1 | +--- | |
| 2 | +title: "How to Boost FPS in CS 1.6 (2026 Guide)" | |
| 3 | +excerpt: "Real ways to raise and smooth your client frame rate in CS 1.6 — fps_max, launch options, video settings and the config lines that matter — without the placebo tweaks." | |
| 4 | +category: "client" | |
| 5 | +tags: "fps, performance" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>CS 1.6 is a 2003 game; on any modern PC it should run at hundreds of frames per second. If yours does not, the cause is almost always one of a handful of real settings, not some secret cvar from a YouTube thumbnail. This guide sticks to the settings that measurably change frame rate on the current engine and skips the folklore. Your client frame rate has nothing to do with the server's FPS — that is a separate number covered in <a href="/tutorials/measure-server-fps">measuring server FPS</a>.</p><h2>1. Raise the fps_max cap</h2><p><code>fps_max</code> is the client frame-rate ceiling. The old engine effectively held it near 100; the current build lets it go much higher. Open the console (enable it with <code>-console</code> or set <code>Enable developer console</code> in Options) and set:</p><pre>fps_max 300</pre><p>Values around 100, 144 (match your monitor), or a few hundred are all reasonable. There is no benefit to an absurd number, and a frame rate far above your refresh rate mostly just heats the GPU. Put it in your config so it persists — see <a href="/tutorials/cs16-config-cfg-guide">the config.cfg guide</a>.</p><h2>2. Use OpenGL, not Software</h2><p>In <em>Options → Video</em>, set the renderer to <strong>OpenGL</strong>. Software mode exists for compatibility and is dramatically slower. OpenGL is the correct choice on every modern GPU.</p><h2>3. Turn off vertical sync</h2><p>VSync locks your frame rate to the monitor refresh and adds input latency. Turn it off in-game:</p><pre>gl_vsync 0</pre><p>Also confirm it is not being forced on in your GPU driver control panel — a driver-level "force VSync on" overrides the game.</p><h2>4. Set launch options</h2><p>Right-click Counter-Strike in Steam → <em>Properties → Launch Options</em> and set a resolution and console:</p><pre>-console -width 1920 -height 1080 -freq 144</pre><p><code>-freq</code> sets the refresh rate the game requests; match your monitor. Do not paste long lists of made-up flags — most "FPS boost" launch options copied around forums do nothing or are outright invalid on the current engine.</p><h2>5. Trim the config lines that help</h2><p>A few cvars genuinely reduce per-frame work. Add them to your config:</p><pre>developer 0 | |
| 10 | +gl_spriteblend 0 | |
| 11 | +max_shells 0 | |
| 12 | +max_smokepuffs 0 | |
| 13 | +violence_hblood 0 | |
| 14 | +violence_ablood 0</pre><p><code>developer 1</code> spams the console and costs frames; keep it at 0 unless debugging. The shell and smoke-puff limits cut some clutter. These are small gains — the big wins are fps_max, OpenGL and VSync.</p><h2>6. Show the frame rate so you can measure</h2><p>Do not tune blind. Turn on a live readout:</p><pre>net_graph 3 | |
| 15 | +cl_showfps 1</pre><p><code>net_graph 3</code> shows FPS along the bottom next to your network stats; <code>cl_showfps 1</code> is a plain counter. Change one setting at a time and watch the number actually move.</p><h2>7. Rule out the machine, not the game</h2><p>If frames are still low, the cause is often outside CS: an outdated GPU driver, a laptop running on the integrated GPU instead of the discrete one, or Windows power settings throttling the CPU. Update the driver, force the game onto the dedicated GPU in the driver control panel, and set the Windows power plan to High Performance.</p><h2>Common errors</h2><ul><li><strong><code>fps_max</code> seems capped near 100</strong> — you are on an old build or <code>gl_vsync</code>/driver VSync is on. Turn VSync off and confirm the game is current; the very old engine held ~100 by design.</li><li><strong>Frame rate high but the game still stutters</strong> — that is a network problem, not FPS. Check <code>net_graph 3</code> for choke/loss and read <a href="/tutorials/cs16-fix-high-ping">how to fix high ping</a>.</li><li><strong>Settings reset every launch</strong> — you edited <code>config.cfg</code> while the game was running and it overwrote your changes on exit. Use an autoexec approach from <a href="/tutorials/cs16-config-cfg-guide">the config guide</a>.</li><li><strong>Low FPS only on a laptop</strong> — the game is running on the integrated GPU. Force the discrete GPU in the NVIDIA/AMD control panel.</li><li><strong>Screen stretched after setting a resolution</strong> — that is a display-scaling issue, covered in <a href="/tutorials/cs16-widescreen-resolution">the widescreen guide</a>.</li></ul><h2>Verification</h2><p>Enable <code>net_graph 3</code>, join a server or a bot match, and watch the FPS figure during action. After the changes above you should see a stable frame rate comfortably above your monitor's refresh rate with no dips into the double digits during smoke or crossfire. Change one setting, alt-tab back, and confirm the number moved — that is the only proof that matters.</p> |
get-players-on-new-server/en.md
A
| @@ -0,0 +1,50 @@ | ||
| 1 | +--- | |
| 2 | +title: "How to Get Players on a Brand New CS 1.6 Server" | |
| 3 | +excerpt: "An empty server stays empty because the browser sorts by player count. Here is the honest, ordered playbook for getting the first regulars onto a new CS 1.6 server." | |
| 4 | +category: "hosting" | |
| 5 | +tags: "growth, players" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>The hard truth about a brand-new CS 1.6 server: it is empty because it is empty. The internet browser sorts by player count, so a zero-player server sits at the bottom of a list thousands of servers long, and players join servers that already have players. Breaking out of that cold-start problem is the whole game. None of this is magic — it is a grind of getting the fundamentals right and then being consistently visible. Here is the order that actually works.</p> | |
| 10 | + | |
| 11 | +<h2>1. Make sure you are even findable</h2> | |
| 12 | +<p>Before growth, get discovery right. Your server must appear in the master list, which means <code>sv_lan 0</code>, a reachable public UDP 27015, and — critically — a <strong>dedicated IPv4 address</strong>. Servers sharing one IP on different ports have master-list identity problems and get culled or merged in the browser. If you are not certain you are listed, stop here and fix it first: <a href="/tutorials/get-server-in-master-list">getting listed in the master list</a> and <a href="/tutorials/cs16-server-firewall-ports">which ports to open</a>.</p> | |
| 13 | + | |
| 14 | +<h2>2. Pick a mod that still has demand</h2> | |
| 15 | +<p>A well-run server for a dead mode grows slower than a mediocre server for a popular one. Look at what is actually populated in your region's browser and build for that — do not launch the ten-thousandth vanilla <code>de_dust2</code> unless you have something to differentiate it. See <a href="/tutorials/pick-a-mod-with-players">picking a mod that still has players</a>.</p> | |
| 16 | + | |
| 17 | +<h2>3. Choose a location close to your players</h2> | |
| 18 | +<p>Ping decides retention. A player from your target region will leave a 120 ms server for a 30 ms one without a second thought. Host near the population you want, not near you. This is a hosting decision you make once and cannot easily undo, so weigh it early: <a href="/tutorials/choose-vps-for-cs16">choosing a VPS</a>.</p> | |
| 19 | + | |
| 20 | +<h2>4. Seed the server so it is never truly empty</h2> | |
| 21 | +<p>Players join activity. The two legitimate ways to break the empty-server deadlock:</p> | |
| 22 | +<ul> | |
| 23 | +<li><strong>Real seeding</strong> — get a handful of friends or a small community to agree to hop on at a fixed time each day. Five real players at 8pm pull in strangers who see a populated server.</li> | |
| 24 | +<li><strong>Bots or a fake-player count</strong> — many admins seed with AI bots or a "fake players" plugin so the count is not zero. This is effective and widespread, but be honest about the trade-offs before you rely on it; see <a href="/tutorials/do-server-boost-services-work">do server boost services work</a>.</li> | |
| 25 | +</ul> | |
| 26 | + | |
| 27 | +<h2>5. Set fixed peak hours and defend them</h2> | |
| 28 | +<p>Do not spread thin seeding across 24 hours. Concentrate your real activity into a 2–3 hour daily window so that, at that time, the server is genuinely busy. A server that hits 12/24 every evening at the same hour trains a regular crowd; a server that averages 2 players all day never catches.</p> | |
| 29 | + | |
| 30 | +<h2>6. Be visible off the browser</h2> | |
| 31 | +<ul> | |
| 32 | +<li><strong>List on community sites.</strong> Register on server-listing and ranking sites so people discover you outside the in-game browser. A live banner that shows your current map and player count draws clicks.</li> | |
| 33 | +<li><strong>Run a Discord.</strong> It is where a modern CS 1.6 community lives between sessions. Post when you are seeding so regulars know when to show up.</li> | |
| 34 | +<li><strong>Give people a reason to stay.</strong> Working stats (a ranking plugin), a clear set of rules, and present admins turn a one-time visitor into a regular. A server with a live scoreboard and responsive staff retains far better than a bare install.</li> | |
| 35 | +</ul> | |
| 36 | + | |
| 37 | +<h2>7. Keep it up, literally</h2> | |
| 38 | +<p>Uptime is growth. A server that reboots randomly, lags at peak, or disappears for a weekend loses the fragile regular base it just built. Put it behind a process supervisor so it survives crashes and reboots, and monitor it. Reliability over months is what compounds into a population.</p> | |
| 39 | + | |
| 40 | +<h2>Common mistakes</h2> | |
| 41 | +<ul> | |
| 42 | +<li><strong>Expecting organic players on day one</strong> — with zero seeding, an unknown server can sit empty for weeks. Seeding is not optional.</li> | |
| 43 | +<li><strong>Chasing a saturated niche with no edge</strong> — one more identical zombie server does not grow. Offer something the busy ones do not.</li> | |
| 44 | +<li><strong>Peak hours that drift</strong> — regulars need a predictable time. Pick one and hold it.</li> | |
| 45 | +<li><strong>Bad ping to your audience</strong> — no amount of promotion beats a 40 ms competitor. Fix location first.</li> | |
| 46 | +<li><strong>Buying inflated player counts and nothing else</strong> — vanity numbers with an empty, unremarkable server do not convert. See the honest look linked above.</li> | |
| 47 | +</ul> | |
| 48 | + | |
| 49 | +<h2>Verification</h2> | |
| 50 | +<p>Track two numbers weekly: <strong>peak concurrent real players</strong> and <strong>returning names</strong>. Growth looks like your daily peak creeping up and the same nicknames reappearing — that is a community forming. If your raw connection count is high but nobody stays, the problem is retention (ping, mod, admins), not visibility. If nobody arrives at all, it is discovery, and you should recheck steps 1–3 before spending another minute on promotion.</p> | |
| 0 | 51 |
