Add 7 tutorials (7 files)
Browse Source
Daemon666 committed
parent 696220025f
commit c809cbde9a85bb682d9f9d372cf8a4931516175e
7 changed files
with 68 additions and 0 deletions
A
247-dust2-strategy/en.md
+10 -0
A
first-30-regulars-playbook/en.md
+9 -0
A
fix-failed-to-load-server-dll/en.md
+11 -0
A
fix-msg-overflowed/en.md
+9 -0
A
fix-reunion-wrong-steamids/en.md
+9 -0
A
fix-stuck-verifying-resources/en.md
+11 -0
A
server-name-that-attracts/en.md
+9 -0
247-dust2-strategy/en.md
A
| @@ -0,0 +1,10 @@ | ||
| 1 | +--- | |
| 2 | +title: "24/7 Dust2 Servers: Still the Easiest Way to Fill?" | |
| 3 | +excerpt: "Why a single-map de_dust2 rotation still fills faster than a varied one, the exact cvars and mapcycle to lock it, and where the model breaks down as your server grows." | |
| 4 | +category: "hosting" | |
| 5 | +tags: "strategy, maps" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>Ask any veteran admin how to fill an empty CS 1.6 server and a large share will say the same thing: run 24/7 de_dust2. It is not nostalgia — it is a discovery advantage. Players browsing the server list scan for a map they already know, and dust2 is the one map every CS player has memorised. This is an honest look at why the single-map model still works, exactly how to set it up, and the point at which it stops helping.</p><h2>1. Why one map fills faster than twenty</h2><p>A new server's problem is not retention, it is the <em>first</em> few players — nobody joins an empty server, so you need something that pulls a lone browser in. A 24/7 dust2 server wins that moment three ways. The name is a keyword players actively search the browser for. The map is instantly playable with zero learning curve, so a joiner stays instead of leaving after one confusing round on an unknown map. And a familiar map lowers the bar for the second and third player, who see one person on dust2 and think "I know that, I'll play a round." Variety is a retention feature; it does nothing for cold-start discovery. Related reading: <a href="/tutorials/get-players-on-new-server">getting players on a new server</a> and <a href="/tutorials/pick-a-mod-with-players">picking a mod that already has players</a>.</p><h2>2. Lock the map with mapcycle and cvars</h2><p>A true 24/7 server never rotates off the map. Put a single entry in <code>mapcycle.txt</code>:</p><pre>de_dust2</pre><p>With one line, the "next map" is always dust2, so every map change reloads it. Reinforce that in <a href="/tutorials/setup-server-cfg-cs16">server.cfg</a> so the current and default map are also dust2:</p><pre>map de_dust2 | |
| 10 | +mp_timelimit 30</pre><p>Keep <code>mp_timelimit</code> non-zero so the map still "ends" and cleanly restarts the same map — this resets scores and keeps the round flow honest without ever leaving dust2. The mechanics of what ends a map are in <a href="/tutorials/timelimit-maxrounds-flow">mp_timelimit and map flow</a>, and how the cycle file is read in <a href="/tutorials/mapcycle-txt-setup">mapcycle.txt setup</a>.</p><h2>3. Put the map name where browsers see it</h2><p>The keyword only helps if it is visible. Set the hostname to advertise the map explicitly:</p><pre>hostname "24/7 Dust2 | Fast DM | No Lag"</pre><p>A browser filtering or eyeballing the list reads the hostname, not the current map column alone. "24/7 Dust2" in the name is doing marketing work every second the server is listed. Make sure the server is actually <em>in</em> the list first — <code>sv_lan 0</code> and a working master registration, covered in <a href="/tutorials/get-server-in-master-list">getting into the master list</a>.</p><h2>4. Decide whether to disable RTV</h2><p>A 24/7 server and a Rock The Vote plugin are in tension — the whole promise is that the map never changes. If you run RTV or a map chooser, either remove it or restrict its map list to dust2 only so a vote cannot break the promise the hostname makes. Nothing frustrates a player who joined "24/7 Dust2" more than a vote dumping them onto de_aztec. If you want variety, run it as a <em>separate</em> server with its own rotation rather than diluting the 24/7 one.</p><h2>5. Where the model breaks down</h2><p>Single-map filling is a starter strategy, not a growth ceiling. Two limits show up as you succeed. First, regulars burn out — the same map every session eventually pushes your most loyal players toward variety, so a mature community usually runs 24/7 dust2 to <em>acquire</em> players and a second rotation server to <em>keep</em> them. Second, the tactic is crowded: many admins run 24/7 dust2, so you are competing on ping, slot count, and lack of lag, not novelty. That is why the hostname promises "No Lag" — on this map, performance is your only differentiator. Get the server FPS and rates right (see <a href="/tutorials/rehlds-performance-cvars">ReHLDS performance cvars</a>) because a laggy dust2 loses to the dozen other dust2 servers one line down the list.</p><h2>Common errors</h2><ul><li><strong>Server rotates off dust2 anyway</strong> — <code>mapcycle.txt</code> has more than one line, or an RTV/mapchooser plugin is changing it. Trim the cycle to one entry and restrict the vote.</li><li><strong>Map name not visible in the browser</strong> — the hostname does not mention dust2. Put "24/7 Dust2" in <code>hostname</code>.</li><li><strong>Fills briefly then empties every night</strong> — that is the retention limit, not a bug. Add a second varied server for regulars.</li><li><strong>Loses to identical servers</strong> — you are competing on performance and ping now. Fix server FPS and choke, not the map.</li><li><strong>Map restarts but scores never reset</strong> — <code>mp_timelimit 0</code>. Keep it non-zero so the map cycles cleanly.</li></ul><h2>Verification</h2><p>Restart the server, let a map end, and confirm it reloads de_dust2 rather than advancing — watch the console print the same map name. Open the in-game server browser from a second machine, search for your hostname, and confirm "24/7 Dust2" appears with a healthy ping. Then leave it running through a peak evening and watch the player count: if it fills from zero to a handful within a busy window, the discovery advantage is working. If it never crosses the first two or three players, the problem is upstream — the server may not be in the master list at all.</p> |
first-30-regulars-playbook/en.md
A
| @@ -0,0 +1,9 @@ | ||
| 1 | +--- | |
| 2 | +title: "The First 30 Regulars: A Growth Playbook" | |
| 3 | +excerpt: "A concrete playbook for taking a CS 1.6 server from empty to a self-sustaining core of thirty regulars, covering the seeding problem, fixed peak hours, retention hooks, and turning players into a community." | |
| 4 | +category: "hosting" | |
| 5 | +tags: "growth, community" | |
| 6 | +image: "" | |
| 7 | +read_time: "9 min read" | |
| 8 | +--- | |
| 9 | +<p>A CS 1.6 server becomes self-sustaining at roughly thirty regulars — enough that at any popular hour a few are online, which pulls in browsers, which keeps it populated without you babysitting it. Getting to that number is a chicken-and-egg problem: players join servers with players. This playbook is the sequence that actually works, in order, from a stone-cold empty server to a living community.</p><h2>1. Solve the cold-start with a fixed seeding hour</h2><p>An empty server stays empty because nobody joins first. You break the loop by <strong>being the first player every day at the same time</strong>. Pick one hour that suits your timezone's evening, be on the server yourself, and invite anyone you can — friends, a few AI bots for warmth (see <a href="/tutorials/fake-players-bot-padding">real bots vs fake padding</a>). Browsers who see 2–3 real players at 8pm every night will try it; an empty server at random hours they will not. Consistency of <em>time</em> matters more than raw hours online.</p><h2>2. Pick a mod that has an audience</h2><p>You are competing for a finite, mod-specific population. A vanilla public in an ocean of vanilla publics is invisible; a well-run mod server with a smaller audience can own its niche. Choose deliberately — zombie, gungame, CSDM, classic pubs — using <a href="/tutorials/pick-a-mod-with-players">picking a mod with players</a>, and commit to it. Do not change mod every week; regulars form around a stable identity, and each switch resets your progress.</p><h2>3. Make the first five minutes good</h2><p>A first-time joiner decides in minutes. Remove friction: no forced download of 80MB before they can play (keep custom content lean, use <a href="/tutorials/fastdl-setup-guide">FastDL</a> so it is fast), spawn protection so they are not instantly farmed (<a href="/plugins/csb-spawn-protection">CSB Spawn Protection</a>), and a clear <a href="/tutorials/motd-txt-html-guide">MOTD</a> that says what the server is and how to reach the Discord. A new player who spawns, gets a fair fight, and sees where the community lives is a candidate regular.</p><h2>4. Build retention hooks</h2><p>Give players reasons to return that compound over time:</p><ul><li><strong>Ranks and stats</strong> — a visible ladder people want to climb. Set up <a href="/tutorials/setup-stats-system">a stats system</a>; "I'm rank 14, I want top 10" brings people back.</li><li><strong>Playtime and recognition</strong> — track time and reward it. A <a href="/plugins/csb-playtime-tracker">playtime tracker</a> plus a tag for veterans makes regulars feel seen.</li><li><strong>Reserved slots</strong> — regulars should never be turned away when the server is full (<a href="/tutorials/reserved-slots-setup">reserved slots</a>).</li></ul><h2>5. Turn players into a community off-server</h2><p>The server is where they play; the community is where they commit. Stand up a Discord and funnel every joiner into it — put it in the MOTD, announce it in-game with an <a href="/plugins/csb-adverts">adverts plugin</a>, and wire live status into it (<a href="/tutorials/discord-server-integration">Discord integration</a>). Once thirty players are in a Discord that pings when the server fills, they seed each other. That ping — "6 online, come play" — is what replaces you as the daily seeder.</p><h2>6. Make new admins from your regulars</h2><p>You cannot be online every hour, and a server that is only well-behaved when you are watching will not grow. Promote trusted regulars to admins with limited flags so the seeding hour and moderation continue without you — but guard against abuse (<a href="/tutorials/prevent-admin-abuse">preventing admin abuse</a>). A core of a few reliable admins across timezones is what finally makes the server run itself.</p><h2>Common errors</h2><ul><li><strong>Seeding at random hours</strong> — nobody learns when to show up. Fix one peak hour and hold it for weeks.</li><li><strong>Changing the mod repeatedly</strong> — each change scatters the regulars you were accumulating. Commit to one identity.</li><li><strong>Punishing new joiners</strong> — getting spawn-farmed in the first minute drives them off. Add spawn protection and keep the download light.</li><li><strong>No off-server home</strong> — without a Discord, players never coordinate and the server dies whenever you are offline. Build the community, not just the server.</li><li><strong>Faking the count instead of seeding</strong> — padding drives away the very regulars you need; see <a href="/tutorials/fake-players-bot-padding">fake players and bot padding</a>.</li></ul><h2>Verification</h2><p>Track two numbers weekly: unique players who returned on a different day (that is a forming regular) and the size of your Discord. When your fixed peak hour reliably has real players before you personally log on — when the server seeds itself — you have crossed the threshold. At that point browsers do the recruiting for you, and your job shifts from filling the server to keeping the community you built healthy. For the tactics that feed this loop, keep <a href="/tutorials/get-players-on-new-server">getting players onto a new server</a> to hand.</p> |
fix-failed-to-load-server-dll/en.md
A
| @@ -0,0 +1,11 @@ | ||
| 1 | +--- | |
| 2 | +title: "Fix: 'Failed to load server DLL' / cs.so Not Loading" | |
| 3 | +excerpt: "What the game DLL is, why liblist.gam points at the wrong file, the Metamod hand-off that breaks the path, 32-bit and ReGameDLL mismatches, and reading the load error verbatim." | |
| 4 | +category: "errors" | |
| 5 | +tags: "gamedll, crash" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>The server refuses to start and prints a variant of:</p><blockquote>Failed to load server DLL</blockquote><p>or, on Linux, a failure to load <code>cs.so</code> / <code>dlopen</code> of the game library. The game DLL is the code that <em>is</em> Counter-Strike — <code>cs.so</code> (Linux) or <code>mp.dll</code> (Windows), or its ReGameDLL replacement. When the engine cannot load it, there is no mod to run, so the server dies at boot. The cause is always one of: wrong path, wrong architecture, or a broken Metamod hand-off. Here is how to isolate it.</p><h2>1. Read which file it failed on</h2><p>The full console line names the path the engine tried. Get it:</p><pre>./hlds_run -game cstrike -console +map de_dust2 2>&1 | head -40</pre><p>Note the exact filename in the error — whether it points at <code>cstrike/dlls/cs.so</code>, a Metamod path, or a ReGameDLL file. That path is the whole diagnosis.</p><h2>2. Check liblist.gam</h2><p><code>cstrike/liblist.gam</code> tells the engine which game DLL to load via its <code>gamedll</code> / <code>gamedll_linux</code> lines:</p><pre>gamedll "dlls\mp.dll" | |
| 10 | +gamedll_linux "dlls/cs.so" | |
| 11 | +</pre><p>If these point at a file that does not exist — a typo, a renamed folder, a ReGameDLL install that changed the filename — the load fails. Confirm the referenced file is actually present:</p><pre>ls -l cstrike/dlls/cs.so</pre><p>A missing or misnamed <code>cs.so</code> here is the single most common cause. Restore the stock file or fix the path to match reality.</p><h2>3. Understand the Metamod hand-off</h2><p>When you run Metamod, the engine loads <em>Metamod</em> as the game DLL, and Metamod in turn loads the real game DLL named in <code>addons/metamod/plugins.ini</code>... except the real game DLL is pointed to by <code>liblist.gam</code> being redirected to Metamod. The critical detail: with Metamod installed, <code>liblist.gam</code>'s <code>gamedll_linux</code> should point at <strong>Metamod's</strong> <code>.so</code>, and Metamod loads the actual <code>cs.so</code>. If someone edited one side and not the other — Metamod path in <code>liblist.gam</code> but Metamod misconfigured, or the real <code>cs.so</code> path lost — you get this error. If the failing file is <code>metamod</code>, jump to <a href="/tutorials/fix-failed-to-open-metamod-so">the metamod.so fix</a>; if it is <code>cs.so</code>, the game DLL itself is the problem.</p><h2>4. Rule out an architecture mismatch</h2><p>The game DLL is 32-bit. A 64-bit-only host, or a mixed install where someone dropped a 64-bit build in, fails to load with an incompatible-ELF error. Check the file:</p><pre>file cstrike/dlls/cs.so</pre><p>It must report <code>ELF 32-bit</code>. If it says 64-bit, you have the wrong build — install the 32-bit game DLL and its 32-bit libraries (<code>libc6:i386</code>, <code>libstdc++6:i386</code>). This is the same class of problem as <a href="/tutorials/fix-libstdcpp-so-6-not-found">the libstdc++ error</a>.</p><h2>5. Match ReGameDLL to the engine</h2><p>If you replaced the stock game DLL with <a href="/tutorials/install-regamedll-cs16">ReGameDLL_CS</a>, it must be a build compatible with your engine (ReHLDS strongly recommended). A ReGameDLL binary built against a different ReHLDS API, or dropped onto plain HLDS it does not support, can fail to load or crash immediately. Reinstall a ReGameDLL release matching your ReHLDS version, and make sure <code>liblist.gam</code> points at the ReGameDLL file, not the old stock one.</p><p>One subtle ReGameDLL trap: it typically installs its <code>cs.so</code> in place of the stock one under <code>cstrike/dlls/</code>, so a botched install can leave you with a zero-byte or partially-copied file that the engine reports as a load failure rather than a missing file. Check the size and permissions of the file <code>liblist.gam</code> names, and if in doubt drop the stock <code>cs.so</code> back to prove the engine and paths are fine before re-layering ReGameDLL on top.</p><h2>Common errors</h2><ul><li><strong>Points at <code>cs.so</code> that is missing</strong> — wrong path in <code>liblist.gam</code> or a deleted file. Restore it and fix the path.</li><li><strong>Points at <code>metamod</code></strong> — this is a Metamod load failure, not the game DLL. See the metamod fix.</li><li><strong><code>wrong ELF class</code> / incompatible</strong> — a 64-bit game DLL on a 32-bit contract. Install the 32-bit build.</li><li><strong>Failed right after installing ReGameDLL</strong> — the ReGameDLL build does not match your engine. Reinstall a matching release.</li><li><strong>Works without Metamod, fails with it</strong> — the Metamod hand-off in <code>liblist.gam</code>/<code>plugins.ini</code> is misconfigured.</li></ul><h2>Verification</h2><p>Start the server in the foreground and watch it pass the DLL load without error, reaching the map:</p><pre>./hlds_run -game cstrike -console +map de_dust2</pre><p>A clean boot to the map means the game DLL loaded. If you run Metamod, confirm the chain with <code>meta list</code> after startup — Metamod running plus a spawned map proves both the Metamod hand-off and the underlying <code>cs.so</code> loaded correctly. Connect a client to a live round to be sure the mod is really running and not a stub.</p> |
fix-msg-overflowed/en.md
A
| @@ -0,0 +1,9 @@ | ||
| 1 | +--- | |
| 2 | +title: "Fix: 'Msg overflowed' / Buffer Overflow in Message" | |
| 3 | +excerpt: "What SZ_GetSpace and reliable-channel overflows mean, why too many entities or a chatty plugin trigger them, and how to cut the message volume that crashes clients." | |
| 4 | +category: "errors" | |
| 5 | +tags: "netchan, overflow" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>Players get disconnected with a buffer or message overflow, or the server console spits out <code>SZ_GetSpace</code> errors during heavy fights. GoldSrc packs game state and events into fixed-size network buffers each frame. When the engine tries to write more into a buffer than it holds — too many entities in view, too many simultaneous messages, a plugin flooding HUD or chat — it overflows, and depending on which buffer, either a client drops or the server errors. The cure is to reduce what is being crammed into the buffer.</p><h2>1. Identify which overflow you have</h2><p>The two you will actually see are:</p><pre>SZ_GetSpace: overflow on netchan->message</pre><p>and</p><pre>Reliable channel overflowed for <player></pre><p>The reliable-channel overflow is per client: one player is being sent more reliable data than their channel can carry, and the engine drops them to protect the connection. The generic <code>SZ_GetSpace</code> overflow is the buffer running out of space while the engine or a plugin writes to it. Both come down to volume — the difference is whether it is one player's channel or a shared buffer.</p><h2>2. Suspect entity and effect density first</h2><p>The most common non-plugin cause is simply too much happening at once: a corner packed with players, grenades, smoke, decals, and temporary sprites. Each visible entity and effect costs bytes in the update. On a high-slot server a single choke point can push a client's update past the buffer. If overflows cluster around the busiest map areas and biggest fights, this is your cause — and it overlaps with the edict pressure covered in <a href="/tutorials/fix-max-edicts-too-many-entities">the MAX_EDICTS fix</a>.</p><h2>3. Find the chatty plugin</h2><p>A plugin that sends large or frequent messages is the other big cause. Watch for:</p><ul><li>HUD plugins redrawing a big status panel every frame instead of on change.</li><li>Advert or info plugins printing long colored messages to everyone at once.</li><li>Effect plugins firing many temporary-entity messages per kill or per shot.</li><li>Menu or scoreboard plugins rebuilding on every event.</li></ul><p>Disable suspects one at a time in <a href="/tutorials/plugins-ini-load-order">plugins.ini</a>, change map, and see whether the overflow stops. A plugin that blasts a per-frame HUD message to 32 players is a classic trigger.</p><h2>4. Reduce the volume</h2><p>Once you know the source, cut it down:</p><ul><li>Lower decal churn with a stricter <code>decalfrequency</code> so sprays and bullet marks do not pile bytes into every update.</li><li>Trim cosmetic effect plugins on high-population servers where the buffer headroom per client is smallest.</li><li>For a plugin you control or can configure, make HUD updates event-driven, not per-frame, and shorten message text.</li><li>Reduce slot count if you are running far more players than the map and plugin set can serialize per frame.</li></ul><p>Do not reach for exotic net cvars as a first move — the overflow is caused by content volume, and tuning rates around it just moves the crash. Cut the source.</p><h2>5. Distinguish a server crash from a client kick</h2><p>It matters who actually goes down. A <code>Reliable channel overflowed for <player></code> line usually drops only that one client — the server survives and everyone else plays on — because the engine protects the connection by disconnecting the overloaded channel. A generic <code>SZ_GetSpace</code> overflow on a shared buffer is worse: it can fault the whole server. If you are losing single players intermittently, hunt the per-client cause (a plugin targeting individuals, or one player sitting in the densest spot). If the entire server drops at once, look at a broadcast — a round-end effect, a bomb explosion, an advert fired to all — that wrote too much to a buffer shared by everyone. Reading which message immediately preceded the crash in the console narrows it fast.</p><h2>Troubleshooting</h2><ul><li><strong><code>Reliable channel overflowed for X</code> repeatedly</strong> — that specific client is being sent too much reliable data; a plugin is spamming them, or they sit in the densest area. Find the plugin or reduce effects.</li><li><strong>Overflows only during big fights</strong> — entity/effect density, not a plugin. Cut decals and cosmetic effects.</li><li><strong>Everyone drops at the same moment</strong> — a single broadcast message or effect fired to all players overflowed a shared buffer. Look at what event just happened (round end, a bomb effect, an advert).</li><li><strong>Started after adding one plugin</strong> — that plugin is the source; it sends too much. Reconfigure or replace it.</li><li><strong>Only on 32-slot, fine on 16</strong> — per-frame buffer pressure scales with player count. Reduce slots or the plugin/effect load.</li></ul><h2>Verification</h2><p>After cutting the suspected source, recreate the worst case: fill the busiest map area with as many players as you can, throw grenades, spray decals, and trigger the events that used to overflow. A clean console with no <code>SZ_GetSpace</code> or reliable-channel errors through a full heavy round means the volume now fits the buffers. If you isolated a plugin, re-enable it alone to confirm the overflow returns with it and disappears without it — that closes the loop on the cause rather than leaving you guessing.</p> |
fix-reunion-wrong-steamids/en.md
A
| @@ -0,0 +1,9 @@ | ||
| 1 | +--- | |
| 2 | +title: "Fix: Reunion Installed but Steam IDs Are Still Wrong" | |
| 3 | +excerpt: "Why non-Steam players share STEAM_ID_LAN or get colliding IDs even with Reunion loaded, how the SteamIdHashSalt and cid modes work, why Reunion refuses to load without a long salt, and how to verify stable IDs." | |
| 4 | +category: "errors" | |
| 5 | +tags: "reunion, steamid" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>You installed Reunion so non-Steam players get stable, unique Steam IDs, but players still show <code>STEAM_ID_LAN</code>, share one ID, or get a different ID every reconnect — which breaks admin flags, bans, and <a href="/tutorials/setup-stats-system">stats</a> that are all keyed by SteamID. Reunion works, but only when its salt and ID-generation mode are configured correctly, and a common failure is that it silently did not load at all. Here is how to get real, stable IDs.</p><h2>1. Confirm Reunion actually loaded</h2><p>Reunion is a Metamod plugin. If it is not listed in Metamod's plugin list, nothing it does is happening and the engine falls back to <code>STEAM_ID_LAN</code> for non-Steam clients. From the server console:</p><pre>meta list</pre><p>Reunion must appear with status <code>running</code>. If it is absent, its line is missing from <code>addons/metamod/plugins.ini</code>; if it shows <code>bad load</code>, the most common cause is the salt problem in the next step — Reunion refuses to start without a valid salt.</p><h2>2. Set a SteamIdHashSalt of at least 16 characters</h2><p>This is the single most common reason Reunion does not load. Its config, <code>reunion.cfg</code> in the server root, must define a hash salt of <strong>16 characters or more</strong>. Anything shorter and Reunion refuses to initialize:</p><pre>SteamIdHashSalt = a-long-random-secret-salt-value</pre><p>The salt is what makes generated IDs both unique and stable — it is mixed into the hash that turns a non-Steam client's identity into a persistent <code>STEAM_</code> ID. Once set, <strong>never change it</strong>: changing the salt regenerates every non-Steam player's ID, orphaning their admin access, bans, and rank. Pick one long random value at setup and leave it.</p><h2>3. Choose the right cid (client id) generation mode</h2><p>Reunion generates the ID for non-Steam clients from a source you select in <code>reunion.cfg</code>. The mode decides whether IDs are stable. A mode that keys off something the client can change or that many clients share produces collisions; a mode that keys off the client's stored authentication produces stable, distinct IDs. Set the generation mode per Reunion's documented options in <code>reunion.cfg</code> and prefer the mode that derives the ID from the client's own stored token rather than from an easily-shared value. If two different people consistently get the same ID, your mode is deriving IDs from something they share — switch modes and have them reconnect.</p><h2>4. Match Reunion to your engine</h2><p>Reunion is the non-Steam provider for <strong>ReHLDS</strong>. On original Valve HLDS you use <strong>dproto</strong> instead. Running Reunion on stock HLDS, or an old Reunion build against a newer ReHLDS, can load but misbehave — wrong IDs, or clients that authenticate as Steam when they are not. Confirm you are on ReHLDS (its banner prints at boot) and that Reunion is a build current with your engine, as covered in <a href="/tutorials/fix-regamedll-rehlds-incompatible">the ReHLDS compatibility guide</a>.</p><h2>5. Understand Steam vs non-Steam clients</h2><p>Reunion handles the non-Steam side; genuine Steam clients keep their real Steam ID regardless. If a legitimate Steam player shows a wrong ID, that is not a Reunion issue — check that the server is validating Steam tickets and that <code>sv_lan</code> is <code>0</code>, since a LAN server issues <code>STEAM_ID_LAN</code> to everyone. Mixing this up sends admins chasing Reunion config when the real cause is a LAN-mode server. Set <code>sv_lan 0</code> and confirm real Steam clients resolve to their own IDs before blaming Reunion for non-Steam ones.</p><h2>Troubleshooting</h2><ul><li><strong>Reunion <code>bad load</code> in <code>meta list</code></strong> — <code>SteamIdHashSalt</code> is shorter than 16 characters or missing. Set a long salt (step 2).</li><li><strong>Everyone is <code>STEAM_ID_LAN</code></strong> — Reunion is not loaded at all, or <code>sv_lan 1</code>. Check <code>meta list</code> and set <code>sv_lan 0</code>.</li><li><strong>Two players share one ID</strong> — the cid generation mode derives the ID from a shared value. Change the mode (step 3).</li><li><strong>ID changes every reconnect</strong> — the mode keys off something non-persistent, or the salt was changed. Fix the mode and leave the salt alone.</li><li><strong>All non-Steam bans stopped working after an edit</strong> — you changed <code>SteamIdHashSalt</code> and regenerated every ID. Restore the original salt.</li><li><strong>Wrong engine</strong> — Reunion on stock HLDS. Use <a href="/tutorials/setup-dproto-non-steam">dproto</a> there instead.</li></ul><h2>Verification</h2><p>Have a non-Steam player connect and run <code>status</code> in the console; note their <code>STEAM_</code> ID. Have them reconnect and confirm the ID is identical — stable across sessions is the whole point. Then have a second non-Steam player join and confirm they get a <em>different</em> ID. If IDs are stable per player and distinct between players, Reunion is configured correctly and admin flags, bans and <a href="/tutorials/setup-stats-system">rank</a> will now key reliably. Finally, add a non-Steam admin by their resolved ID and confirm the flag applies on their next connect. Guard <code>reunion.cfg</code> and its salt like a password.</p> |
fix-stuck-verifying-resources/en.md
A
| @@ -0,0 +1,11 @@ | ||
| 1 | +--- | |
| 2 | +title: "Fix: Players Stuck on 'Verifying Resources' / Precaching" | |
| 3 | +excerpt: "Why clients hang on 'Verifying and downloading resources', how the precache file limit and a broken FastDL cause it, and the fixes that let players finish loading in." | |
| 4 | +category: "errors" | |
| 5 | +tags: "precache, download" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>Players connect, reach the <em>Verifying and downloading resources</em> screen, and sit there — the loading bar crawls, freezes, or the client eventually drops. This stage is where the client fetches every custom file the map and plugins reference and checks them against what the server expects. A hang here has three usual causes: too many files (the precache limit), a broken download source, or a consistency mismatch. This sorts out which one you have.</p><h2>1. Understand the stage</h2><p>Before a player spawns, the server sends the full list of resources the map needs — the <code>.bsp</code>, models, sounds, sprites, and anything plugins precache. The client verifies which it already has and downloads the rest. If that list is enormous, or a file cannot be fetched, or a file the client has does not match what the server demands, the client stalls right here. So the fix depends on <em>why</em> the list will not clear.</p><h2>2. Check the precache file count</h2><p>GoldSrc has a fixed ceiling on precached files. Pile on custom-model plugins, sound packs, sprite-heavy HUD plugins and a content-rich map, and the resource list grows huge — slow to verify and, past the limit, a hard failure. If the hang correlates with adding plugins or a specific map, trim what gets precached. Disable content-heavy plugins one at a time in <a href="/tutorials/plugins-ini-load-order">plugins.ini</a> and retest; the same budget problem behind the <a href="/tutorials/fix-sound-slots-overflow">out of sound slots overflow</a> shows up here as a stall. Fewer files means a faster, more reliable verify stage.</p><h2>3. Fix the download source</h2><p>If the client is trying to download and cannot, it hangs. Two server cvars govern whether and how fast that download works:</p><pre>sv_allowdownload 1 | |
| 10 | +sv_downloadurl "http://dl.example.com/cs"</pre><p>With <code>sv_allowdownload 0</code>, clients missing a file are stuck or join without it. With allow on but <strong>no</strong> FastDL URL, downloads crawl over the ancient in-game UDP channel — a 20 MB map can hang the verify screen for minutes and time out. Set up FastDL so files come over HTTP; the full setup is in the <a href="/tutorials/fastdl-setup-guide">FastDL setup guide</a>. If your FastDL is configured but every file 404s, the client stalls forever — see <a href="/tutorials/fix-sv-downloadurl-ignored">sv_downloadurl ignored</a> for the path traps.</p><h2>4. Resolve a consistency mismatch</h2><p>If the server enforces file consistency and a client has a <em>different</em> version of a file (a differently-sized model or sprite), the client can hang or get dropped at verification. Consistency is enforced with <code>sv_consistency</code> and <code>force_consistency</code> rules:</p><pre>sv_consistency 1</pre><p>With consistency on, the client must match the server's version of enforced files. If you distribute a custom model but a client cached an old one, it fails here. Either make sure the FastDL serves the exact files the server uses, or relax consistency for non-critical files. A mismatch shows up as a specific file the client cannot reconcile, not a slow bar.</p><h2>5. Rule out the client's own settings</h2><p>Some hangs are the player's side. If a player set <code>cl_allowdownload 0</code>, they cannot pull missing files and will stall or join broken no matter what your server does — you cannot override it. Have them confirm:</p><pre>cl_allowdownload 1 | |
| 11 | +cl_downloadingfiles 1</pre><p>If one player hangs and everyone else loads fine, it is that player's setting or connection, not your server.</p><h2>Troubleshooting</h2><ul><li><strong>Bar crawls extremely slowly</strong> — downloading over the slow UDP channel. Set up <a href="/tutorials/fastdl-setup-guide">FastDL</a> so files come over HTTP.</li><li><strong>Hangs on one specific map</strong> — that map's custom files are missing from the download source, or push you past the precache limit. Confirm the files are on FastDL and trim plugin precaches.</li><li><strong>Only one player hangs</strong> — their <code>cl_allowdownload</code> is <code>0</code> or their link dropped. It is client-side.</li><li><strong>Drops with a consistency complaint</strong> — the client's copy of an enforced file differs. Serve the exact file via FastDL or relax <code>sv_consistency</code>.</li><li><strong>Started after adding plugins</strong> — too many precached files. Disable heavy content plugins to test.</li></ul><h2>Verification</h2><p>From a clean test client (delete the custom map and models first), connect and watch the verify stage complete and the map load. If it downloads over HTTP quickly and spawns you in, the pipeline is healthy. Then connect on the heaviest map with all plugins active and confirm it still clears — that proves you are under the precache budget with a working download source. Keep the FastDL mirror in sync with your <a href="/tutorials/mapcycle-txt-setup">map rotation</a> so a newly-added map never introduces files the mirror lacks.</p> |
server-name-that-attracts/en.md
A
| @@ -0,0 +1,9 @@ | ||
| 1 | +--- | |
| 2 | +title: "Server Name Tricks That Actually Attract Players (and the Ones That Get You Delisted)" | |
| 3 | +excerpt: "How the hostname cvar drives discovery in the CS 1.6 server browser, what to put in a name that earns clicks, and the fake-player-count and tag tricks that get servers hidden." | |
| 4 | +category: "hosting" | |
| 5 | +tags: "hostname, marketing" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>In a server browser sorted by ping and players, your <code>hostname</code> is the one line of text that decides whether someone clicks you. It is the most-seen piece of copy your server has. There is real craft in writing one that pulls players — and a set of dishonest tricks that get servers filtered out of the browser entirely. This covers both: what genuinely works and what to never do.</p><h2>1. Set the hostname correctly</h2><p>The name is the <code>hostname</code> cvar, set in <a href="/tutorials/setup-server-cfg-cs16">server.cfg</a> so it applies on every start:</p><pre>hostname "[EU] Classic 5v5 24/7 Dust2 | fast dl"</pre><p>It must be set before the server registers with the master list, which is why <code>server.cfg</code> is the right place — setting it live with <code>rcon</code> works but does not survive a restart. Read it back with <code>hostname</code> and no argument to confirm.</p><h2>2. Front-load the information a player scans for</h2><p>Players read the first part of the name and stop. Put the decision-making facts first: region tag, mode, and the map or gimmick. A player scanning for a low-ping classic server sees <code>[EU] Classic 5v5</code> and knows instantly it is for them. Good ingredients, roughly in priority order:</p><ul><li><strong>Region tag</strong> — <code>[EU]</code>, <code>[BR]</code>, <code>[RU]</code>. Ping is the first filter; naming your region saves the player a guess.</li><li><strong>Mode</strong> — Classic, Zombie, GunGame, DeatHRun. See <a href="/tutorials/popular-mods-by-region">popular modes by region</a>.</li><li><strong>The hook</strong> — <code>24/7 Dust2</code>, <code>100 lvl</code>, <code>free VIP</code>, <code>fast dl</code>. One concrete reason to pick you over the server above.</li></ul><h2>3. Keep it short and readable</h2><p>Long names get truncated in the browser and on your <a href="/tutorials/server-banners-signatures">banner</a>, so the clever part at the end never gets seen. Aim for something that reads fully at a glance. Skip walls of Unicode symbols and colour-code spam — they look like noise, some browsers render them as boxes, and they push the useful words off the visible edge. One clean tag beats ten decorative glyphs, and a name a player can read in the half-second they spend scanning the list is a name that gets the click. Assume the reader is skimming dozens of rows at once and write for that.</p><h2>4. Tricks that work honestly</h2><p>These pull clicks without lying: naming a popular 24/7 map that people search for by name; advertising a genuine perk (<code>free VIP</code>, <code>no lag</code>) that you actually deliver; a consistent community tag so returning players recognise you at a glance; and matching the language of your target region so it reads as "for me". None of these fake anything — they just surface a real reason to join.</p><h2>5. The tricks that get you delisted</h2><p>Do not do any of these. <strong>Fake player counts</strong> — padding the server with bots dressed as players to look full — is the classic dishonest trick; it inflates your browser ranking briefly but real players who join an empty "full" server leave instantly and feel scammed, and query-based trackers and communities flag it. <strong>Impersonating another server</strong> by copying a well-known community's exact name invites reports. <strong>Misleading region tags</strong> (labelling a US box <code>[EU]</code>) just guarantees a wave of high-ping rage-quits. The browser and the wider community route around servers that lie, and the reputation cost is permanent. Honest naming compounds; deceptive naming burns down.</p><h2>Common mistakes</h2><ul><li><strong>Name reverts after restart</strong> — you set <code>hostname</code> live but not in <a href="/tutorials/setup-server-cfg-cs16">server.cfg</a>. Put it in the config.</li><li><strong>Clever part of the name is cut off</strong> — too long. Front-load the essentials; the browser truncates.</li><li><strong>Name shows as boxes or garbage</strong> — non-ASCII decoration your target players' browser cannot render. Stick to plain text and simple tags.</li><li><strong>Great name, players still leave fast</strong> — the name promised something the server does not deliver (a mode, low ping, VIP). Match the name to reality or fix the reality.</li><li><strong>Server hidden or reported</strong> — fake counts or impersonation. Stop padding with bots; earn the count.</li></ul><h2>Verification</h2><p>Set your hostname, restart, and find your own server in the in-game browser exactly as a player would — is the important part visible without clicking? Read the cvar back in console with <code>hostname</code> to confirm it stuck. Then ask an honest question of the name: does every claim in it match what a joiner actually gets? If the name says <code>[EU]</code> and your ping test from Europe is 90ms, or it says <code>free VIP</code> and there is none, fix the mismatch. A name that is true and scannable will out-convert a decorated lie over any real timespan.</p> | |
| 0 | 10 |
