Add 6 tutorials (6 files)
Browse Source
Daemon666 committed
parent e484633b8f
commit e202b6bd31160572b862ef46d9d24a305eb6f853
6 changed files
with 208 additions and 0 deletions
A
decompile-a-bsp/en.md
+9 -0
A
install-cs16-server-debian-12/en.md
+67 -0
A
install-hlds-without-root/en.md
+62 -0
A
metamod-plugins-ini-explained/en.md
+44 -0
A
package-map-for-fastdl/en.md
+17 -0
A
where-to-find-plugins-help/en.md
+9 -0
decompile-a-bsp/en.md
A
| @@ -0,0 +1,9 @@ | ||
| 1 | +--- | |
| 2 | +title: "Decompiling a BSP: What Works and What Breaks" | |
| 3 | +excerpt: "How BSP decompilers reconstruct a .map from a compiled GoldSrc map, why the result has off-grid vertices, lost entity keyvalues and damaged brushwork, and the ethics of only decompiling your own maps." | |
| 4 | +category: "mapping" | |
| 5 | +tags: "decompiling, bsp" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>Decompiling turns a compiled <code>.bsp</code> back into an editable <code>.map</code> you can open in a Hammer/JACK. It is genuinely useful for recovering your own lost source, or for studying how something was built — but it is a lossy, one-way street done backwards. The BSP does not contain your original brushes; it contains the compiler's <em>output</em>, and a decompiler reverse-engineers brushes from that. Understanding what survives and what does not saves you hours of chasing artifacts. First, the ethics.</p><h2>1. Only decompile maps you have the right to</h2><p>Compiling is deliberately one-way; a mapper who ships only a BSP has chosen not to release their source. Decompiling someone else's map to re-release it, or to strip credit, is theft of their work and is treated that way by the mapping community. The legitimate uses are narrow: recovering the source to a map <em>you</em> made and lost, or learning technique from a map whose author permits it. Do that and nothing here is a problem; do the other thing and you have made an enemy of every mapper.</p><h2>2. Pick a decompiler</h2><p>The established GoldSrc BSP decompilers are tools like <strong>BSPTwoMAP</strong> and <strong>Winbspc</strong>. They read a v30 GoldSrc BSP and emit a <code>.map</code>. They differ in how they reconstruct brushes and how much entity data they preserve, so if one produces unusable geometry, trying the other is worth it. Run it against the BSP and open the resulting <code>.map</code> in your editor.</p><h2>3. Expect off-grid, ugly brushwork</h2><p>This is the big one. The compiler splits your clean brushes into rendering faces and throws away the original brush definitions. The decompiler rebuilds brushes by guessing, and the result is:</p><ul><li><strong>Off-grid vertices</strong> — corners land on fractional coordinates instead of the grid, so nothing snaps cleanly and editing is painful.</li><li><strong>Fragmented geometry</strong> — one original brush comes back as several pieces, and complex shapes come back as tangled invalid solids.</li><li><strong>Invalid / concave solids</strong> that will not re-compile without cleanup.</li></ul><p>The takeaway: a decompiled map is a <em>reference</em> or a <em>recovery starting point</em>, not a clean source you can tweak and recompile as-is.</p><h2>4. Expect lost and mangled entity data</h2><p>Point entities usually survive with their positions, but a lot of their <em>keyvalues</em> do not. Custom keys, targetnames, and settings the compiler baked in or dropped come back missing or wrong. Lighting is a special case: the lightmaps are baked into the BSP and cannot be turned back into light entities, so a decompiled map often loses its light setup or produces a fullbright re-compile. You will be re-doing lighting from scratch.</p><h2>5. Expect texture and WAD issues</h2><p>The BSP references textures by name and may or may not contain the texture data (depending on whether the original used <code>-wadinclude</code>). After decompiling you often have to re-point the map at the right WADs, and any embedded textures may need extracting. Missing textures show as the usual missing-texture placeholder until you sort the WAD references — see <a href="/tutorials/cs16-cannot-find-wad">cannot find WAD</a>.</p><h2>6. Clean up before recompiling</h2><p>If your goal is a working re-compile (recovering your own map), budget real cleanup time: snap vertices back to the grid, delete and rebuild the worst brushes, re-seal any leaks the fragmentation introduced (a decompiled map frequently leaks), re-add lighting, and fix entity keys. Treat it as a renovation of a rough draft, not a finished file. A leak from the mangled brushwork is common; the <a href="/tutorials/fix-leak-in-hull-pointfile">leak and pointfile guide</a> will be your friend.</p><h2>Common errors</h2><ul><li><strong>Decompiled map will not compile / leaks everywhere</strong> — the fragmented brushwork left gaps in the world hull. Rebuild the offending brushes and chase the leak with the pointfile.</li><li><strong>Everything is off-grid and impossible to edit</strong> — expected. Snap vertices to the grid and rebuild the worst solids by hand.</li><li><strong>Lights are gone / re-compile is fullbright</strong> — baked lightmaps cannot be decompiled into entities. Re-light the map from scratch per <a href="/tutorials/cs16-map-lighting-basics">the lighting guide</a>.</li><li><strong>Missing textures on load</strong> — the WAD references did not survive. Re-point the map at the correct WADs.</li><li><strong>Entity does not behave like the original</strong> — keyvalues were lost in decompilation. Re-enter them by hand.</li></ul><h2>Verification</h2><p>Open the decompiled <code>.map</code> and assess honestly: is the geometry close enough to salvage, or is it faster to rebuild? For a recovery job, clean the brushwork, re-light, fix entities, and attempt a full compile — then load the result and compare it against the original BSP room by room. If it compiles, runs, and matches, the recovery worked. If the brushwork is hopeless, you have at least a spatial reference to rebuild from. And if the map was never yours to begin with, the right verification is simply not to have decompiled it.</p> |
install-cs16-server-debian-12/en.md
A
| @@ -0,0 +1,67 @@ | ||
| 1 | +--- | |
| 2 | +title: "Install a CS 1.6 Server on Debian 12" | |
| 3 | +excerpt: "A step-by-step CS 1.6 dedicated server install on Debian 12 (bookworm): enabling i386, installing the 32-bit libraries HLDS needs, downloading the game files with SteamCMD, and first launch." | |
| 4 | +category: "installation" | |
| 5 | +tags: "debian, linux" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>Debian 12 "bookworm" is a clean, stable base for a CS 1.6 server, but HLDS is a 32-bit binary, so the one thing that trips people up on a fresh 64-bit Debian is the missing i386 libraries. This walks through the whole install: enable multi-arch, install the 32-bit runtime, pull the game files with SteamCMD, and launch under a non-root user.</p> | |
| 10 | + | |
| 11 | +<h2>1. Update and create a service user</h2> | |
| 12 | +<p>Never run a game server as root. As root, update the system and make a dedicated user:</p> | |
| 13 | +<pre>apt update && apt upgrade -y | |
| 14 | +adduser --disabled-password --gecos "" csserver</pre> | |
| 15 | +<p>Everything from here on runs as <code>csserver</code>. Switch to it:</p> | |
| 16 | +<pre>su - csserver</pre> | |
| 17 | + | |
| 18 | +<h2>2. Enable the i386 architecture</h2> | |
| 19 | +<p>HLDS and SteamCMD are 32-bit. On 64-bit Debian you must add the i386 architecture before the libraries are installable. As root:</p> | |
| 20 | +<pre>dpkg --add-architecture i386 | |
| 21 | +apt update</pre> | |
| 22 | +<p>Skip this and the 32-bit packages in the next step simply will not be found, and HLDS later fails to start with a loader error about a missing library.</p> | |
| 23 | + | |
| 24 | +<h2>3. Install the 32-bit libraries and tools</h2> | |
| 25 | +<p>As root, install the runtime HLDS needs plus the tools to fetch it:</p> | |
| 26 | +<pre>apt install -y lib32gcc-s1 lib32stdc++6 ca-certificates curl tar</pre> | |
| 27 | +<p><code>lib32gcc-s1</code> and <code>lib32stdc++6</code> are the 32-bit C/C++ runtimes the engine links against — the two libraries whose absence causes the classic <em>error while loading shared libraries</em> on first launch. <code>ca-certificates</code> lets SteamCMD validate its TLS connection.</p> | |
| 28 | + | |
| 29 | +<h2>4. Install SteamCMD</h2> | |
| 30 | +<p>Back as <code>csserver</code>, download and unpack SteamCMD into its own folder:</p> | |
| 31 | +<pre>mkdir -p ~/steamcmd && cd ~/steamcmd | |
| 32 | +curl -sqL "https://steamcdn-a.akamaihd.net/client/installer/steamcmd_linux.tar.gz" | tar zxvf -</pre> | |
| 33 | +<p>The general SteamCMD setup, including the Valve-hosted download, is covered in <a href="/tutorials/install-steamcmd-linux">installing SteamCMD on Linux</a> if you want the detail. Run it once to let it self-update:</p> | |
| 34 | +<pre>./steamcmd.sh +quit</pre> | |
| 35 | + | |
| 36 | +<h2>5. Download the CS 1.6 server files</h2> | |
| 37 | +<p>The CS 1.6 dedicated server is Steam app <code>90</code>. Because app 90 is an old HLDS package, set its mod config to <code>cstrike</code> and validate. Run SteamCMD with an anonymous login:</p> | |
| 38 | +<pre>./steamcmd.sh +force_install_dir ~/hlds \ | |
| 39 | + +login anonymous \ | |
| 40 | + +app_set_config 90 mod cstrike \ | |
| 41 | + +app_update 90 validate \ | |
| 42 | + +quit</pre> | |
| 43 | +<p>App 90 is notorious for needing a few retries — if it stops partway, run the exact same command again and it resumes. Keep going until it reports the install as fully up to date. For the safety considerations around where server files come from, see <a href="/tutorials/download-cs16-server-files-safely">downloading server files safely</a>.</p> | |
| 44 | + | |
| 45 | +<h2>6. First launch</h2> | |
| 46 | +<p>Change into the install and start HLDS with a sane command line:</p> | |
| 47 | +<pre>cd ~/hlds | |
| 48 | +./hlds_run -game cstrike +ip 0.0.0.0 -port 27015 \ | |
| 49 | + +map de_dust2 +maxplayers 20 +sv_lan 0</pre> | |
| 50 | +<p><code>sv_lan 0</code> is required to reach the master list; the default <a href="/tutorials/change-cs16-server-port">port 27015</a> is UDP. If it boots to the console and prints the map loading, the install works. From here, consider swapping HLDS for <a href="/tutorials/install-rehlds-on-linux">ReHLDS</a> for performance, and set up a <a href="/tutorials/hlds-systemd-service">systemd service</a> so it survives reboots.</p> | |
| 51 | + | |
| 52 | +<h2>7. Open the firewall and lock down access</h2> | |
| 53 | +<p>A running server that nobody can reach is a firewall problem. Debian 12 ships without a running firewall by default, but a VPS provider often adds one. If you use <code>ufw</code>, allow the game port as UDP:</p> | |
| 54 | +<pre>ufw allow 27015/udp</pre> | |
| 55 | +<p>CS 1.6 is UDP-only, so a TCP rule passes nothing — a frequent cause of "the server runs but the browser never sees it." Set a strong <code>rcon_password</code> in <a href="/tutorials/setup-server-cfg-cs16">server.cfg</a> before you expose the box, because an open RCON port on a public IP is found within hours. The full port list, including the master-server ports, is in <a href="/tutorials/cs16-server-firewall-ports">the firewall ports guide</a>.</p> | |
| 56 | + | |
| 57 | +<h2>Common errors</h2> | |
| 58 | +<ul> | |
| 59 | +<li><strong><code>error while loading shared libraries: libstdc++.so.6</code></strong> — the 32-bit libraries are missing. Enable i386 and install <code>lib32gcc-s1</code> and <code>lib32stdc++6</code>.</li> | |
| 60 | +<li><strong>SteamCMD: <code>Failed to install app '90' (Missing file permissions)</code></strong> — you ran it as root earlier and the files are root-owned. Fix ownership: <code>chown -R csserver:csserver ~/hlds</code>.</li> | |
| 61 | +<li><strong>app_update 90 stalls or errors partway</strong> — a known app-90 quirk. Re-run the identical command; it resumes.</li> | |
| 62 | +<li><strong>Server starts but is not in the browser</strong> — <code>sv_lan 1</code>, or UDP 27015 is closed. Set <code>sv_lan 0</code> and open the port; see <a href="/tutorials/cs16-server-firewall-ports">firewall ports</a> and <a href="/tutorials/fix-server-not-in-master-list">server not in master list</a>.</li> | |
| 63 | +<li><strong><code>hlds_run: not found</code> even though it exists</strong> — a 32-bit loader is missing, or you are in the wrong directory. Confirm the i386 libs and run from <code>~/hlds</code>.</li> | |
| 64 | +</ul> | |
| 65 | + | |
| 66 | +<h2>Verification</h2> | |
| 67 | +<p>With the server running, from another machine open the console in CS and <code>connect <server-ip>:27015</code>. You should join and see <code>de_dust2</code>. On the server, <code>status</code> lists you as a player. Then confirm it appears in the internet server browser after a minute — if you can join from outside and it lists publicly, the Debian 12 install is complete and you can move on to a systemd service and ReHLDS.</p> |
install-hlds-without-root/en.md
A
| @@ -0,0 +1,62 @@ | ||
| 1 | +--- | |
| 2 | +title: "How to Install HLDS as a Non-Root User (Best Practice)" | |
| 3 | +excerpt: "Run HLDS under a dedicated unprivileged user, set the right ownership, and use a systemd unit that drops privileges — the correct, secure way to host CS 1.6." | |
| 4 | +category: "installation" | |
| 5 | +tags: "linux, permissions" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>Running a game server as <code>root</code> is a habit worth breaking permanently. HLDS parses untrusted network traffic from anyone on the internet; if a flaw is ever exploited, the attacker inherits whatever privileges the process holds. Run it as <code>root</code> and that is the whole machine. Run it as a locked-down user and the blast radius is one game server's files. There is no performance cost and no functional downside, so this is simply how it should be done.</p> | |
| 10 | +<h2>1. Why root is unnecessary here</h2> | |
| 11 | +<p>The one reason a service traditionally needs root is binding a port below 1024. HLDS uses <strong>UDP 27015</strong>, which is well above that range, so an unprivileged user can bind it without any special capability. There is nothing HLDS does that requires elevated privileges — the only reason people run it as root is that they installed as root and never switched.</p> | |
| 12 | +<h2>2. Create a dedicated user</h2> | |
| 13 | +<p>Make a user that exists only to run the server, with no login password and no shell privileges beyond what it needs:</p> | |
| 14 | +<pre>sudo adduser --disabled-password --gecos "" csserver</pre> | |
| 15 | +<p>Use a service-specific account, not your own login account — you want the server isolated from your personal files and SSH keys. Everything the server touches will be owned by <code>csserver</code>.</p> | |
| 16 | +<h2>3. Install everything as that user</h2> | |
| 17 | +<p>Switch to the new user and install SteamCMD and HLDS from there, so every file is created with the right ownership from the start:</p> | |
| 18 | +<pre>sudo su - csserver | |
| 19 | +mkdir -p ~/steamcmd ~/hlds | |
| 20 | +cd ~/steamcmd | |
| 21 | +curl -sqL "https://steamcdn-a.akamaihd.net/client/installer/steamcmd_linux.tar.gz" | tar zxf - | |
| 22 | +./steamcmd.sh +force_install_dir ~/hlds +login anonymous +app_update 90 validate +quit</pre> | |
| 23 | +<p>Installing as <code>csserver</code> avoids the most common mistake: installing as root and later getting <code>Permission denied</code> when the game process cannot write its own logs or download files. The full install is in <a href="/tutorials/install-cs16-dedicated-server-linux-steamcmd">the SteamCMD guide</a>; the 32-bit libraries it needs are in <a href="/tutorials/install-32bit-libraries-cs16-linux">32-bit libraries for CS 1.6</a>.</p> | |
| 24 | +<h2>4. If you already installed as root, fix ownership</h2> | |
| 25 | +<p>Inherited a root-owned install? Do not reinstall — just hand it to the new user:</p> | |
| 26 | +<pre>sudo chown -R csserver:csserver /home/csserver/hlds</pre> | |
| 27 | +<p>Then always start the server as <code>csserver</code>, never with <code>sudo</code>. A single root-owned file in the tree (often a log or <code>.dem</code> written during a root test) can cause a <code>Permission denied</code> later, so re-run the <code>chown</code> if anything misbehaves.</p> | |
| 28 | +<h2>5. Run it under systemd with dropped privileges</h2> | |
| 29 | +<p>The clean way to keep it non-root permanently is a systemd unit that sets <code>User=</code>, so the service can never run as root even if you start it as root. Create <code>/etc/systemd/system/hlds.service</code>:</p> | |
| 30 | +<pre>[Unit] | |
| 31 | +Description=CS 1.6 HLDS Server | |
| 32 | +After=network.target | |
| 33 | + | |
| 34 | +[Service] | |
| 35 | +Type=simple | |
| 36 | +User=csserver | |
| 37 | +Group=csserver | |
| 38 | +WorkingDirectory=/home/csserver/hlds | |
| 39 | +ExecStart=/home/csserver/hlds/hlds_run -game cstrike +map de_dust2 +maxplayers 24 -port 27015 | |
| 40 | +Restart=on-failure | |
| 41 | +RestartSec=5 | |
| 42 | + | |
| 43 | +[Install] | |
| 44 | +WantedBy=multi-user.target</pre> | |
| 45 | +<p>Enable and start it:</p> | |
| 46 | +<pre>sudo systemctl daemon-reload | |
| 47 | +sudo systemctl enable --now hlds</pre> | |
| 48 | +<p>The <code>User=csserver</code> line is the guarantee: systemd drops to that account before executing HLDS. A fuller unit with auto-restart tuning is in <a href="/tutorials/hlds-systemd-service">the HLDS systemd service guide</a>.</p> | |
| 49 | +<h2>6. Optional hardening</h2> | |
| 50 | +<p>Because the service is already unprivileged, you can add cheap systemd sandboxing on top — <code>NoNewPrivileges=true</code>, <code>ProtectSystem=strict</code> with a <code>ReadWritePaths=</code> for the game dir, and <code>PrivateTmp=true</code>. These cost nothing and further shrink what a compromised process could reach. Start with just <code>User=</code> though; that alone is the difference that matters.</p> | |
| 51 | +<h2>Troubleshooting</h2> | |
| 52 | +<ul> | |
| 53 | +<li><strong><code>Permission denied</code> writing logs or downloads</strong> — part of the tree is root-owned. Run the <code>chown -R csserver:csserver</code> from step 4.</li> | |
| 54 | +<li><strong>Service fails with <code>hlds_run: No such file or directory</code></strong> — the 32-bit loader is missing, not a permission issue. See <a href="/tutorials/fix-hlds-no-such-file-32bit">the fix</a>.</li> | |
| 55 | +<li><strong>Works when you run it manually as root but not under systemd</strong> — that is the point; fix ownership so it runs as <code>csserver</code> rather than reverting to root.</li> | |
| 56 | +<li><strong>Port bind fails</strong> — not a privilege problem on 27015; another process holds the port. Check with <code>ss -ulpn | grep 27015</code>.</li> | |
| 57 | +</ul> | |
| 58 | +<h2>Verification</h2> | |
| 59 | +<p>With the service running, confirm the process is not root:</p> | |
| 60 | +<pre>ps -o user= -C hlds_linux | |
| 61 | +systemctl status hlds</pre> | |
| 62 | +<p>The owner should read <code>csserver</code>, not <code>root</code>. Connect to the server to confirm it plays normally as an unprivileged process — it will, because nothing HLDS does needs root. If <code>ps</code> shows <code>csserver</code> and players can join, you are running the correct, secure way. Pair this with a <a href="/tutorials/choose-vps-for-cs16">well-chosen VPS</a> and a locked-down <a href="/tutorials/cs16-server-firewall-ports">firewall</a>.</p> |
metamod-plugins-ini-explained/en.md
A
| @@ -0,0 +1,44 @@ | ||
| 1 | +--- | |
| 2 | +title: "metamod/plugins.ini Explained (Paths, win32 vs linux)" | |
| 3 | +excerpt: "A precise breakdown of metamod/plugins.ini: the win32 vs linux platform columns, relative paths, and why it is not AMXX's plugins.ini." | |
| 4 | +category: "installation" | |
| 5 | +tags: "metamod, config" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>Metamod's <code>plugins.ini</code> is the file that tells Metamod which game-DLL plugins to load — AMX Mod X, bots like POD-Bot and YaPB, and any other Metamod plugin. It is small and its syntax is simple, but two things trip people up constantly: it is not the same file as AMXX's own <code>plugins.ini</code>, and each line has a platform column that must match your OS. This is a precise breakdown of the format.</p> | |
| 10 | +<h2>1. There are two files called plugins.ini</h2> | |
| 11 | +<p>This is the number-one confusion. There are two completely different <code>plugins.ini</code> files:</p> | |
| 12 | +<ul> | |
| 13 | +<li><strong><code>addons/metamod/plugins.ini</code></strong> — lists <em>Metamod</em> plugins (native DLLs/SOs): AMXX itself, bots, and similar. This is the file this guide is about.</li> | |
| 14 | +<li><strong><code>addons/amxmodx/configs/plugins.ini</code></strong> — lists <em>AMXX</em> plugins (Pawn <code>.amxx</code> files): admin.amxx, your custom plugins. Covered in <a href="/tutorials/plugins-ini-load-order">plugins.ini load order</a>.</li> | |
| 15 | +</ul> | |
| 16 | +<p>Adding a bot to the AMXX file, or a <code>.amxx</code> to the Metamod file, silently fails. AMXX is the bridge: it is a line in the Metamod file, and it then reads its own file for Pawn plugins.</p> | |
| 17 | +<h2>2. The line format</h2> | |
| 18 | +<p>Each non-comment line has two parts — a platform keyword and a path to the binary:</p> | |
| 19 | +<pre><platform> <path-to-plugin-binary></pre> | |
| 20 | +<p>For example, the line that loads AMX Mod X looks like this on each OS:</p> | |
| 21 | +<pre>linux addons/amxmodx/dlls/amxmodx_mm_i386.so | |
| 22 | +win32 addons/amxmodx/dlls/amxmodx_mm.dll</pre> | |
| 23 | +<p>The first token is the platform; the rest of the line is the file Metamod loads.</p> | |
| 24 | +<h2>3. win32 vs linux</h2> | |
| 25 | +<p>The platform keyword tells Metamod to only load that line on the matching operating system. <code>win32</code> lines load on a Windows server; <code>linux</code> lines load on a Linux server. You can keep both lines for the same plugin in one file — Metamod loads the one that matches the host and ignores the other — which is exactly how a plugin ships a cross-platform <code>plugins.ini</code>:</p> | |
| 26 | +<pre>linux addons/podbot/podbot_mm_i386.so | |
| 27 | +win32 addons/podbot/podbot_mm.dll</pre> | |
| 28 | +<p>On Linux, Metamod loads the <code>.so</code> and skips the <code>.dll</code>; on Windows, the reverse. If you list only the <code>win32</code> line and run on Linux, the plugin simply never loads — and there is no error, because Metamod correctly skipped a non-matching platform line. That silent skip is why "I added the line but nothing loaded" is so often a wrong platform keyword.</p> | |
| 29 | +<h2>4. Paths are relative to the game directory</h2> | |
| 30 | +<p>The path is relative to the mod folder — <code>cstrike/</code> for Counter-Strike — not to <code>addons/metamod/</code> and not absolute. So <code>addons/amxmodx/dlls/amxmodx_mm_i386.so</code> resolves to <code>cstrike/addons/amxmodx/dlls/amxmodx_mm_i386.so</code>. On Linux the file is a 32-bit <code>.so</code> ending <code>_i386.so</code>; on Windows a <code>.dll</code>. Use forward slashes; they work on both platforms. A wrong path, or a Linux server pointed at a <code>.dll</code>, produces a load failure at map start.</p> | |
| 31 | +<h2>5. AMXX is just another plugin here</h2> | |
| 32 | +<p>The key mental model: AMX Mod X is not special to Metamod — it is one Metamod plugin among several, loaded by one line in this file. Bots are peers of AMXX, each their own line. The load order between Metamod plugins rarely matters (unlike AMXX's Pawn plugins, where it can), so you can list AMXX and a bot in either order. Comment a line out with a leading semicolon to disable it without deleting it:</p> | |
| 33 | +<pre>; win32 addons/podbot/podbot_mm.dll ; disabled for now | |
| 34 | +linux addons/amxmodx/dlls/amxmodx_mm_i386.so</pre> | |
| 35 | +<h2>Troubleshooting</h2> | |
| 36 | +<ul> | |
| 37 | +<li><strong>Plugin does not load, no error</strong> — wrong platform keyword (a <code>win32</code> line on Linux). Metamod silently skips non-matching lines. Use the keyword for your OS.</li> | |
| 38 | +<li><strong>"Couldn't load plugin" / bad load</strong> — wrong path or wrong binary type (a <code>.dll</code> on Linux). See <a href="/tutorials/fix-metamod-bad-load">fix Metamod bad load</a>.</li> | |
| 39 | +<li><strong><code>meta list</code> shows no AMXX</strong> — the AMXX line is missing or in the wrong <code>plugins.ini</code>. Work through <a href="/tutorials/fix-meta-list-no-amxx">meta list has no AMXX</a>.</li> | |
| 40 | +<li><strong>Edited the file, nothing changed</strong> — <code>plugins.ini</code> is read at map load; change the map or restart.</li> | |
| 41 | +<li><strong>Put a <code>.amxx</code> in this file</strong> — wrong file. Pawn plugins go in <code>addons/amxmodx/configs/plugins.ini</code>, not here.</li> | |
| 42 | +</ul> | |
| 43 | +<h2>Verification</h2> | |
| 44 | +<p>After editing, change the map and run <code>meta list</code> in the server console. Every plugin from this file that matched your platform should appear with a <code>running</code> status — AMXX, your bot, and anything else. A plugin you expected but do not see was skipped (wrong platform) or failed (wrong path); a plugin marked <code>bad load</code> loaded but errored. Cross-check against <a href="/tutorials/install-metamod-r">the Metamod-r install</a> if the whole list is empty, which means Metamod itself is not loading.</p> |
package-map-for-fastdl/en.md
A
| @@ -0,0 +1,17 @@ | ||
| 1 | +--- | |
| 2 | +title: "Packaging a Map for FastDL (bsp, res, wad, models)" | |
| 3 | +excerpt: "The exact folder layout for shipping a CS 1.6 map over FastDL: the bsp, its res manifest, external wads, models, sounds and sky, mirrored under cstrike." | |
| 4 | +category: "mapping" | |
| 5 | +tags: "fastdl, packaging" | |
| 6 | +image: "" | |
| 7 | +read_time: "9 min read" | |
| 8 | +--- | |
| 9 | +<p>A finished map is more than a <code>.bsp</code>. To ship it to a live server so players download everything cleanly, you assemble the map plus every asset it references into the exact folder layout the game expects, then mirror that layout onto your FastDL host. Miss one file or put it one folder too deep and players get missing textures, <code>ERROR</code> models, or a slow in-game trickle. This is the packaging checklist.</p><h2>1. Gather every file the map needs</h2><p>Start from the <a href="/tutorials/generate-res-file">.res file</a> — it is your packing list. You need:</p><ul><li><code>maps/de_mymap.bsp</code> — the compiled map</li><li><code>maps/de_mymap.res</code> — the content manifest</li><li>Any external <code>.wad</code> the map did <em>not</em> embed (if you used <a href="/tutorials/wadinclude-vs-external-wads">external WADs</a>)</li><li>Custom <code>models/</code>, <code>sound/</code>, <code>sprites/</code> the map references</li><li>The six <code>gfx/env/</code> skybox faces if the sky is custom</li><li><code>overviews/de_mymap.bmp</code> and <code>.txt</code> for the radar</li></ul><p>If you embedded textures with <code>-wadinclude</code>, you do not ship a WAD at all — the BSP carries them. That is the simplest package for a map with only a few custom textures.</p><h2>2. Lay them out under cstrike/</h2><p>Every path is relative to <code>cstrike/</code>, and the server and FastDL host must mirror that structure exactly:</p><pre>cstrike/maps/de_mymap.bsp | |
| 10 | +cstrike/maps/de_mymap.res | |
| 11 | +cstrike/models/props/mymap_crate.mdl | |
| 12 | +cstrike/sound/ambient/mymap_wind.wav | |
| 13 | +cstrike/sprites/mymap_glow.spr | |
| 14 | +cstrike/gfx/env/mysky_up.tga (and dn/lf/rt/ft/bk) | |
| 15 | +cstrike/overviews/de_mymap.bmp | |
| 16 | +cstrike/overviews/de_mymap.txt</pre><p>Put these on the game server first so the map runs, and confirm it loads locally with all content before touching FastDL. See <a href="/tutorials/install-custom-maps-cs16-server">installing custom maps</a> for the server-side placement.</p><h2>3. Mirror the tree onto the FastDL host</h2><p>The FastDL web root must contain a <code>cstrike/</code> directory that mirrors the server, because the engine requests <code><sv_downloadurl>/cstrike/maps/de_mymap.bsp</code> — the full game-relative path including the <code>cstrike/</code> level. Copy the same files to the same relative paths on the web host. If your <code>sv_downloadurl</code> is <code>http://dl.example.com/cs</code>, then the crate model must resolve at <code>http://dl.example.com/cs/cstrike/models/props/mymap_crate.mdl</code>. The full server/mirror wiring is in the <a href="/tutorials/fastdl-setup-guide">FastDL setup guide</a> and <a href="/tutorials/sv-allowdownload-settings">the download cvars</a>.</p><h2>4. Compress with bzip2 for fast transfers</h2><p>FastDL clients will fetch a <code>.bz2</code> version of a file if it exists, decompressing it on arrival — much faster than the raw file. Create <code>.bz2</code> copies of each large asset alongside the originals on the web host:</p><pre>de_mymap.bsp -> de_mymap.bsp.bz2 | |
| 17 | +mymap_crate.mdl -> mymap_crate.mdl.bz2</pre><p>Keep both the plain and the <code>.bz2</code> so any client works. The mechanics and tooling are in <a href="/tutorials/fastdl-bzip2-compression">FastDL bzip2 compression</a>.</p><h2>5. Confirm the WAD is delivered or embedded</h2><p>If textures are external, the custom <code>.wad</code> must be on both the server and the FastDL host and listed so clients fetch it — otherwise you get <a href="/tutorials/fix-missing-black-textures">black textures</a>. If you embedded with <code>-wadinclude</code>, skip this: nothing to ship. Never ship the giant stock WADs — every client already has <code>halflife.wad</code> and <code>cstrike.wad</code>.</p><h2>6. Keep the server and mirror byte-identical</h2><p>The server and the FastDL host must hold the <em>same</em> files at the same relative paths. If you fix a texture, recompile the map, or rename an asset, update both places in the same step — a map that plays fine on the server but pulls an old <code>.bsp</code> from a stale mirror gives players a version mismatch and a failed download. A simple discipline that prevents this: build the complete <code>cstrike/</code> package once in a staging folder, verify the map loads from it locally, then push that same folder to the game server and to the web root. Never edit one side and forget the other. When you rotate the map into the cycle, confirm the <a href="/tutorials/install-custom-maps-cs16-server">server has the map installed</a> and the mirror has every file the <code>.res</code> names, because the download only works when both halves agree.</p><h2>Common errors</h2><ul><li><strong>Everything 404s over HTTP</strong> — the <code>cstrike/</code> level is missing or doubled in the web root. The path must be <code><url>/cstrike/maps/...</code> exactly.</li><li><strong>Map downloads but models are <code>ERROR</code></strong> — the model is not in the <code>.res</code> or not on the mirror. Reconcile the <code>.res</code> with the files.</li><li><strong>Black/checkerboard textures</strong> — external WAD not delivered, or not embedded. See <a href="/tutorials/fix-missing-black-textures">missing textures</a>.</li><li><strong>Downloads crawl</strong> — no <code>.bz2</code> copies, or <code>sv_downloadurl</code> unreachable. Add bzip2 files and test the URL.</li><li><strong>Sky blank for players</strong> — the six <code>gfx/env/</code> faces are not in the package. Ship all six.</li></ul><h2>Verification</h2><p>Use a clean client with none of the custom content and connect to the server with FastDL live. Watch the download list: the <code>.bsp</code>, the models, sounds, sprites and sky faces should all transfer over HTTP, then the map should render with every texture, model and the correct sky. Open one asset's full FastDL URL in a browser to prove the path resolves. If a single file fails, its <code>.res</code> line or its position in the <code>cstrike/</code> tree is wrong — fix that one path and re-test. That clean-client download is the only proof the package is complete.</p> |
where-to-find-plugins-help/en.md
A
| @@ -0,0 +1,9 @@ | ||
| 1 | +--- | |
| 2 | +title: "Where to Find CS 1.6 Plugins and Help in 2026" | |
| 3 | +excerpt: "An honest map of where working AMX Mod X plugins, source code, and admin help actually live in 2026, how to vet what you download, and why the version and stack matter before you install anything." | |
| 4 | +category: "misc" | |
| 5 | +tags: "community, resources" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>CS 1.6 is 25 years old and its documentation is scattered across forums, repos, and dead links. Knowing <em>where</em> to look — and how to tell a maintained plugin from an abandoned one — saves hours. This is an honest map of the resources that still matter in 2026, without inventing URLs that may not exist by the time you read it.</p><h2>1. Categories of source, not single sites</h2><p>Rather than trust one link, think in terms of where each kind of thing lives:</p><ul><li><strong>The AMX Mod X community forums.</strong> The long-running AMXX forum ecosystem is still the largest archive of plugins, each posted with a <code>.sma</code> source, a description, cvars, and a support thread. This is where most public plugins originate and where authors answer questions. Search there first for any behaviour you want to add.</li><li><strong>GitHub.</strong> The maintained core stack is developed openly under the <code>rehlds</code> organisation (ReHLDS, ReGameDLL_CS, ReAPI, Metamod-r, Reunion) and the AMX Mod X project has its own repository with releases and includes. GitHub is where you get <em>current, versioned</em> downloads and can read the actual code and issue tracker — far more trustworthy than a random forum mirror.</li><li><strong>This site's plugin directory.</strong> The CS Boost plugin directory hosts GPL-licensed plugins with their source, and compiles each <code>.amxx</code> on demand from that source — so what you download matches what you can read. Browse it for admin tools like the <a href="/plugins/csb-admin-menu">CSB Admin Menu</a> and utilities like <a href="/plugins/csb-server-adverts">CSB Server Adverts</a>.</li></ul><h2>2. How to vet a plugin before installing it</h2><p>Not every plugin you find is safe to run on a live server. Check, in order:</p><ol><li><strong>Is the source included?</strong> Prefer plugins that ship the <code>.sma</code>, not just a compiled <code>.amxx</code>. You can read what it does and recompile it for your version. A binary-only plugin is a black box.</li><li><strong>What AMXX version does it target?</strong> A plugin using <code>client_print_color</code> needs 1.9+; running it on 1.8.2 fails. Match the plugin to your core — see <a href="/tutorials/amxx-versions-explained">AMX Mod X versions explained</a>.</li><li><strong>Does it need ReAPI/ReGameDLL?</strong> A plugin that <code>#include <reapi></code> requires <a href="/tutorials/what-is-regamedll">ReGameDLL</a>. Installing it on a stock stack produces a bad load.</li><li><strong>Is it AMX Mod X, not old AMX Mod?</strong> A <code>.amx</code> from the discontinued platform will not load — see <a href="/tutorials/amx-mod-vs-amx-mod-x">AMX Mod vs AMX Mod X</a>.</li><li><strong>When was it last touched?</strong> A plugin with recent activity and a live support thread is far safer than one last updated a decade ago against an engine that no longer exists.</li></ol><h2>3. Where to ask for help</h2><p>When something breaks, the fastest help comes from communities that share your stack:</p><ul><li>The AMXX forums' scripting and support sections — post the exact error from <code>amxx plugins</code> or the server log, your AMXX version, and whether you run ReHLDS/ReGameDLL. Precise questions get precise answers.</li><li>The relevant GitHub issue trackers — for engine, ReGameDLL, or ReAPI bugs, the maintainers themselves read and respond there.</li><li>The tutorials on this site — for the common problems (module load failures, protocol mismatches, missing from the master list) there is usually a step-by-step already written.</li></ul><h2>4. A note on dead links and honesty</h2><p>Many old "download here" links from CS 1.6's peak are gone, and mirror sites come and go. Do not trust a random re-upload of a compiled binary from an anonymous file host — that is how servers get backdoored plugins. Prefer the original author's post, the project's GitHub releases, or a directory that publishes the source. If a plugin only exists as a compiled <code>.amxx</code> on a sketchy mirror, treat it as untrusted.</p><h2>Common misconceptions</h2><ul><li><strong>"Any plugin I find will just work."</strong> Version, stack, and modules all matter. A plugin can be perfect and still bad-load because it targets a different AMXX branch or needs ReGameDLL.</li><li><strong>"Compiled-only downloads are fine."</strong> They are a security risk and unfixable. Prefer source you can read and recompile.</li><li><strong>"The forums are dead."</strong> The scene is smaller but the AMXX forums and GitHub repos are active — see <a href="/tutorials/is-cs16-still-alive-2026">is CS 1.6 still alive in 2026</a>.</li><li><strong>"Newest plugin is best."</strong> Newest is not the metric — maintained, source-available, and matched to your version is.</li><li><strong>"I need a paid host to get plugins."</strong> All of the core stack and the vast plugin archive is free and open.</li></ul><h2>How to sanity-check a plugin on your server</h2><p>After installing, load it and confirm it took:</p><pre>amxx plugins</pre><p>Your plugin should read <code>running</code>, not <code>bad load</code>. If it bad-loads, the usual causes are a version mismatch, a missing module, or a stock stack lacking ReGameDLL — work back through the vetting checklist above. To advertise your server once it is configured, see <a href="/tutorials/where-to-advertise-cs16-server">where to advertise a CS 1.6 server</a>.</p> | |
| 0 | 10 |
