Add 7 tutorials (7 files)
Browse Source
Daemon666 committed
parent 2983c4fcd4
commit e3a553a7cc99f2c3fe8182aa6ddeb027dd4331a9
7 changed files
with 76 additions and 0 deletions
A
fake-players-bot-padding/en.md
+10 -0
A
fix-dproto-clients-rejected/en.md
+13 -0
A
fix-missing-wad-server-side/en.md
+9 -0
A
fix-regamedll-rehlds-incompatible/en.md
+10 -0
A
fix-steamcmd-timeout-downloading/en.md
+12 -0
A
read-hlds-core-dump-gdb/en.md
+13 -0
A
server-banners-signatures/en.md
+9 -0
fake-players-bot-padding/en.md
A
| @@ -0,0 +1,10 @@ | ||
| 1 | +--- | |
| 2 | +title: "Fake Players and Bot Padding: Risks and Alternatives" | |
| 3 | +excerpt: "What fake-player padding is, why it inflates your listing count, the concrete risks of delisting and player distrust, and the honest alternatives that actually fill a server." | |
| 4 | +category: "hosting" | |
| 5 | +tags: "bots, ethics" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>Every new-server owner discovers the same temptation: plugins that add fake "players" to the scoreboard so the server looks busy in the browser and on GameTracker, on the theory that players join servers that already have people. Padding does exploit a real psychological effect — but it carries risks that can sink a server, and there are honest tactics that produce the same pull without them. This lays out how padding works, what it costs you, and what to do instead.</p><h2>1. What bot padding actually does</h2><p>A fake-player plugin does not spawn real bots that play. It manipulates the numbers the engine reports to A2S_INFO queries, so the browser and listing sites show, say, 12/32 when the server is empty. The "players" have names but no bodies, no movement, no interaction — they exist only in the query response. The goal is purely cosmetic: appear populated so real players click join.</p><h2>2. Why it backfires</h2><p>The effect that makes padding tempting is the same one that punishes it:</p><ul><li><strong>The reveal is instant.</strong> A player joins your "12-player" server and finds it empty. That is worse than an honestly empty server — you have taught them your listing lies, and they will not come back or recommend you.</li><li><strong>Listing sites detect and delist.</strong> GameTracker and monitors track player <em>history</em> and can spot the signature of padding — a count that never resolves into real join/leave churn. Flagged servers lose ranking or get removed, destroying the very visibility you were faking. See <a href="/tutorials/gametracker-ranking-explained">how GameTracker ranking works</a>.</li><li><strong>It corrupts your own stats.</strong> Fake entries pollute logs and can confuse rank plugins and your uptime tooling.</li></ul><h2>3. The security angle</h2><p>Fake-player exploits are also a known attack surface. Malicious actors use the same query-manipulation techniques to grief servers, and some "free" padding plugins are backdoored — you are running untrusted code that touches network responses. If you run a defensive plugin, run it to <em>block</em> abuse, not to pad: <a href="/plugins/csb-fakeplayer-guard">CSB Fakeplayer Guard</a> exists to detect and reject fake-player manipulation against your server, and you should audit any plugin before loading it (<a href="/tutorials/spot-backdoored-amxx-plugin">spotting a backdoored plugin</a>).</p><h2>4. Real bots are the honest version of the same idea</h2><p>If you want bodies on the server so it is not a ghost town at 3am, use <em>actual</em> AI bots that play the game. YapB and similar bots walk the map, buy, shoot, and fill rounds — a player who joins finds a real game in progress, not a lie. Install them per <a href="/tutorials/install-yapb-bots">the YapB guide</a> and cap them so they yield slots to humans:</p><pre>yb_quota 6 // keep ~6 bots when the server is quiet | |
| 10 | +yb_quota_mode fill // bots fill up to the quota, leave as humans join</pre><p>The distinction is everything: a bot the player can shoot is content; a number that evaporates on join is a bait-and-switch.</p><h2>5. What genuinely fills a server</h2><p>Population comes from consistency and content, not from faked counts. Pick a mod that has an audience (<a href="/tutorials/pick-a-mod-with-players">picking a mod with players</a>), be online yourself at fixed hours so there is always a seed of real play, reward regulars, and advertise where players look. The full approach is in <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>. Reserved slots (<a href="/tutorials/reserved-slots-setup">reserved slots setup</a>) keep space for regulars during a rush — that is honest scarcity, the opposite of fake abundance.</p><h2>Common errors</h2><ul><li><strong>"Padding got me players"</strong> — briefly, then a delisting or a reputation for lying costs you more than you gained. The join-then-empty experience is a net negative.</li><li><strong>Server flagged or dropped on GameTracker</strong> — the padding signature was detected. Remove the plugin; ranking recovers only with real activity.</li><li><strong>Bots never leave for humans</strong> — you set a fixed count instead of a fill quota. Use <code>yb_quota_mode fill</code> so bots yield slots.</li><li><strong>Installed a padding plugin that did more than pad</strong> — it was backdoored. Audit before loading; prefer maintained code.</li><li><strong>Real players complain the server "feels bottish"</strong> — your bot quota is too high at peak. Lower <code>yb_quota</code> so humans dominate when they show up.</li></ul><h2>Verification</h2><p>Query your own server from outside and confirm the reported count matches the number of real plus real-bot players actually in the game — there should be no phantom entries. Join with a bot quota set and confirm the "players" move, shoot, and buy; a legitimate bot does all three. Watch your GameTracker page over a week: an honest server's graph shows genuine join/leave churn, which is exactly what ranking rewards and what padding can never fake.</p> |
fix-dproto-clients-rejected/en.md
A
| @@ -0,0 +1,13 @@ | ||
| 1 | +--- | |
| 2 | +title: "Fix: dproto Installed but Non-Steam Clients Are Still Rejected" | |
| 3 | +excerpt: "Why non-Steam players are still bounced after installing dproto, the HLDS vs ReHLDS split with Reunion, the dproto.cfg protocol and client settings, and confirming the module actually loaded." | |
| 4 | +category: "errors" | |
| 5 | +tags: "dproto, non-steam" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>You dropped dproto in to allow non-Steam clients, restarted, and non-Steam players are still refused — kicked at connect, or shown as invalid. dproto is a Metamod plugin (or a direct engine module) that lets original HLDS accept non-Steam clients, but it only works when it is the right tool for your engine, is actually loaded, and is configured to accept the client type your players run. Here is the checklist that resolves it.</p><h2>1. Use the right emulator for your engine</h2><p>This is the most common mistake. The rule:</p><ul><li><strong>Original HLDS</strong> — use <strong>dproto</strong>.</li><li><strong>ReHLDS</strong> — use <strong>Reunion</strong>, not dproto.</li></ul><p>If you are running ReHLDS and installed dproto, it may load but misbehave or refuse clients, because the two projects target different engines. On ReHLDS, remove dproto and install Reunion instead; note that Reunion needs a <code>SteamIdHashSalt</code> of at least 16 characters in its config or it refuses to load at all. See <a href="/tutorials/install-rehlds-on-linux">the ReHLDS install guide</a> for which stack you are actually on.</p><h2>2. Confirm dproto is actually loaded</h2><p>An installed file is not a loaded module. If you run dproto through Metamod, it must be listed in <code>addons/metamod/plugins.ini</code>:</p><pre>linux addons/dproto/dproto_i386.so | |
| 10 | +</pre><p>Check at runtime from the server console:</p><pre>meta list</pre><p>dproto must appear with a running/ok status. If it is absent, the path in <code>plugins.ini</code> is wrong or the <code>.so</code> is missing. If Metamod itself is not loading, that is upstream — see <a href="/tutorials/fix-failed-to-open-metamod-so">the metamod.so load fix</a> first, because nothing dproto-related works until Metamod runs.</p><h2>3. Set dproto.cfg to accept non-Steam clients</h2><p>dproto is configured through <code>dproto.cfg</code>. The setting that decides which client types are allowed governs whether Steam-only, non-Steam-only, or both can connect. The client-type value must permit non-Steam:</p><pre># dproto.cfg (values control accepted client types) | |
| 11 | +client_ss_check 0 | |
| 12 | +# accept both Steam and non-Steam clients rather than Steam-only | |
| 13 | +</pre><p>If dproto is set to accept only validated Steam clients, non-Steam players are rejected by design — exactly the symptom. Set it to allow non-Steam (or both) client types, and restart the server so the config is re-read.</p><h2>4. Align the protocol version</h2><p>dproto exposes a protocol setting. If it is pinned to a protocol your clients do not speak, they are bounced with a version-style rejection. If your community runs a specific client build, match dproto's protocol to it; if in doubt, allow the protocol your players actually use rather than forcing one. A protocol mismatch here presents almost identically to <a href="/tutorials/fix-different-game-version">the different-version error</a>, so if the rejection mentions the game version, suspect the protocol setting.</p><h2>5. Do not run two emulators at once</h2><p>Running dproto and Reunion (or dproto twice under different names) simultaneously makes them fight over the same connection hooks, and clients get rejected unpredictably. Pick one emulator for your engine and remove the other from <code>plugins.ini</code> entirely. Confirm with <code>meta list</code> that exactly one non-Steam emulator is loaded.</p><h2>6. Restart, do not just change map</h2><p>dproto hooks the engine at load, so config changes to <code>dproto.cfg</code> and edits to <code>plugins.ini</code> are only picked up on a full server restart, not a <code>changelevel</code>. Admins often edit the config, change the map, see no difference, and conclude dproto is broken — when in fact the old configuration is still resident. Stop the server process fully and start it again after any dproto config change, then re-check <code>meta list</code>. If you edit the client-type or protocol setting live, nothing takes effect until that restart, which explains a great many "I changed it and it still rejects them" reports.</p><h2>Common errors</h2><ul><li><strong>dproto loaded but non-Steam still rejected</strong> — the client-type setting in <code>dproto.cfg</code> only accepts Steam clients. Allow non-Steam.</li><li><strong>dproto not in <code>meta list</code></strong> — wrong path in <code>plugins.ini</code> or a missing/mis-architecture <code>.so</code>.</li><li><strong>Rejected with a game-version message</strong> — protocol mismatch. Align dproto's protocol to the clients.</li><li><strong>Running ReHLDS, dproto flaky</strong> — wrong tool; switch to Reunion (with a 16+ char <code>SteamIdHashSalt</code>).</li><li><strong>Random rejections</strong> — two emulators loaded at once. Keep exactly one.</li></ul><h2>Verification</h2><p>From the console, confirm the module is live:</p><pre>meta list</pre><p>dproto should show as running. Then connect with a non-Steam client and confirm it joins and appears in <code>status</code> with a valid ID. Because ranks and bans key off SteamID, also confirm non-Steam players get stable IDs rather than all sharing one — if they collide, revisit the ID-hashing settings, the same concern covered in <a href="/tutorials/find-player-steamid">finding a player's SteamID</a>. A clean non-Steam join plus a distinct ID per player means the emulator is doing its job.</p> |
fix-missing-wad-server-side/en.md
A
| @@ -0,0 +1,9 @@ | ||
| 1 | +--- | |
| 2 | +title: "Fix: 'Couldn't open .wad' - Missing WAD Files for Clients" | |
| 3 | +excerpt: "Why a custom map throws 'couldn't open' WAD errors, how a .bsp references texture WADs, putting the WADs where clients can download them, and embedding textures so they never miss." | |
| 4 | +category: "errors" | |
| 5 | +tags: "wad, maps" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>You add a custom map and players either drop on connect or load in with missing textures and a console full of WAD errors. A <code>.bsp</code> map does not always contain its own textures — it can reference external <strong>WAD</strong> texture packages by name, and if a client (or the server) cannot find a referenced WAD, you get the error and broken visuals. The fix is to make sure every WAD the map names is present and downloadable, or to embed the textures into the map so nothing external is needed.</p><h2>1. Read the error and identify the WAD</h2><p>The message names the exact file:</p><pre>Couldn't open ns_boesmania.wad</pre><p>or the client-side variant complaining it cannot find a WAD the map wants. The named file is a texture package the mapper referenced at compile time but did not include with the map. Note that a map can reference several WADs; fix them all, not just the first one printed.</p><h2>2. Know why it happens</h2><p>When a mapper compiles a <code>.bsp</code>, they choose whether textures are <em>embedded</em> in the map or left as references to external WADs. If they reference external WADs (common for shared texture sets like the stock CS and Half-Life WADs, and for custom texture packs), those WAD files must exist alongside the map on both the server and every client. Standard WADs such as <code>halflife.wad</code>, <code>decals.wad</code>, and the <code>cs_*.wad</code> set ship with the game, so those never error. Custom WADs that came with a map pack are the ones that go missing.</p><h2>3. Put the WADs on the server and make them downloadable</h2><p>Place every custom WAD the map references in the game folder:</p><pre>cstrike/<wadname>.wad</pre><p>WADs live in the mod root (<code>cstrike/</code>), not in <code>maps/</code>. Then make sure clients can pull them: downloads must be enabled and the file must be on your fast-download mirror. In <a href="/tutorials/sv-allowdownload-settings">server.cfg</a>:</p><pre>sv_allowdownload 1</pre><p>and copy the same WAD into the matching path on your FastDL host, exactly as covered in the <a href="/tutorials/fastdl-setup-guide">FastDL setup guide</a>. If the WAD is on the server but not on the mirror, the server itself renders the map but connecting clients still error — they download from the mirror, not from the game server, when <code>sv_downloadurl</code> is set.</p><h2>4. The permanent fix: embed the textures</h2><p>The robust solution is to stop referencing external WADs at all by embedding the textures into the <code>.bsp</code>. If you compile or recompile the map, wad-include the custom textures so they are baked into the map file. Tools that repackage a finished map can also merge the referenced WAD textures into the <code>.bsp</code>. An embedded map is self-contained: it carries its own textures, so no client can ever be missing a WAD, at the cost of a larger map file. For a public server where you cannot control what mappers did, embedding the maps you host is the reliable path.</p><h2>5. List the map's required files</h2><p>Ship a resource list so clients know what to download. A <code>.res</code> file next to the map naming the WADs, models, and sounds it needs makes the download explicit rather than relying on the engine to infer everything. This is especially worth doing for map packs with several custom WADs.</p><h2>Troubleshooting</h2><ul><li><strong><code>Couldn't open X.wad</code> on the server console</strong> — the WAD is not in <code>cstrike/</code>. Copy it there.</li><li><strong>Server is fine, clients miss textures</strong> — the WAD is on the server but not on the FastDL mirror, or downloads are off. Check <code>sv_allowdownload 1</code> and the mirror path.</li><li><strong>Only some players error</strong> — those players have <code>cl_allowdownload 0</code> set locally, or their download of the WAD failed; only they can re-enable it.</li><li><strong>WAD present but still errors</strong> — filename case mismatch on Linux (<code>Custom.wad</code> vs <code>custom.wad</code>). Match the case the map references exactly.</li><li><strong>Recurs on every new map pack</strong> — embed the textures into the <code>.bsp</code> so hosted maps are self-contained and stop depending on external WADs.</li></ul><h2>Verification</h2><p>Load the map on the server and confirm the console is clean of WAD errors — that proves the server has every referenced WAD. Then connect from a fresh client that has never seen the map (delete it locally first) and watch it download; if it loads with correct textures and no <code>couldn't open</code> spam, the download path works end to end. For a map you embedded, the definitive test is to rename or remove the external WAD from the client entirely and confirm the map still renders every texture — if it does, the map is truly self-contained.</p> |
fix-regamedll-rehlds-incompatible/en.md
A
| @@ -0,0 +1,10 @@ | ||
| 1 | +--- | |
| 2 | +title: "Fix: ReGameDLL and ReHLDS Version Incompatibility Crash" | |
| 3 | +excerpt: "Why the server crashes on boot after mixing ReHLDS and ReGameDLL builds, how the API version handshake works, reading the console banner and crash line, and how to get onto a matched set." | |
| 4 | +category: "errors" | |
| 5 | +tags: "regamedll, rehlds" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>You updated ReHLDS or ReGameDLL, and now the server crashes on startup or refuses to load the game DLL. ReHLDS (the engine) and ReGameDLL_CS (the game logic) talk over a versioned interface, and when the two builds expect different versions of that interface the game library is rejected or the process segfaults during initialization. This is a compatibility problem, not corruption, and the fix is to get both onto a matched set. Here is how to diagnose and do that.</p><h2>1. Read the startup banner</h2><p>Both projects print their version to the console at boot. Start the server from a terminal (not detached) so you can see the lines before the crash:</p><pre>./hlds_run -game cstrike -console +map de_dust2</pre><p>ReHLDS prints its engine version early; ReGameDLL prints its own banner as the game DLL initializes. If the crash happens <em>after</em> the ReHLDS line but <em>before</em> or <em>during</em> the ReGameDLL line, the game DLL is failing to attach to the engine — the signature of a version mismatch. Note both version strings; you need them to pick a compatible pair.</p><h2>2. Recognize the mismatch errors</h2><p>The console around the crash usually names the interface. Common lines include a failure to load the game library or an API version complaint:</p><pre>Failed to load the "cs" game DLL | |
| 10 | +Game DLL version mismatch</pre><p>A hard segfault with no message right as the game DLL loads is the same class of problem — the DLL called into an engine ABI that changed. Either way the meaning is: this ReGameDLL build was compiled against a different ReHLDS API than the one you are running.</p><h2>3. Match the pair, do not mix eras</h2><p>The reliable fix is to run ReHLDS and ReGameDLL builds from the same release window. Do not pair a brand-new ReGameDLL with a ReHLDS from two years ago, or vice versa. Decide which one you actually needed to update and bring the other forward to match. Update both binaries together:</p><ul><li>The ReHLDS engine binaries (<code>engine_i486.so</code> / the swds library) go in the HLDS root.</li><li>The ReGameDLL game library (<code>cs.so</code> / <code>mp.dll</code>) goes in <code>cstrike/dlls/</code>.</li></ul><p>Replace both, keeping backups of the old files, then boot. A matched pair passes the handshake and the ReGameDLL banner appears cleanly. This is the base install described in <a href="/tutorials/install-regamedll-cs16">the ReGameDLL guide</a>.</p><h2>4. Keep Metamod and ReAPI in step</h2><p>If you run Metamod-r and the reapi module, they sit in the same dependency chain. A ReGameDLL update that changes hook chains can break an old reapi module, producing <code>bad load</code> or a later crash even after the engine handshake succeeds. When you move ReHLDS and ReGameDLL, refresh the reapi module too, and confirm Metamod-r is a build that supports your ReHLDS. See <a href="/tutorials/fix-reapi-native-not-found">the ReAPI native fix</a> for how that layer reports failure.</p><h2>5. Roll back cleanly if the update was the trigger</h2><p>If the crash started the moment you updated one component and you cannot immediately source a matching build, restore the backups you took and return to the last-known-good matched set. This is why keeping the previous <code>cs.so</code> and engine files before any update matters — a mismatch is instantly reversible if you kept the old pair. Never update one of the two in isolation on a live server without the other's matching build ready.</p><h2>Troubleshooting</h2><ul><li><strong><code>Failed to load the "cs" game DLL</code></strong> — the game library is the wrong architecture or built against a different engine API. Replace it with a build matching your ReHLDS.</li><li><strong>Segfault right as the game DLL loads, no message</strong> — ABI mismatch between ReGameDLL and ReHLDS. Match the pair (step 3).</li><li><strong>ReHLDS banner prints, then instant exit</strong> — ReGameDLL rejected the engine version. Update ReGameDLL to the same era.</li><li><strong>Boots but reapi plugins are <code>bad load</code></strong> — the reapi module is out of step with the new ReGameDLL. Update the module.</li><li><strong>Crash returned after a working period</strong> — an automated update pulled one component forward. Pin versions and update both together.</li><li><strong>Works with stock game DLL, crashes with ReGameDLL</strong> — confirms the game DLL is the mismatched piece, not the engine.</li></ul><h2>Verification</h2><p>Boot the server in a terminal and confirm both banners print in sequence — the ReHLDS engine line, then the ReGameDLL version line — with no crash between them and the map loading normally. Connect a client and confirm gameplay logic (buy menu, round timing, ReGameDLL-specific cvars) behaves. If both banners appear and the map loads, the handshake succeeded and the versions are compatible; save that exact pair of binaries as your known-good baseline before the next update. Then re-check any <a href="/tutorials/fix-reapi-native-not-found">ReAPI plugins</a> load, since they depend on the same matched stack.</p> |
fix-steamcmd-timeout-downloading/en.md
A
| @@ -0,0 +1,12 @@ | ||
| 1 | +--- | |
| 2 | +title: "Fix: SteamCMD 'Timeout downloading' Errors" | |
| 3 | +excerpt: "Why SteamCMD hangs with 'Timeout downloading. Retrying', the app 90 legacy-depot trap for CS 1.6, and the retry, platform and CDN fixes that finish the install." | |
| 4 | +category: "errors" | |
| 5 | +tags: "steamcmd, download" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>You run SteamCMD to install the CS 1.6 dedicated server (app <code>90</code>) and it stalls with <code>Timeout downloading. Retrying...</code>, loops forever, or bails with <code>Error! App '90' state is 0x606 after update job</code>. SteamCMD is generally reliable, so a persistent timeout is nearly always one of a few specific things: a flaky CDN edge, the notorious app 90 legacy-depot behaviour, or a platform/architecture mismatch. Here is how to get it to finish.</p><h2>1. Just retry — it is often a bad CDN edge</h2><p>The first and dullest fix works more often than it should. <code>Timeout downloading</code> frequently means Steam handed you a slow or dead content-server edge. Simply re-run the exact same command; SteamCMD resumes from where it stopped and usually gets a different, healthy edge:</p><pre>./steamcmd.sh +force_install_dir ./hlds +login anonymous +app_update 90 validate +quit</pre><p>If it times out again, run it a few more times — each retry resumes progress rather than restarting. Many "broken" installs finish on the third attempt with zero config changes.</p><h2>2. Handle the app 90 legacy-depot trap</h2><p>CS 1.6's app <code>90</code> is old and pulls legacy depots that behave badly with a single <code>app_update 90</code>. The classic symptom is it downloading, timing out, and re-downloading the base HLDS depot in a loop, never reaching the Counter-Strike content. The reliable workaround is to install the base first, then the mod depots, running the update repeatedly until the state settles:</p><pre>./steamcmd.sh +force_install_dir ./hlds +login anonymous +app_update 90 +quit | |
| 10 | +# run it again; app 90 often needs several passes to fully settle | |
| 11 | +./steamcmd.sh +force_install_dir ./hlds +login anonymous +app_update 90 validate +quit</pre><p>Do not add <code>validate</code> on the very first pass if it keeps looping — validate forces a re-check that can restart the loop. Get a clean pass first, then validate once at the end.</p><h2>3. Force the platform type</h2><p>On a 64-bit Linux box SteamCMD sometimes fetches the wrong platform depot and stalls. Pin it to the platform the CS 1.6 server actually needs:</p><pre>./steamcmd.sh +@sSteamCmdForcePlatformType linux +force_install_dir ./hlds +login anonymous +app_update 90 validate +quit</pre><p>You can substitute <code>windows</code> if you are deliberately pulling the Windows binaries under Wine. Setting the platform explicitly stops SteamCMD guessing and re-fetching the wrong depot, which is a frequent cause of an install that downloads a large amount and then loops back to the start without ever completing.</p><h2>4. Fix the environment causing timeouts</h2><p>If retries never help, the timeout is your side, not Steam's:</p><ul><li><strong>32-bit libraries missing</strong> — SteamCMD is 32-bit. On a 64-bit host without <code>lib32gcc</code>/<code>lib32stdc++</code> it can fail oddly during download. Install the i386 libs for your distro.</li><li><strong>Disk full</strong> — a partition running out of space mid-download reads as a timeout/loop. Check <code>df -h</code>.</li><li><strong>Firewall/proxy</strong> — a restrictive outbound firewall throttling Steam CDN traffic causes exactly this stall. Confirm the box has clean outbound HTTP to Steam content servers.</li><li><strong>Ancient SteamCMD</strong> — a stale binary can loop. Delete the SteamCMD directory and re-extract a fresh copy, letting it self-update on first run.</li></ul><h2>5. Point it at a fresh install dir</h2><p>A partially-corrupted download directory can make every subsequent run time out trying to reconcile broken state. Move the old directory aside and let SteamCMD build a clean one:</p><pre>mv hlds hlds.broken | |
| 12 | +./steamcmd.sh +force_install_dir ./hlds +login anonymous +app_update 90 validate +quit</pre><p>A clean directory removes any half-written depot metadata that was confusing the updater.</p><h2>Troubleshooting</h2><ul><li><strong><code>Timeout downloading. Retrying</code> loops forever</strong> — bad CDN edge or app 90 legacy behaviour. Re-run several times; run without <code>validate</code> first, then validate once at the end.</li><li><strong><code>Error! App '90' state is 0x606</code></strong> — the update did not complete. Re-run <code>app_update 90</code> until it reports up to date, then <code>validate</code>.</li><li><strong>Fails immediately, not a timeout</strong> — missing 32-bit libs or a stale SteamCMD binary. Install i386 libs and re-extract SteamCMD.</li><li><strong>Downloads then loops re-downloading the base depot</strong> — the classic app 90 trap. Run multiple passes; do not validate until it settles.</li><li><strong>Stalls at the same percentage every time</strong> — disk full or a proxy cutting the connection. Check <code>df -h</code> and outbound connectivity.</li></ul><h2>Verification</h2><p>A finished install prints <code>Success! App '90' fully installed</code> and drops the server files into your install dir. Confirm the launch binary and <code>cstrike/</code> exist, then start the server once to prove the content is complete:</p><pre>./hlds_run -game cstrike +map de_dust2 +maxplayers 12</pre><p>If it reaches a running console and loads the map, the download completed cleanly. From here, layer your <a href="/tutorials/setup-server-cfg-cs16">server.cfg</a> and content on a known-good base rather than fighting a half-installed one.</p> |
read-hlds-core-dump-gdb/en.md
A
| @@ -0,0 +1,13 @@ | ||
| 1 | +--- | |
| 2 | +title: "How to Read a HLDS Core Dump with gdb" | |
| 3 | +excerpt: "How to make HLDS produce a core file, load it in gdb, read the backtrace to find which module crashed the server, and turn that stack into an actionable culprit." | |
| 4 | +category: "errors" | |
| 5 | +tags: "gdb, coredump" | |
| 6 | +image: "" | |
| 7 | +read_time: "9 min read" | |
| 8 | +--- | |
| 9 | +<p>When HLDS segfaults it can leave a <strong>core dump</strong> — a snapshot of the process memory at the instant it died. Loaded into <code>gdb</code>, that core gives you a backtrace: the exact chain of function calls that led to the crash, usually pointing straight at the module or plugin responsible. This is how you move from "the server keeps crashing on map change" to "Metamod plugin X faulted in this function." You need shell access to the box; you do not need to be a C programmer to read the result.</p><h2>1. Make the server actually produce a core</h2><p>By default the shell limits core dumps to zero bytes, so nothing is written. Raise the limit in the same shell that launches the server, before starting it:</p><pre>ulimit -c unlimited</pre><p>Confirm it took with <code>ulimit -c</code> (it should print <code>unlimited</code>). Now when HLDS crashes it writes a <code>core</code> or <code>core.<pid></code> file into its working directory — the same folder as <code>hlds_run</code>. If you launch through a wrapper or systemd, the limit and the core pattern are set differently; check <code>/proc/sys/kernel/core_pattern</code>, which shows where the kernel sends cores (a bare <code>core</code> means the working directory; a piped value means a handler like systemd-coredump or apport is intercepting them).</p><h2>2. Install gdb and locate the core</h2><p>Install the debugger and find the dump:</p><pre>sudo apt-get install gdb | |
| 10 | +ls -la core*</pre><p>You should see a <code>core</code> file with a recent timestamp matching the crash. If there is none after a confirmed crash, the <code>ulimit</code> was not applied to the process that died, or a handler captured it — see the troubleshooting section.</p><h2>3. Load the core against the right binary</h2><p>gdb needs both the executable that crashed and the core. For GoldSrc the crashing process is the 32-bit engine launcher:</p><pre>gdb ./hlds_linux core</pre><p>gdb loads, prints the signal that killed it (typically <code>Program terminated with signal SIGSEGV, Segmentation fault.</code>), and drops you at a prompt. The binary must match the one that produced the core; loading a core against a different build gives you nonsense addresses.</p><h2>4. Read the backtrace</h2><p>At the gdb prompt, ask for the call stack:</p><pre>bt</pre><p>You get a numbered list of stack frames, most-recent first:</p><pre>#0 0xf5a01b2c in ?? () from .../addons/metamod/dlls/some_plugin.so | |
| 11 | +#1 0xf5a03f10 in ?? () from .../addons/metamod/dlls/some_plugin.so | |
| 12 | +#2 0xf7c12abc in ?? () from .../cstrike/dlls/cs.so | |
| 13 | +#3 0x0804a1d0 in ?? () from ./hlds_linux</pre><p>Read frame <code>#0</code> first: the file it names in the <code>from ...</code> path is where execution was when the process died. If that path points at a Metamod plugin <code>.so</code> or an AMX Mod X module, that add-on is your prime suspect — the crash happened in its code. If <code>#0</code> is inside <code>engine_i486.so</code> or <code>cs.so</code> but the frames above it come from a plugin, the plugin fed the engine something bad. The lower frames show the path that got there. Use <code>bt full</code> for local variables if the symbols are present.</p><h2>5. Turn the stack into a culprit</h2><p>You now have a filename. Correlate it with the crash conditions: if the top frame is <code>zombie_plague.so</code> and the server dies on map change, disable that plugin and see whether the crash stops. Cross-reference the timestamp with the <a href="/tutorials/read-amxx-error-log">AMXX error log</a> and the HLDS console log — a run-time error logged one second before the core often names the same plugin. This backtrace-plus-log pairing is the fast path; the broader elimination method for a server that crashes with no obvious cause is in <a href="/tutorials/debug-server-crash-no-error">debugging a server crash with no error</a> and <a href="/tutorials/find-crashing-plugin">finding a crashing plugin</a>.</p><h2>Common errors</h2><ul><li><strong>No core file after a crash</strong> — <code>ulimit -c unlimited</code> was not set for the process that died, or <code>core_pattern</code> pipes cores to a handler. Check both.</li><li><strong>Backtrace is all <code>?? ()</code> with no names</strong> — symbols are stripped; the <code>from ...so</code> path is still the useful part. That filename is your suspect.</li><li><strong>'core' is truncated / gdb complains it is incomplete</strong> — the disk filled or the limit capped it. Free space and set the limit to <code>unlimited</code>.</li><li><strong>Loaded core against the wrong binary</strong> — addresses look random. Use the exact <code>hlds_linux</code> that crashed.</li><li><strong>Crash is inside the engine, not a plugin</strong> — if no add-on appears anywhere in the stack, suspect the engine build itself and consider <a href="/tutorials/install-rehlds-on-linux">ReHLDS</a>, which fixes many stock-engine faults.</li></ul><h2>Verification</h2><p>Once the stack points at a plugin or module, remove it (comment its line in <code>plugins.ini</code> or <code>modules.ini</code>), restart, and reproduce the exact action that caused the crash. If the server survives, the backtrace was correct. Keep the core file and your <code>bt</code> output until the fix is confirmed — if the crash returns, load the next core the same way and compare frame <code>#0</code>; a moving top frame points at memory corruption, a stable one confirms the single guilty add-on.</p> |
server-banners-signatures/en.md
A
| @@ -0,0 +1,9 @@ | ||
| 1 | +--- | |
| 2 | +title: "Server Banners and Signatures That Get Clicks" | |
| 3 | +excerpt: "How CS 1.6 server banners and forum signatures work, how the connect link is built, why live player-count images convert better, and the common reasons a banner shows offline." | |
| 4 | +category: "hosting" | |
| 5 | +tags: "banners, marketing" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>A server banner is a small image that shows your server's name, map and live player count, usually links straight into the game, and lives in a forum signature, a Discord, or a website. Done right it is free, always-on advertising that puts your server in front of people already looking for one. Done wrong it shows "offline" and does the opposite. This explains how banners and connect links actually work and how to make one that converts.</p><h2>1. How a banner image works</h2><p>A live banner is an image generated on demand by a tracking service that queries your server with the standard A2S protocol and draws the result — hostname, current map, players/slots — onto a PNG. Because it is queried fresh each time the image loads, it reflects the real state: a banner showing "18/24" tells a viewer the server is alive and worth joining. The service needs to reach your server's query port, which is your game port (default <strong>27015</strong>) over UDP, so the same A2S traffic that puts you in the master list feeds the banner. If <a href="/tutorials/fix-a2s-info-no-response">A2S queries fail</a>, the banner cannot render your state.</p><h2>2. The connect link that actually joins</h2><p>The point of a banner is to turn a viewer into a player in one click. The game registers a URL scheme so a link like this launches CS and connects:</p><pre>steam://connect/203.0.113.10:27015</pre><p>Put that behind the banner image and a viewer who has the game clicks once and lands on your server. Always use the literal IP and port — a hostname that has not propagated, or a missing port, breaks the jump. For players who prefer to do it by hand, also show the raw <code>connect</code> line so they can paste it into the console:</p><pre>connect 203.0.113.10:27015</pre><p>See <a href="/tutorials/cs16-connect-via-console">connecting via console</a> for the client side.</p><h2>3. Use a real tracking service, do not hand-roll</h2><p>You do not need to draw the image yourself. Established server trackers such as GameTracker generate a banner and a signature image from your server IP and port for free, keep it live, and give you the HTML/BBCode to paste. Register your server on one, grab the signature image URL, and wrap it in your <code>steam://connect</code> link. This also gets you a tracker profile page — a place your server exists on the web that people can find and bookmark.</p><h2>4. What makes a banner get clicked</h2><ul><li><strong>Show live players.</strong> A static logo is ignored; "20/24 on de_dust2" is a signal the server is fun right now. Live counts convert far better than art.</li><li><strong>Readable hostname.</strong> The banner inherits your <a href="/tutorials/server-name-that-attracts">server name</a> — keep it short enough to read at banner size.</li><li><strong>Put it where CS players are.</strong> A signature on a CS 1.6 forum, a pinned image in a Discord, your community site. See <a href="/tutorials/where-to-advertise-cs16-server">where to advertise</a>.</li><li><strong>One clear action.</strong> The whole image is the connect link; do not bury it behind three menus.</li></ul><h2>Common errors</h2><ul><li><strong>Banner shows "offline" but the server is up</strong> — the tracker cannot query your port. Confirm UDP 27015 is open and A2S responds; see <a href="/tutorials/cs16-server-firewall-ports">firewall ports</a>.</li><li><strong>Player count is always zero</strong> — a query-port or <code>sv_lan</code> issue, or an A2S-flood protection dropping the tracker's probe. Check <a href="/tutorials/stop-a2s-query-flood">A2S flood handling</a> is not too aggressive.</li><li><strong>Connect link does nothing</strong> — the viewer does not have the game installed, or the link used a hostname/port that does not resolve. Use the literal IP and port.</li><li><strong>Banner shows the wrong map or a stale count</strong> — the tracker caches for a short interval; it catches up within a minute. Persistent staleness means intermittent query timeouts.</li><li><strong>Image hotlink blocked</strong> — some forums strip external images; use the BBCode the tracker provides rather than a raw <code><img></code>.</li></ul><h2>Verification</h2><p>Open your banner image URL directly in a browser — it should render your current hostname, map and live player count, matching what <a href="/tutorials/cs16-server-browser-empty">the in-game browser</a> shows. Then click your own connect link from a machine with CS installed and confirm it launches and joins the right server. Finally, have a friend on a different network click it; if it works for you locally but not for them, your public IP or port forwarding is the problem, not the banner. A banner that renders live and connects in one click is doing its job.</p> | |
| 0 | 10 |
