Add 6 tutorials (6 files)
Browse Source
Daemon666 committed
parent c809cbde9a
commit 82744d8e4d3d8184dcfc80e049522a6106fb1ef0
6 changed files
with 196 additions and 0 deletions
A
add-bot-waypoints-to-map/en.md
+13 -0
A
amxx-versions-explained/en.md
+12 -0
A
dproto-vs-reunion/en.md
+51 -0
A
fix-wad-not-found-compile/en.md
+10 -0
A
install-csdm/en.md
+68 -0
A
install-pterodactyl-cs16-egg/en.md
+42 -0
add-bot-waypoints-to-map/en.md
A
| @@ -0,0 +1,13 @@ | ||
| 1 | +--- | |
| 2 | +title: "Adding Bot Waypoints/Graphs to Your Map (YaPB / POD-Bot)" | |
| 3 | +excerpt: "How to give bots navigation on a custom map: the difference between YaPB graph files and POD-Bot .pwf waypoints, where each file lives, how to record nodes in-game, and how to auto-download community graphs." | |
| 4 | +category: "mapping" | |
| 5 | +tags: "bots, waypoints" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>Bots on a custom CS 1.6 map do nothing until the map has navigation data. Without it they spawn and stand still, because they have no nodes describing where they can walk, camp, or plant. The two dominant bots — <strong>YaPB</strong> and <strong>POD-Bot mm</strong> — use different, incompatible navigation files, and getting them into the right folder is half the battle. This covers both formats and how to create or fetch the data.</p><h2>1. Know which file your bot uses</h2><p>The formats are not interchangeable:</p><ul><li><strong>YaPB</strong> uses a <code>.graph</code> file (its modern navigation format). Newer YaPB builds can also generate a graph automatically.</li><li><strong>POD-Bot mm</strong> uses a <code>.pwf</code> waypoint file (the classic "waypoint" format that predates graphs).</li></ul><p>A <code>.pwf</code> from POD-Bot will not drive YaPB and vice versa. Decide which bot you run first; if you are choosing, see <a href="/tutorials/install-yapb-bots">installing YaPB</a>. The rest of this assumes you know your bot.</p><h2>2. Put the file where the bot looks for it</h2><p>Each bot loads navigation by map name from its own data directory. The files are named after the map (<code>de_rats.graph</code>, <code>de_rats.pwf</code>) and go under the bot's addon folder:</p><pre>// YaPB | |
| 10 | +addons/yapb/data/graph/de_rats.graph | |
| 11 | + | |
| 12 | +// POD-Bot mm | |
| 13 | +addons/podbot/waypoints/de_rats.pwf</pre><p>The filename must match the BSP name exactly, or the bot loads nothing for that map. This mismatch — a graph named for the wrong map — is the single most common reason "the waypoints don't work."</p><h2>3. Fetch an existing graph before making one</h2><p>Popular maps almost always have community navigation already. YaPB in particular can download a graph for the current map from its online database when one is missing, dropping it straight into <code>data/graph/</code>. If the map is well known, load it, let the bot fetch or check the community waypoint archives, and you may be done without recording anything. Only hand-make navigation for a map that has none.</p><h2>4. Record nodes in-game</h2><p>To build navigation yourself, start a local listen server on the map with the bot's waypoint/graph editor enabled, then walk the routes. Both bots expose console commands to add nodes as you move; the workflow is the same in spirit:</p><ul><li>Walk to a spot and add a node; the editor drops a waypoint at your feet.</li><li>Mark special nodes — camp spots, sniper positions, the bomb-plant zone on <code>de_</code> maps, the goal on <code>cs_</code> maps — using the editor's node-type commands so bots know what to do there.</li><li>Let the editor auto-connect nearby nodes into paths, or connect them manually where the auto-linker misses a jump or a ladder.</li></ul><p>Cover every route a player would take: both bombsites, every ramp, ladders, and doorways. Bots can only go where a path exists.</p><h2>5. Save and reload</h2><p>Save from the editor when the network is complete; it writes the <code>.graph</code> or <code>.pwf</code> under the bot's data folder for the current map. Reload the map to load the fresh file, then add bots and watch them move. Iterate — the first pass always misses a corner.</p><h2>6. Ship the navigation with the map</h2><p>If you distribute the map to other servers, include the navigation file. On a server, drop the correct file into the bot's data directory listed above and change the map; no compile step is involved, since navigation is separate from the BSP.</p><h2>Common errors</h2><ul><li><strong>Bots spawn and stand still</strong> — no navigation file for this map, or it is in the wrong folder or misnamed. This is the same root cause covered in <a href="/tutorials/fix-bots-stand-still-no-waypoints">bots stand still with no waypoints</a>.</li><li><strong>Graph exists but bots ignore it</strong> — the filename does not match the BSP name exactly, or you gave a <code>.pwf</code> to YaPB (or a <code>.graph</code> to POD-Bot). Match the format to the bot.</li><li><strong>Bots walk into walls or off ledges</strong> — missing or bad path connections. Re-open the editor and fix the links between nodes.</li><li><strong>Bots never plant or defuse</strong> — you did not mark the objective nodes (bomb-plant / goal). Add the special node types at those locations.</li><li><strong>Editor commands do nothing</strong> — the waypoint/graph editing mode is not enabled, or you are on a real server rather than a local listen server. Edit locally with the editor turned on.</li></ul><h2>Verification</h2><p>Load the map, add a few bots, and watch a full round: they should leave spawn, take multiple routes to the objective, use ladders, and plant or defuse. Force a couple of bots to different areas and confirm none get permanently stuck. If a whole region is dead, you are missing nodes there — add them and re-save. For the reverse problem where bots exist but never move at all, work through <a href="/tutorials/fix-bots-stand-still-no-waypoints">the no-waypoints fix</a>.</p> |
amxx-versions-explained/en.md
A
| @@ -0,0 +1,12 @@ | ||
| 1 | +--- | |
| 2 | +title: "AMX Mod X Versions: 1.8.2 vs 1.9 vs 1.10 vs 1.11-dev" | |
| 3 | +excerpt: "What actually differs between the AMX Mod X release lines, which natives arrived when, why a plugin compiled for one branch can bad-load on another, and which version to run." | |
| 4 | +category: "misc" | |
| 5 | +tags: "amxmodx, versions" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>"Just install AMX Mod X" hides a real decision: which version? The differences between 1.8.2, 1.9, 1.10 and the 1.11 development line are not cosmetic — they change which natives you can call, which modules load, and whether a plugin someone else compiled will even run on your server. Here is what separates the branches and how to pick.</p><h2>1. The release lines</h2><table><thead><tr><th>Version</th><th>Status</th><th>In one line</th></tr></thead><tbody><tr><td><strong>1.8.2</strong></td><td>Old, still widespread</td><td>The long-time default; stable but missing newer natives.</td></tr><tr><td><strong>1.9</strong></td><td>Stable</td><td>The safe modern default; adds natives 1.8.2 lacks.</td></tr><tr><td><strong>1.10</strong></td><td>Current stable</td><td>The current recommended release.</td></tr><tr><td><strong>1.11-dev</strong></td><td>Development</td><td>Bleeding edge; not for production unless you need something in it.</td></tr></tbody></table><h2>2. Why the version changes what your plugins can do</h2><p>Each line added natives and module capabilities. The most-cited example: coloured chat printing. <code>client_print_color</code> — the native that prints team-coloured chat with <code>^x01</code>/<code>^x03</code>/<code>^x04</code> codes — exists from <strong>1.9 onward</strong>, not in 1.8.2. A plugin that calls it will fail to compile on 1.8.2 and, if you download a pre-compiled build, may bad-load on a 1.8.2 server. This is why plugin pages specify a minimum AMXX version: if a plugin lists <code>amxx_min 1.9</code>, it is telling you it uses at least one native that does not exist in 1.8.2.</p><h2>3. The module ABI trap</h2><p>The subtler issue is <strong>binary compatibility of modules and plugins across branches</strong>. AMXX modules (the <code>.so</code>/<code>.dll</code> files providing <code>fakemeta</code>, <code>hamsandwich</code>, etc.) and the compiled <code>.amxx</code> plugins are built against a specific branch's interfaces. A plugin or module compiled for one branch can <strong>bad-load</strong> on another because the internal ABI changed between release lines. Symptoms you will see in <code>amxx plugins</code>:</p><pre>amxx plugins | |
| 10 | +// a mismatched plugin shows: | |
| 11 | +// myplugin.amxx bad load</pre><p>The fix is to compile the plugin against the branch you actually run, or download the build that matches your version — not to force a foreign binary. When you upgrade the core, upgrade the modules to the matching build too; a 1.10 core with leftover 1.8.2 modules is a reliable way to produce <code>bad load</code> lines.</p><h2>4. Compiler differences</h2><p>Each AMXX version ships its own <code>amxxpc</code> compiler and its own set of include files. Compiling with the 1.9 compiler bakes in the 1.9 natives and interfaces; compiling the same source with the 1.10 compiler targets 1.10. This is exactly why a live compile service pins multiple toolchains — the correct binary depends on the target server's version. When in doubt, compile with the toolchain matching the server you will run it on.</p><h2>5. Which version to run</h2><ul><li><strong>New server:</strong> run <strong>1.10</strong> (current stable) or <strong>1.9</strong> (stable, extremely well-supported). Both have the modern natives; you will not hit the 1.8.2 wall.</li><li><strong>Existing 1.8.2 server:</strong> plan an upgrade if you want modern plugins — see <a href="/tutorials/upgrade-amxmodx-1-8-2-to-1-10">upgrading 1.8.2 to 1.10</a>. Keep 1.8.2 only if you depend on a plugin that was never rebuilt for newer branches.</li><li><strong>1.11-dev:</strong> avoid on production. It is a development branch and may change under you; use it only to test something that specifically requires it.</li></ul><p>Install guides per version: <a href="/tutorials/install-amx-mod-x-1-8-2">1.8.2</a>, <a href="/tutorials/install-amx-mod-x-1-9">1.9</a>, <a href="/tutorials/install-amx-mod-x-1-10">1.10</a>.</p><h2>6. What upgrading actually involves</h2><p>Moving between lines is not just swapping the core binary. A clean upgrade means replacing the AMXX core files, replacing every <strong>module</strong> with the matching-branch build, and recompiling any plugin you built yourself against the new compiler and includes. Third-party plugins you downloaded pre-compiled for the old branch should be re-downloaded in a build for the new one, or recompiled from their <code>.sma</code>. Your configs — <code>plugins.ini</code>, <code>modules.ini</code>, <code>amxx.cfg</code> — generally carry over, but new versions sometimes add cvars or change defaults worth reviewing. The single most common upgrade failure is leaving old modules in place: a 1.10 core will happily start but every plugin that touches a stale 1.8.2 module bad-loads. The full procedure for the most common jump is in <a href="/tutorials/upgrade-amxmodx-1-8-2-to-1-10">upgrading 1.8.2 to 1.10</a>. Do it on a test server first and confirm a clean <code>amxx plugins</code> output before touching production.</p><h2>Common misconceptions</h2><ul><li><strong>"Higher version = my old plugins break."</strong> Usually the opposite — newer cores run older <em>source</em> fine once recompiled. What breaks is a <em>pre-compiled</em> binary or module from a different branch, which bad-loads. Recompile and it is fine.</li><li><strong>"1.8.2 is fine, everyone uses it."</strong> Widespread, yes, but it lacks natives like <code>client_print_color</code>. Modern plugins increasingly require 1.9+.</li><li><strong>"I can mix modules from different versions."</strong> No — run one matched set. Mismatched modules bad-load.</li><li><strong>"-dev means newest and best."</strong> It means unfinished. Run stable in production.</li><li><strong>"The version only matters at compile time."</strong> It matters at load time too — the running core must match the modules and accept the plugin's build.</li></ul><h2>How to check your version</h2><p>From the server console:</p><pre>amxx version | |
| 12 | +meta list</pre><p><code>amxx version</code> prints the running AMX Mod X version and build; <code>meta list</code> confirms AMXX loaded under Metamod. Then run <code>amxx plugins</code> and scan for any <code>bad load</code> — those are your version/ABI mismatches. If you see them after an upgrade, replace those plugins and modules with builds matching your core version and reload the map.</p> |
dproto-vs-reunion/en.md
A
| @@ -0,0 +1,51 @@ | ||
| 1 | +--- | |
| 2 | +title: "dproto vs Reunion: Which One in 2026?" | |
| 3 | +excerpt: "A straight comparison of dproto and Reunion for non-Steam CS 1.6 servers: which engine each targets, how they handle SteamIDs and protocol 47/48, and why ReHLDS plus Reunion is the 2026 default." | |
| 4 | +category: "installation" | |
| 5 | +tags: "dproto, reunion, comparison" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>Both <strong>dproto</strong> and <strong>Reunion</strong> do the same job — let a CS 1.6 server accept non-Steam clients and hand every player a usable SteamID — but they target different engines and are not interchangeable. Running the wrong one for your engine is the single most common non-Steam setup mistake. This lays out the differences and gives a clear recommendation for 2026.</p> | |
| 10 | + | |
| 11 | +<h2>1. The one rule that decides it: your engine</h2> | |
| 12 | +<ul> | |
| 13 | +<li><strong>ReHLDS → Reunion.</strong> Reunion is written for ReHLDS and hooks engine functions ReHLDS exposes cleanly.</li> | |
| 14 | +<li><strong>Original Valve HLDS → dproto.</strong> dproto predates ReHLDS and works on the stock engine.</li> | |
| 15 | +</ul> | |
| 16 | +<p>Install <a href="/tutorials/install-reunion">Reunion</a> on plain HLDS and it refuses to load or misbehaves; install dproto on ReHLDS and it may load but reject clients unpredictably. So the real question is not "dproto or Reunion" — it is "which engine am I on," and that answer picks the tool. Check with <code>rehlds_version</code>: a real version means ReHLDS and Reunion; <code>Unknown command</code> means stock HLDS and dproto.</p> | |
| 17 | + | |
| 18 | +<h2>2. Side by side</h2> | |
| 19 | +<table><thead><tr><th></th><th>dproto</th><th>Reunion</th></tr></thead><tbody> | |
| 20 | +<tr><td>Target engine</td><td>Original HLDS</td><td>ReHLDS</td></tr> | |
| 21 | +<tr><td>Loads as</td><td>Metamod plugin (or engine module)</td><td>Metamod plugin</td></tr> | |
| 22 | +<tr><td>Config file</td><td><code>dproto.cfg</code></td><td><code>reunion.cfg</code></td></tr> | |
| 23 | +<tr><td>Mandatory salt</td><td>No</td><td>Yes — <code>SteamIdHashSalt</code> 16+ chars</td></tr> | |
| 24 | +<tr><td>Protocol 47 + 48</td><td>Yes</td><td>Yes</td></tr> | |
| 25 | +<tr><td>Maintenance status</td><td>Legacy, stable</td><td>Actively maintained with ReHLDS</td></tr> | |
| 26 | +<tr><td>Modern AMXX behaviour</td><td>Adequate</td><td>Better-behaved</td></tr> | |
| 27 | +</tbody></table> | |
| 28 | + | |
| 29 | +<h2>3. SteamID handling</h2> | |
| 30 | +<p>Both generate a <code>STEAM_</code> id for non-Steam players and pass real Steam ids through. The difference is configuration discipline. Reunion forces the decision on you: no <a href="/tutorials/configure-reunion-cfg">SteamIdHashSalt</a> of 16+ characters and it will not start, which is annoying once but guarantees stable, salted ids. dproto is more permissive — it starts without a salt — but its <a href="/tutorials/configure-dproto-cfg">id-generation mode</a> still has to be chosen deliberately or you get name-based collisions. In both, the golden rule is identical: pick your id source once and never change it, or every non-Steam player's admin access, stats and bans reset. Wrong-id symptoms are covered in <a href="/tutorials/fix-reunion-wrong-steamids">wrong SteamIDs</a>.</p> | |
| 31 | + | |
| 32 | +<h2>4. Protocol 47 and 48</h2> | |
| 33 | +<p>Neither forces you to choose between old and new clients. Both answer protocol 48 (Steam and current non-Steam) and protocol 47 (older non-Steam) on the same port, so your audience is not split by client build. When a specific client is bounced, it is a <a href="/tutorials/fix-protocol-mismatch-47-48">protocol configuration</a> issue in either tool, not a reason to switch products.</p> | |
| 34 | + | |
| 35 | +<h2>5. Why Reunion wins in 2026</h2> | |
| 36 | +<p>The honest recommendation for a new server is <strong>ReHLDS + Reunion</strong>. ReHLDS is faster and actively maintained, Reunion is developed alongside it, and the pair behaves better with current AMX Mod X than dproto on the old engine. If you are standing up a server today, install <a href="/tutorials/install-rehlds-on-linux">ReHLDS</a>, then Reunion, and you are on the maintained path with security fixes still landing. dproto remains the correct answer for one situation only: you are committed to running stock Valve HLDS and cannot migrate. It still works, it is stable, and it accepts non-Steam clients — but it is a legacy choice, not a forward-looking one.</p> | |
| 37 | + | |
| 38 | +<h2>6. Do not run both</h2> | |
| 39 | +<p>Whichever you pick, run exactly one. dproto and Reunion both hook the connection handshake, and loading them together makes them fight over the same clients, producing random rejections that look like a dozen other problems. If you migrate from HLDS to ReHLDS, remove dproto from <code>addons/metamod/plugins.ini</code> entirely before adding Reunion — do not leave it commented-in "just in case." Confirm with <code>meta list</code> that only one non-Steam provider is loaded.</p> | |
| 40 | + | |
| 41 | +<h2>Common errors</h2> | |
| 42 | +<ul> | |
| 43 | +<li><strong>Chose a tool by reputation, not engine</strong> — the engine decides. ReHLDS uses Reunion, HLDS uses dproto.</li> | |
| 44 | +<li><strong>Both loaded at once</strong> — clients rejected unpredictably. Remove one from <code>plugins.ini</code>.</li> | |
| 45 | +<li><strong>Reunion will not start</strong> — missing or short <code>SteamIdHashSalt</code>. dproto has no such requirement, which trips people migrating between the two.</li> | |
| 46 | +<li><strong>Switched tools and lost every admin</strong> — the two derive ids differently, so migrating changes non-Steam ids. Re-map admin entries to the new ids.</li> | |
| 47 | +<li><strong>dproto on ReHLDS "sort of works"</strong> — it will bite you later. Move to Reunion.</li> | |
| 48 | +</ul> | |
| 49 | + | |
| 50 | +<h2>Verification</h2> | |
| 51 | +<p>Run <code>rehlds_version</code> to confirm your engine, then <code>meta list</code> to confirm exactly one provider — Reunion on ReHLDS or dproto on HLDS — is loaded and running. Connect one Steam and one non-Steam client and check <code>status</code>: both should join and hold a stable id. If that works with a single provider on the matching engine, you are on the right tool and can stop second-guessing the choice.</p> |
fix-wad-not-found-compile/en.md
A
| @@ -0,0 +1,10 @@ | ||
| 1 | +--- | |
| 2 | +title: "Fix: 'Could not open wad file' During Compile" | |
| 3 | +excerpt: "Why hlcsg cannot find a WAD referenced by the map, and how to correct the wad key paths, use relative paths, or copy WADs locally so the compile completes." | |
| 4 | +category: "mapping" | |
| 5 | +tags: "wad, compiling" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>Your compile stops early in <code>hlcsg</code> with:</p><pre>Error: Could not open wad file mytextures.wad</pre><p>This is the first tool in the chain telling you it cannot find a <code>.wad</code> the map depends on. <code>hlcsg</code> needs every referenced WAD to read texture data and decide what to embed. The WAD list comes from two places — the map's <code>worldspawn</code> "wad" key (the list the editor saved) and any <code>-wad</code>/<code>-wadinclude</code> flags you pass — and one of those paths does not resolve on the machine running the compile. The fix is to make the paths correct and present.</p><h2>1. See which WAD it cannot open</h2><p>The error names the file. That is the WAD whose path is wrong. There may be several such lines; fix all of them. The path in the error is exactly what <code>hlcsg</code> tried to open, so if it reads an absolute path from another PC, that is your clue.</p><h2>2. Inspect the map's wad key</h2><p>The editor stores the WAD list in <code>worldspawn</code>. In Valve Hammer this is <strong>Map → Map Properties → wad</strong>; the value is a semicolon-separated list of absolute paths saved when you set up the game config:</p><pre>wad: "C:\games\cstrike\halflife.wad;C:\games\cstrike\cstrike.wad;C:\maps\mytextures.wad"</pre><p>Every path in that list must exist on the compiling machine. If you moved the project, changed drives, or compile on a different PC than you edit on, these absolute paths break — hence the error. Update them to where the WADs actually are.</p><h2>3. Prefer relative paths or -wad flags</h2><p>Absolute paths baked into the map are fragile. Two robust alternatives:</p><ul><li>Copy every WAD the map uses into one folder next to the compiler and pass them explicitly, so the map's stored list is overridden by what you control:</li></ul><pre>hlcsg -wadconfig mycfg mymap | |
| 10 | +hlcsg -wadinclude mytextures mymap</pre><ul><li>Or keep the WADs beside the <code>.map</code>/<code>.bsp</code> and use relative paths in the wad key. As long as <code>hlcsg</code>'s working directory can reach them, they open. This makes the project portable between machines.</li></ul><p>The compiler reads the wad key first; make sure it points at real files or strip the stale entries. See <a href="/tutorials/zhlt-vhlt-compile-parameters">the compile parameters guide</a> for how <code>-wad</code> interacts with the map's list.</p><h2>4. Copy the WADs locally</h2><p>The simplest reliable fix: gather <code>halflife.wad</code>, <code>cstrike.wad</code>, and every custom WAD into the folder you compile from, then set the wad key to those local copies. Now nothing depends on another drive or another PC. This is especially important when you compile on a build server or a friend's machine that does not have your original texture folders.</p><h2>5. Remove references to WADs you no longer use</h2><p>If you deleted a WAD from the project but its path is still in the wad key, <code>hlcsg</code> will fail trying to open a file that no longer exists. Open Map Properties and delete the dead entries from the wad list so the compiler only looks for WADs the map actually needs.</p><h2>6. Watch for path separators and spaces</h2><p>The wad key uses semicolons to separate entries and (on Windows) backslashes inside each path. A stray forward slash, a missing semicolon that fuses two paths into one, or a folder name with a space that the tool cannot parse all produce the same could-not-open error. If the path in the error looks subtly wrong — two WAD names run together, or a mangled directory — edit the wad key by hand in a text editor: the <code>.map</code>/<code>.rmf</code> stores it as plain text you can correct directly. Rebuild the list cleanly if it has accumulated cruft over many edits.</p><h2>Common errors</h2><ul><li><strong><code>Error: Could not open wad file ...wad</code></strong> — the named path does not resolve. Fix it in Map Properties or copy the WAD locally.</li><li><strong>Path in the error is from another computer</strong> — absolute paths were saved on a different machine. Repoint the wad key or use local relative paths.</li><li><strong>Compile finds stock WADs but not the custom one</strong> — the custom WAD moved or was never copied to the compile machine. Put it beside the compiler.</li><li><strong>Fixed one path, another WAD fails</strong> — there are multiple entries; correct every path in the list.</li><li><strong>Removed a WAD but it still errors</strong> — its dead entry is still in the wad key. Delete the entry.</li></ul><h2>Verification</h2><p>Re-run <code>hlcsg</code> alone and confirm it reads past the WAD-loading stage without the error, listing each WAD it opened. Then run the full chain and load the map to check textures resolve — a compile that could not open a WAD often produced black faces even where it limped through. If it compiles clean on your machine but you plan to build elsewhere, move the whole project (map + WADs + relative paths) to that machine and compile again to prove it is portable. For delivering the map afterwards, see <a href="/tutorials/wadinclude-vs-external-wads">wadinclude vs external WADs</a>.</p> |
install-csdm/en.md
A
| @@ -0,0 +1,68 @@ | ||
| 1 | +--- | |
| 2 | +title: "How to Install CSDM (Deathmatch) on CS 1.6" | |
| 3 | +excerpt: "Install CSDM on top of Metamod and AMX Mod X, enable respawning and weapon menus through csdm.cfg, and get instant-action deathmatch running cleanly." | |
| 4 | +category: "installation" | |
| 5 | +tags: "csdm, deathmatch" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>CSDM turns a normal round-based CS 1.6 server into instant-respawn deathmatch: players spawn immediately after dying, pick weapons from a menu, and fight continuously. It runs on top of <a href="/tutorials/install-metamod-r">Metamod</a> and <a href="/tutorials/install-amx-mod-x-1-9">AMX Mod X</a>, hooking the engine to override the standard round flow. This walks through a correct install and the config that actually enables respawning.</p> | |
| 10 | +<h2>1. Confirm the prerequisites</h2> | |
| 11 | +<p>CSDM will not load without both Metamod and AMX Mod X already working. Verify from the server console:</p> | |
| 12 | +<pre>meta list | |
| 13 | +amxx version</pre> | |
| 14 | +<p><code>meta list</code> must show Metamod running with AMX Mod X loaded beneath it. If either is missing, install them first — CSDM has nothing to attach to otherwise.</p> | |
| 15 | +<h2>2. Extract CSDM into the game folder</h2> | |
| 16 | +<p>CSDM ships as a package of AMX Mod X plugins plus a supporting module and config files. Extract it so the pieces land under <code>cstrike/</code>:</p> | |
| 17 | +<ul> | |
| 18 | +<li>The plugin binaries (<code>csdm_main.amxx</code>, <code>csdm_equip.amxx</code>, <code>csdm_spawn_preset.amxx</code>, <code>csdm_misc.amxx</code>, <code>csdm_ffa.amxx</code>, <code>csdm_protection.amxx</code>) go in <code>addons/amxmodx/plugins/</code>.</li> | |
| 19 | +<li>The CSDM config, <code>csdm.cfg</code>, goes in <code>addons/amxmodx/configs/</code>.</li> | |
| 20 | +</ul> | |
| 21 | +<p>Keep the exact filenames from the package — the plugins reference each other by name.</p> | |
| 22 | +<h2>3. Register the plugins</h2> | |
| 23 | +<p>Add the CSDM plugins to <code>addons/amxmodx/configs/plugins.ini</code>. The main plugin must be present; the others are optional features:</p> | |
| 24 | +<pre>csdm_main.amxx ; core deathmatch + respawn | |
| 25 | +csdm_equip.amxx ; weapon-select menu on spawn | |
| 26 | +csdm_spawn_preset.amxx ; preset spawn points per map | |
| 27 | +csdm_misc.amxx ; ammo refill, extras | |
| 28 | +csdm_protection.amxx ; brief spawn protection | |
| 29 | +; csdm_ffa.amxx ; enable for free-for-all (no teams)</pre> | |
| 30 | +<p>Load order is fine as listed. See <a href="/tutorials/install-amxx-plugin-files">installing AMXX plugin files</a> for the general procedure.</p> | |
| 31 | +<h2>4. Enable CSDM in csdm.cfg</h2> | |
| 32 | +<p>This is the step people miss: the plugins load but do nothing until CSDM is switched on in its config. Edit <code>addons/amxmodx/configs/csdm.cfg</code>:</p> | |
| 33 | +<pre>// master switch - CSDM is OFF until this is 1 | |
| 34 | +csdm_active 1 | |
| 35 | + | |
| 36 | +// respawn behaviour | |
| 37 | +csdm_respawn_wait 0 // seconds before respawn (0 = instant) | |
| 38 | + | |
| 39 | +// spawning mode: use the preset spawn points | |
| 40 | +spawnmode preset | |
| 41 | + | |
| 42 | +// give a weapons menu when players spawn | |
| 43 | +enabled equipment</pre> | |
| 44 | +<p>The <code>csdm_active 1</code> line is the master switch; leaving it at <code>0</code> is the classic "I installed CSDM and nothing respawns" cause. Adjust the respawn delay to taste — <code>0</code> for frantic instant deathmatch, a second or two for a calmer feel.</p> | |
| 45 | +<h2>5. Tune the round for deathmatch</h2> | |
| 46 | +<p>Deathmatch feels wrong with the normal buy time and round economy. In <a href="/tutorials/setup-server-cfg-cs16">server.cfg</a> or a map config:</p> | |
| 47 | +<pre>mp_freezetime 0 | |
| 48 | +mp_roundtime 9 | |
| 49 | +mp_buytime 9999 | |
| 50 | +mp_startmoney 16000</pre> | |
| 51 | +<p>Zero freeze time keeps the action continuous; a long round time stops the map cutting deathmatch short. CSDM's own equip menu usually replaces buying, but generous buy settings avoid awkward money limits.</p> | |
| 52 | +<h2>6. Change the map to load it</h2> | |
| 53 | +<p><code>plugins.ini</code> and <code>csdm.cfg</code> are read on map load, so restart or change the map after editing:</p> | |
| 54 | +<pre>changelevel de_dust2</pre> | |
| 55 | +<p>For a stronger spawn-protection window or a respawn-on-join style, the standalone <a href="/plugins/csb-spawn-protection">CSB Spawn Protection</a> and <a href="/plugins/csb-respawn-on-join">CSB Respawn on Join</a> plugins complement CSDM. If you want a self-contained respawn system without the full CSDM package, <a href="/plugins/csb-csdm-respawn">CSB CSDM Respawn</a> is a lighter alternative.</p> | |
| 56 | +<h2>Understanding the spawn modes</h2> | |
| 57 | +<p>The <code>spawnmode</code> setting in <code>csdm.cfg</code> decides where players reappear, and it is the setting most worth understanding. <strong>Preset</strong> spawns use fixed points defined for each map — the cleanest option, giving predictable, well-spaced spawns, but it only works on maps that have a preset spawn file. Other modes fall back to the map's original spawn entities or spread players around dynamically. On a map without presets, choosing <code>preset</code> lands everyone at the same origin or inside geometry, which is the usual cause of players spawning stuck in a wall. If a map has no presets and you cannot make them, use a non-preset mode for that map, or supply a preset spawn file. Preset spawns are what make deathmatch feel fair on the popular maps, so most CSDM servers ship spawn files for their whole rotation.</p> | |
| 58 | +<h2>Why the equip menu matters</h2> | |
| 59 | +<p>The <code>csdm_equip</code> plugin replaces the normal buy economy with a weapon menu shown on each spawn, which is what makes deathmatch flow — nobody wants to open the buy menu and count money between instant respawns. Configure which weapons the menu offers through the equipment section of <code>csdm.cfg</code>; a tight menu (a few rifles and pistols) keeps the mode focused, while an open one lets players grab an AWP every spawn. This is a deliberate design lever, not a detail: the weapon menu defines the character of your deathmatch server.</p> | |
| 60 | +<h2>Troubleshooting</h2> | |
| 61 | +<ul> | |
| 62 | +<li><strong>Plugins load but nobody respawns</strong> — <code>csdm_active</code> is <code>0</code> in <code>csdm.cfg</code>. Set it to <code>1</code> and change map. Full diagnosis in <a href="/tutorials/fix-csdm-not-respawning">CSDM not respawning</a>.</li> | |
| 63 | +<li><strong>Players spawn stuck inside walls or all in one spot</strong> — the map has no preset spawns; switch <code>spawnmode</code> to a non-preset mode or add spawn points for that map.</li> | |
| 64 | +<li><strong>No weapon menu on spawn</strong> — <code>csdm_equip.amxx</code> is not in <code>plugins.ini</code> or equipment is disabled in <code>csdm.cfg</code>.</li> | |
| 65 | +<li><strong><code>csdm_main.amxx</code> shows <code>bad load</code></strong> in <code>amxx plugins</code> — the CSDM module is missing or AMX Mod X is the wrong version. Reinstall the matching package.</li> | |
| 66 | +</ul> | |
| 67 | +<h2>Verification</h2> | |
| 68 | +<p>Join the server, get killed, and confirm you respawn within your configured delay with the weapon menu appearing. Run <code>amxx plugins</code> and check that every <code>csdm_*</code> plugin reads <code>running</code>, not <code>paused</code> or <code>bad load</code>. If respawning works and the equip menu pops on spawn, CSDM is installed correctly.</p> |
install-pterodactyl-cs16-egg/en.md
A
| @@ -0,0 +1,42 @@ | ||
| 1 | +--- | |
| 2 | +title: "How to Set Up a CS 1.6 Server on Pterodactyl (Egg + Wings)" | |
| 3 | +excerpt: "Import a CS 1.6 egg, create the server, set the startup variables, and let Wings run SteamCMD and launch HLDS in a container." | |
| 4 | +category: "installation" | |
| 5 | +tags: "pterodactyl, panel" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>Pterodactyl is a web game-server panel: an admin UI (the Panel) plus a per-node daemon called <strong>Wings</strong> that actually runs each server inside a Docker container. A game is described by an <em>egg</em> — a JSON definition that specifies the install script and the startup command. This guide adds a CS 1.6 server to an existing Pterodactyl install by importing an egg and creating a server from it. It assumes the Panel and Wings are already installed and a node is configured.</p> | |
| 10 | +<h2>1. Understand the moving parts</h2> | |
| 11 | +<p>Three pieces cooperate: the <strong>Panel</strong> (the web app and database), <strong>Wings</strong> (the daemon on each node that pulls a Docker image and runs the server in it), and the <strong>egg</strong> (the recipe). When you create a CS 1.6 server, the egg's install script runs SteamCMD to download app 90 into the server's data directory, and the egg's startup line tells Wings how to launch <code>hlds</code>. CS 1.6 is 32-bit, so the egg must use a Docker image that provides 32-bit libraries.</p> | |
| 12 | +<h2>2. Import the CS 1.6 egg</h2> | |
| 13 | +<p>In the Panel, go to <strong>Admin, Nests, Import Egg</strong> and upload the egg JSON. An egg for HLDS/CS 1.6 defines:</p> | |
| 14 | +<ul> | |
| 15 | +<li>An <strong>install script</strong> that runs <code>steamcmd +login anonymous +app_update 90 validate +quit</code> against the server directory.</li> | |
| 16 | +<li>A <strong>Docker image</strong> with 32-bit runtime libraries (a Steam/SteamCMD image).</li> | |
| 17 | +<li>A <strong>startup command</strong> such as <code>./hlds_run -game cstrike +map {{SRCDS_MAP}} +maxplayers {{MAX_PLAYERS}} -port {{SERVER_PORT}}</code>.</li> | |
| 18 | +<li><strong>Variables</strong> the UI exposes: map, max players, and so on.</li> | |
| 19 | +</ul> | |
| 20 | +<p>Assign the imported egg to a nest so it appears when you create a server.</p> | |
| 21 | +<h2>3. Create the server</h2> | |
| 22 | +<p>Go to <strong>Admin, Servers, Create New</strong>, pick the node and an allocation (the IP and port — CS 1.6 defaults to UDP <code>27015</code>), choose the CS 1.6 egg, and set resource limits. Give it enough memory (256 to 512 MB is plenty for CS 1.6) and disk for the roughly 1 GB of game files. On save, Wings creates the container and runs the egg's install script.</p> | |
| 23 | +<h2>4. Set the startup variables</h2> | |
| 24 | +<p>Once created, open the server's <strong>Startup</strong> tab. The variables the egg declared appear as fields:</p> | |
| 25 | +<pre>Server Map: de_dust2 | |
| 26 | +Max Players: 20 | |
| 27 | +Server Port: 27015</pre> | |
| 28 | +<p>These map onto the <code>{{SRCDS_MAP}}</code>, <code>{{MAX_PLAYERS}}</code> and <code>{{SERVER_PORT}}</code> placeholders in the startup command. The port must match the allocation you assigned; a mismatch is a common reason the server starts but never appears in the browser.</p> | |
| 29 | +<h2>5. Wait for the install to finish</h2> | |
| 30 | +<p>The install script runs once, in a separate installer container, and streams to the <strong>Install</strong> log. It is downloading app 90 via SteamCMD — the same <code>app_update 90</code> covered in the <a href="/tutorials/install-steamcmd-linux">SteamCMD guide</a>, just executed by Wings. Do not start the server until the panel marks the install complete; starting mid-install produces a server missing its <code>cstrike</code> files.</p> | |
| 31 | +<h2>6. Start the server</h2> | |
| 32 | +<p>Hit <strong>Start</strong> on the console tab. Wings launches the startup command inside the container and streams the HLDS console. You should see the map load and the <code>Console initialized</code> banner. The web console is a full RCON-style console: type <code>status</code> and you get the same output as a local server.</p> | |
| 33 | +<h2>Troubleshooting</h2> | |
| 34 | +<ul> | |
| 35 | +<li><strong>Server stuck "installing" or install fails</strong> — SteamCMD could not reach Steam or the disk quota is too small. Check the Install log; raise disk and retry.</li> | |
| 36 | +<li><strong>Starts then immediately crashes / will not start</strong> — usually a wrong startup command, a missing 32-bit Docker image, or the <code>cstrike</code> files not fully downloaded. Work through <a href="/tutorials/fix-pterodactyl-cs16-wont-start">the CS 1.6 on Pterodactyl won't-start fix</a>.</li> | |
| 37 | +<li><strong>Server runs but is invisible in the browser</strong> — the startup <code>-port</code> does not match the allocation, or <code>sv_lan 1</code>. Align the port and set <code>sv_lan 0</code>.</li> | |
| 38 | +<li><strong>"Segmentation fault" on start</strong> — the Docker image lacks 32-bit libs. Use a SteamCMD image that provides them.</li> | |
| 39 | +<li><strong>Config changes do not persist</strong> — you edited files inside the container instead of via the panel's file manager; edit under the server's data directory so they survive a rebuild.</li> | |
| 40 | +</ul> | |
| 41 | +<h2>Verification</h2> | |
| 42 | +<p>With the server started, type <code>status</code> in the panel console and confirm it reports the map and <code>players : 0</code>. From a client, add the node IP and the allocation port and confirm the server appears and is joinable. Then stop and start it from the panel to confirm the container cycles cleanly. If you would rather run CS 1.6 in a container without a full panel, the <a href="/tutorials/install-cs16-server-docker">plain Docker guide</a> covers the same image without Pterodactyl on top.</p> | |
| 0 | 43 |
