Add 6 tutorials (6 files)
Browse Source
Daemon666 committed
parent e3a553a7cc
commit d1c8959a84a84cf3bb35e33d30aab3aaa7f34ccc
6 changed files
with 180 additions and 0 deletions
A
amx-mod-vs-amx-mod-x/en.md
+9 -0
A
configure-yapb-waypoints/en.md
+58 -0
A
fix-texture-axis-perpendicular/en.md
+9 -0
A
install-cs16-steam-only-server/en.md
+47 -0
A
install-podbot-mm/en.md
+43 -0
A
update-cs16-server-latest-build/en.md
+14 -0
amx-mod-vs-amx-mod-x/en.md
A
| @@ -0,0 +1,9 @@ | ||
| 1 | +--- | |
| 2 | +title: "AMX Mod vs AMX Mod X: What's the Difference?" | |
| 3 | +excerpt: "The original AMX Mod versus the community fork AMX Mod X: why they are not source-compatible, which one is maintained, and what that means for the plugins you download." | |
| 4 | +category: "misc" | |
| 5 | +tags: "amxmodx, history" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>Search for a CS 1.6 admin plugin and you will trip over two names that look almost identical: <strong>AMX Mod</strong> and <strong>AMX Mod X</strong>. They are not the same project, their plugins are not interchangeable, and downloading a plugin for the wrong one is a classic reason a <code>.amxx</code> refuses to load. Here is the distinction and why it still matters in 2026.</p><h2>1. AMX Mod — the original</h2><p>AMX Mod was the original scripting platform, built by <strong>OLO</strong> (and associated authors) on top of the Small/Pawn language. It gave GoldSrc servers an admin system and a plugin API through Metamod, and for years it was <em>the</em> way to script Half-Life mods. It is, however, <strong>discontinued</strong> — development stopped long ago, it does not track modern engine changes, and it lacks the natives, modules, and fixes that arrived over the following two decades.</p><h2>2. AMX Mod X — the community fork</h2><p><strong>AMX Mod X</strong> (AMXX) is a separate, community-driven fork that took the concept and rebuilt it into a far larger, actively-maintained platform. It is developed openly on GitHub, ships a rich module system (<code>fakemeta</code>, <code>hamsandwich</code>, <code>cstrike</code>, <code>csx</code>, <code>reapi</code>, and more), and continues to receive releases. When anyone today says "install AMXX" or references <code>plugins.ini</code>, <code>amxx.cfg</code>, or the <code>amxx</code> server command, they mean AMX Mod X. It is the standard, full stop — see <a href="/tutorials/what-is-amx-mod-x">what is AMX Mod X</a> for the overview.</p><h2>3. Why the plugins are not interchangeable</h2><p>This is the part that bites people: <strong>AMX Mod plugins are not source-compatible with AMX Mod X</strong>. Although both use the Pawn language, they expose different includes and different natives:</p><ul><li>AMX Mod source includes headers and calls functions specific to its own API.</li><li>AMX Mod X source includes <code><amxmodx></code>, <code><amxmisc></code>, <code><fakemeta></code>, <code><hamsandwich></code>, <code><cstrike></code>, etc. — a different, much larger native set.</li></ul><p>You cannot take an old AMX Mod <code>.sma</code> and compile it with the AMXX compiler and expect it to build; the includes and natives it references do not exist in the AMXX API. A plugin must be <strong>rewritten or ported</strong>, not just recompiled. And the compiled binaries differ too — an AMX Mod plugin binary will not load under AMX Mod X.</p><h2>4. What this means when you download plugins</h2><p>Practically, in 2026:</p><ul><li>If a plugin page says "for AMX Mod X" and gives a <code>.sma</code> that <code>#include <amxmodx></code>, it is for the modern platform — that is what you want.</li><li>If you find a very old plugin labelled just "AMX Mod" (no X), assume it will not work on a modern AMXX server without a port. Look for an AMXX equivalent instead; almost everything popular was reimplemented for AMXX years ago.</li><li>The file extension is a hint but not proof: AMXX plugins are <code>.amxx</code>. Old AMX Mod used <code>.amx</code>. Seeing <code>.amx</code> is a strong sign it is the discontinued platform.</li></ul><h2>5. Why AMXX won</h2><p>The fork overtook the original for concrete reasons worth knowing. AMXX added a real <strong>module system</strong> — <code>fakemeta</code> for low-level engine hooks, <code>hamsandwich</code> for game-DLL virtual functions, <code>cstrike</code> for CS-specific natives, <code>csx</code> for stats, <code>sqlx</code> for databases, and later <code>reapi</code> for ReHLDS/ReGameDLL hooks. None of that breadth existed in the original AMX Mod. It also kept pace with engine changes: when ReHLDS, ReGameDLL, and the <a href="/tutorials/25th-anniversary-update-recap">25th anniversary update</a> reshaped the platform, AMX Mod X shipped compatible builds while the original stayed frozen. The result is that the entire modern plugin ecosystem — admin menus, stats, VIP shops, gamemodes — is written for AMXX, and finding a maintained plugin for the original AMX Mod today is nearly impossible.</p><h2>Common misconceptions</h2><ul><li><strong>"AMX Mod X is just a newer version of AMX Mod."</strong> No — it is a separate fork with a different API, not a sequential release of the same codebase.</li><li><strong>"I can recompile an AMX Mod plugin for AMXX."</strong> Not without porting. The includes and natives differ; the source will not build unchanged.</li><li><strong>"The X stands for version 10 / roman numeral."</strong> It does not indicate a version number; it is part of the fork's name. AMXX has its own version line — see <a href="/tutorials/amxx-versions-explained">AMX Mod X versions explained</a>.</li><li><strong>"A .amx file works on my AMXX server."</strong> AMXX loads <code>.amxx</code> files. A raw <code>.amx</code> from old AMX Mod will not load.</li><li><strong>"AMX Mod is still maintained."</strong> It is discontinued. All active development, modules, and engine-compatibility work happens in AMX Mod X.</li></ul><h2>How to tell which one you have</h2><p>On the server, run <code>meta list</code> in the console — the loaded scripting platform shows up as a Metamod plugin. AMX Mod X reports itself as <code>AMX Mod X</code>; the classic one as <code>AMX Mod</code>. Then check your <code>addons/</code> folder: a modern install has an <code>addons/amxmodx/</code> directory with <code>plugins/</code>, <code>configs/</code>, and <code>modules/</code> subfolders. If you inherited a server on the discontinued AMX Mod, the right move is to migrate to AMX Mod X and replace the plugins with their AMXX equivalents — start from <a href="/tutorials/install-amx-mod-x-1-9">installing AMX Mod X 1.9</a>. Everything else you read on this site assumes the AMXX platform.</p> |
configure-yapb-waypoints/en.md
A
| @@ -0,0 +1,58 @@ | ||
| 1 | +--- | |
| 2 | +title: "How to Add YaPB Waypoints/Graphs for Custom Maps" | |
| 3 | +excerpt: "How to build a YaPB navigation graph for a custom map: entering the graph editor, letting the analyzer auto-generate nodes, adding and connecting nodes by hand, and saving so bots navigate." | |
| 4 | +category: "installation" | |
| 5 | +tags: "yapb, waypoints" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>Bots on <a href="/tutorials/install-yapb-bots">YaPB</a> do not path from raw geometry — they follow a per-map navigation <strong>graph</strong>. Official maps ship one (or YaPB downloads it), but a custom map usually arrives with none, so bots spawn and stand still. This guide builds a graph for a custom map: auto-generate a first pass with the analyzer, then fix the tricky spots by hand, and save.</p> | |
| 10 | + | |
| 11 | +<h2>1. Confirm the map really has no graph</h2> | |
| 12 | +<p>Graph files are named after the map and live in the bot's data folder:</p> | |
| 13 | +<pre>cstrike/addons/yapb/data/graph/<mapname>.graph</pre> | |
| 14 | +<p>Load the custom map with a couple of bots. If the console prints a message to the effect of <em>no graph for this map</em> and the bots idle at spawn, you need to create the file. YaPB's native format is <code>.graph</code>; it can import an old <code>.pwf</code> waypoint file if someone hands you one, but you will usually build fresh.</p> | |
| 15 | + | |
| 16 | +<h2>2. Enter the graph editor</h2> | |
| 17 | +<p>Get admin rights on the server (rcon or listen server), then turn the editor on from the console:</p> | |
| 18 | +<pre>yb graph on</pre> | |
| 19 | +<p>Nodes now draw in the world as coloured markers and a wire mesh of connections. Open the editor menu for the full set of actions:</p> | |
| 20 | +<pre>yb graph menu</pre> | |
| 21 | +<p>From that menu you place nodes, set their type, connect paths, and save — it is far easier than memorising every subcommand.</p> | |
| 22 | + | |
| 23 | +<h2>3. Let the analyzer do the first pass</h2> | |
| 24 | +<p>Modern YaPB can walk the map and generate a rough graph automatically, which saves enormous time on a large map. Start the analyzer from the graph menu (the auto-add / analyze option) and let it run; it seeds nodes along walkable surfaces and links them. When it finishes you have a navigable draft that already gets bots moving — you then refine it rather than placing hundreds of nodes by hand.</p> | |
| 25 | + | |
| 26 | +<h2>4. Add and type nodes by hand where it matters</h2> | |
| 27 | +<p>The analyzer misses map-specific intent, so walk the key areas yourself and place nodes with the right type. Stand where you want a node and add it from the menu (or <code>yb graph add</code>), then pick its type:</p> | |
| 28 | +<ul> | |
| 29 | +<li><strong>Normal</strong> — a plain path point.</li> | |
| 30 | +<li><strong>Crouch</strong> — forces bots to duck through vents and low gaps.</li> | |
| 31 | +<li><strong>Jump</strong> — marks a spot bots must jump.</li> | |
| 32 | +<li><strong>Camp</strong> — a hold position, with a facing direction.</li> | |
| 33 | +<li><strong>Goal</strong> — bomb sites, hostage spots, rescue and escape zones.</li> | |
| 34 | +<li><strong>Ladder</strong> — placed on ladder rungs so bots climb.</li> | |
| 35 | +</ul> | |
| 36 | +<p>Place goal nodes at both bomb sites (or every hostage and the rescue point), camp nodes at common angles, and crouch nodes in every vent. This is what separates bots that merely move from bots that actually play the objective.</p> | |
| 37 | + | |
| 38 | +<h2>5. Connect the nodes into paths</h2> | |
| 39 | +<p>Nodes are useless without connections — a bot travels along the links between them. The analyzer connects most automatically, but check awkward geometry: one-way drops, long jumps, and ladders often need a manual path added in the direction of travel. Use the pathing options in the graph menu to add a connection from the nearest node to the one you are looking at, and add a one-way link where a bot can drop down but not climb back. Sparse or broken connections are why bots "move but path badly."</p> | |
| 40 | + | |
| 41 | +<h2>6. Save the graph</h2> | |
| 42 | +<p>When the layout is done, save from the menu or the console:</p> | |
| 43 | +<pre>yb graph save</pre> | |
| 44 | +<p>That writes <code><mapname>.graph</code> into <code>addons/yapb/data/graph/</code>. Graphs are read at map load, so reload the map to pick up the saved file:</p> | |
| 45 | +<pre>changelevel <mapname></pre> | |
| 46 | +<p>From now on YaPB prefers your local file over any download. Keep the <code>.graph</code> alongside the map's <code>.bsp</code> in your own records so you never regenerate it — it is server-side navigation data and does not go on your FastDL mirror.</p> | |
| 47 | + | |
| 48 | +<h2>Common errors</h2> | |
| 49 | +<ul> | |
| 50 | +<li><strong>Bots still idle after saving</strong> — the filename does not match the map. It must be <code>data/graph/<exactmapname>.graph</code>, case-matched on Linux. See <a href="/tutorials/fix-bots-stand-still-no-waypoints">bots stand still, no waypoints</a>.</li> | |
| 51 | +<li><strong><code>yb graph on</code> does nothing</strong> — you lack admin rights, or YaPB is not loaded. Check <code>meta list</code> for YaPB as <code>RUN</code>.</li> | |
| 52 | +<li><strong>Bots move but fall off ledges or bunch up</strong> — missing or wrong connections. Add one-way links on drops and fix the pathing at chokepoints.</li> | |
| 53 | +<li><strong>Bots ignore a bomb site</strong> — no goal node there. Place a goal node at each objective.</li> | |
| 54 | +<li><strong>Analyzer produced a sparse graph</strong> — complex or vertical maps confuse it; supplement by hand in the thin areas and save again.</li> | |
| 55 | +</ul> | |
| 56 | + | |
| 57 | +<h2>Verification</h2> | |
| 58 | +<p>Turn the editor off (<code>yb graph off</code>), reload the map with a few bots, and watch them: within seconds they should leave spawn, take routes, use ladders and vents, and push the objective. Confirm there is no "no graph" message in the console. If the bots navigate the whole map cleanly, the graph is valid and complete; if they stall in one area, re-enter the editor, thicken the nodes and connections there, and save again.</p> |
fix-texture-axis-perpendicular/en.md
A
| @@ -0,0 +1,9 @@ | ||
| 1 | +--- | |
| 2 | +title: "Fix: 'Texture axis perpendicular to face'" | |
| 3 | +excerpt: "What the ZHLT/VHLT warning means, why vertex-manipulated faces produce it, and how to re-align the texture in Hammer so the compile is clean." | |
| 4 | +category: "mapping" | |
| 5 | +tags: "textures, compiling" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>Your compile log fills with lines like:</p><pre>Warning: Texture axis perpendicular to face</pre><p>It is a warning, not a fatal error — the map usually still compiles — but it means a face has a <strong>broken texture projection</strong>, and in game that face will show a smeared, stretched, or garbage texture. The texture's projection plane is at 90 degrees to the face it is applied to, so the compiler cannot map the pixels onto the surface sensibly. It almost always comes from vertex manipulation or rotating a brush, and the fix is to re-apply a valid texture alignment to the offending faces.</p><h2>1. Understand the cause</h2><p>Every face stores a texture axis — two vectors describing how the 2D texture is projected onto the 3D face. When a face lies flat relative to that projection, the mapping is fine. When you use the vertex tool to drag a brush into a wedge, or rotate a brush so a face becomes near-vertical relative to its stored projection, the axis can end up perpendicular to the new face. The compiler cannot divide by that, warns, and falls back to a degenerate mapping. The face still exists; it just looks wrong.</p><h2>2. Read the warning to find the face</h2><p>Older ZHLT prints the warning with the brush/entity number and often the texture name. Vluzacn's VHLT v34 gives clearer diagnostics, sometimes with coordinates. Note the brush number, then in Hammer use <strong>Map → Go to Brush Number</strong> (or the equivalent) to jump straight to it. If you cannot get a number, the culprit is nearly always the last brush you vertex-manipulated or rotated.</p><h2>3. Re-apply the texture with world alignment</h2><p>Select the bad face with the Texture Application (Face Edit) tool, and re-project it cleanly:</p><ul><li>Open the <strong>Face Edit / Texture Application</strong> dialog.</li><li>Select the offending face.</li><li>Click <strong>World</strong> alignment (the compiler-friendly default) — or <strong>Face</strong> alignment if the face is angled and you want the texture to follow the face plane.</li><li>Re-apply the texture. This rewrites the texture axis to something valid.</li></ul><p>World alignment projects the texture along world axes and is the safest choice for most faces; Face alignment lays the texture flat onto an angled face and is right for ramps and slopes. Either one replaces the perpendicular axis with a working one.</p><h2>4. Copy a good alignment onto the bad face</h2><p>A fast fix in Valve Hammer: with the Face Edit tool, hold <strong>Alt</strong> and right-click a neighbouring face that looks correct. That copies its texture and alignment onto the face you clicked, replacing the broken axis. This is the quickest way to fix a wedge whose top or side went perpendicular after vertex work.</p><h2>5. Fix the geometry if it keeps recurring</h2><p>If the same brush keeps throwing the warning after re-aligning, the geometry itself is degenerate — a face collapsed to near-zero area, or three vertices nearly collinear from over-aggressive vertex dragging. Delete and rebuild that brush from a clean block rather than fighting the alignment; a near-invalid solid will keep corrupting its own texture axes. Keep vertex manipulation modest and check faces as you go.</p><p>A related habit prevents most of these warnings in the first place: build angled and vertex-manipulated shapes from a properly-textured block, then do your vertex work, then re-apply textures to the faces you moved. If you texture last rather than first, the projection is computed against the final face orientation and the perpendicular case rarely arises. When you must carve or clip a brush, run the Texture Application tool over the new faces immediately, because clipping inherits the parent brush's axes and a clipped face can land perpendicular the moment it is created.</p><h2>Common errors</h2><ul><li><strong><code>Warning: Texture axis perpendicular to face</code> repeated many times</strong> — one vertex-manipulated brush with several bad faces. Re-align each face with World/Face, or Alt+right-click a good neighbour.</li><li><strong>Warning gone but the face still looks smeared</strong> — you re-aligned but did not re-apply; click Apply after choosing World/Face so the axis is rewritten.</li><li><strong>Comes back every compile on the same brush</strong> — degenerate geometry. Rebuild that brush from a fresh block.</li><li><strong>Whole ramp textured wrong</strong> — use <strong>Face</strong> alignment, not World, so the texture follows the slope.</li><li><strong>Ignored it and shipped</strong> — players see a stretched face. It is cosmetic but obvious; fix it before release.</li></ul><h2>Verification</h2><p>Recompile and confirm the warning is gone from the <code>hlcsg</code>/<code>hlbsp</code> log for that brush. Load the map and look directly at the previously broken face — the texture should sit flat and undistorted, tiling correctly across the surface. Move around it to check the projection holds from every angle. If a few warnings remain on other brushes, repeat the re-alignment; a clean compile log for a finished map should have zero texture-axis warnings. For a broader texturing pass, see <a href="/tutorials/goldsrc-map-optimization-checklist">the optimization checklist</a>.</p> |
install-cs16-steam-only-server/en.md
A
| @@ -0,0 +1,47 @@ | ||
| 1 | +--- | |
| 2 | +title: "Steam-Only CS 1.6 Server: Configuration and Trade-Offs" | |
| 3 | +excerpt: "How to run a server that admits only legitimate Steam clients, why that gives you reliable SteamIDs, and the honest audience trade-off versus allowing non-Steam players." | |
| 4 | +category: "installation" | |
| 5 | +tags: "steam, config" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>A "Steam-only" server is defined by what you <em>do not</em> install: no <a href="/tutorials/install-reunion">Reunion</a>, no <a href="/tutorials/install-dproto">dproto</a>, nothing that fakes or accepts non-Steam authentication. The engine then validates every joining client against Steam and hands you a real, unique SteamID for each player. That single fact changes how bans, stats and admin flags behave. This covers the configuration and the genuine trade-off you are accepting.</p> | |
| 10 | +<h2>1. What Steam-only actually means</h2> | |
| 11 | +<p>Stock HLDS or ReHLDS, with no non-Steam patch loaded, already <em>is</em> Steam-only. Non-Steam clients connect only when you deliberately add Reunion (for ReHLDS) or dproto (for original HLDS). So building a Steam-only server is mostly about <strong>not</strong> installing those, plus a few cvars that make the intent explicit and keep the server on the public list. If you have previously experimented with a non-Steam patch, removing it is step one.</p> | |
| 12 | +<h2>2. The core cvars</h2> | |
| 13 | +<p>In <a href="/tutorials/setup-server-cfg-cs16">server.cfg</a>:</p> | |
| 14 | +<pre>sv_lan 0 // appear on the internet master list, validate via Steam | |
| 15 | +sv_password "" // public server (set a value to make it private) | |
| 16 | +sv_allowdownload 1 // still allow custom content downloads</pre> | |
| 17 | +<p><code>sv_lan 0</code> is the critical line: on a LAN server the engine does not perform internet Steam validation, so it must be <code>0</code> for a real Steam-authenticated public server. These and the rest are covered in <a href="/tutorials/essential-server-cvars">the essential cvars guide</a>.</p> | |
| 18 | +<h2>3. Confirm no non-Steam patch is loaded</h2> | |
| 19 | +<p>If you run Metamod, check its plugin list for a Reunion or dproto entry and remove it:</p> | |
| 20 | +<pre>cat cstrike/addons/metamod/plugins.ini</pre> | |
| 21 | +<p>Any line referencing <code>reunion</code> or <code>dproto</code> means non-Steam clients are being admitted. Delete the line and restart. On ReHLDS specifically, Reunion is the usual culprit; without it, the engine falls back to strict Steam validation.</p> | |
| 22 | +<h2>4. Why the real SteamID matters</h2> | |
| 23 | +<p>With Steam-only, every player carries a genuine, globally-unique <code>STEAM_0:x:xxxxxxx</code>. That gives you:</p> | |
| 24 | +<ul> | |
| 25 | +<li><strong>Bans that stick.</strong> A SteamID ban blocks that account everywhere; the player cannot dodge it by picking a new name.</li> | |
| 26 | +<li><strong>Honest stats.</strong> A <a href="/tutorials/install-amx-mod-x-1-9">rank system</a> keyed by SteamID never confuses two people, because no two players share an ID.</li> | |
| 27 | +<li><strong>Reliable admin flags.</strong> Admins added by SteamID cannot be impersonated, unlike name/password admins.</li> | |
| 28 | +</ul> | |
| 29 | +<p>On a non-Steam server, IDs are frequently duplicated or forged, so all three of these become unreliable — two players can share one ID and thus one rank, one ban, or one admin flag.</p> | |
| 30 | +<h2>5. The trade-off, stated honestly</h2> | |
| 31 | +<p>The cost of Steam-only is audience. A large share of the CS 1.6 population, particularly in some regions, still plays non-Steam clients, and they simply cannot join a Steam-only server — they are rejected at validation. You are trading raw player count for integrity. Decide by your goal:</p> | |
| 32 | +<ul> | |
| 33 | +<li><strong>Competitive, stats-driven, or heavily-moderated community</strong> — Steam-only is the right call. Integrity beats headcount.</li> | |
| 34 | +<li><strong>Maximum population, casual public play</strong> — you may want to admit non-Steam clients via <a href="/tutorials/make-server-accept-nonsteam">the non-Steam guide</a>, accepting the weaker identity model.</li> | |
| 35 | +</ul> | |
| 36 | +<p>There is no universally correct answer; there is only which trade you are making with eyes open.</p> | |
| 37 | +<h2>6. Optional: reduce spoofing further</h2> | |
| 38 | +<p>Even Steam-only servers see occasional connection issues after Valve updates. Keep the engine current (ReHLDS is actively maintained and validates cleanly), and if the 25th Anniversary update broke client connections, the <code>steam_legacy</code> branch is the known rollback on the client side. Do not paste in cvars claiming to "force Steam validation" beyond <code>sv_lan 0</code> — validation is engine behavior, not a magic cvar.</p> | |
| 39 | +<h2>Troubleshooting</h2> | |
| 40 | +<ul> | |
| 41 | +<li><strong>Non-Steam players still join</strong> — a Reunion or dproto plugin is loaded. Check <code>addons/metamod/plugins.ini</code> and remove it.</li> | |
| 42 | +<li><strong>Nobody can join and the server is not listed</strong> — <code>sv_lan 1</code> disables internet validation and listing. Set it to <code>0</code>.</li> | |
| 43 | +<li><strong>Legitimate Steam players rejected after a Valve update</strong> — an engine/version mismatch. Update ReHLDS/HLDS, and have affected clients try the <code>steam_legacy</code> branch.</li> | |
| 44 | +<li><strong>Two players share a rank</strong> — you are not actually Steam-only; a non-Steam patch is handing out colliding IDs.</li> | |
| 45 | +</ul> | |
| 46 | +<h2>Verification</h2> | |
| 47 | +<p>Join your own server and open the console; run <code>status</code>. Every connected player should show a proper <code>STEAM_0:</code> ID rather than <code>VALVE_</code> or a duplicated pattern. Then confirm the server appears in the internet tab with <code>sv_lan 0</code>. If real SteamIDs show and non-Steam clients are refused, your server is genuinely Steam-only and your bans and stats will behave as intended.</p> |
install-podbot-mm/en.md
A
| @@ -0,0 +1,43 @@ | ||
| 1 | +--- | |
| 2 | +title: "How to Install POD-Bot mm on a CS 1.6 Server" | |
| 3 | +excerpt: "Install POD-Bot mm as a Metamod plugin, add the per-map waypoint files it needs, and fill your server with bots." | |
| 4 | +category: "installation" | |
| 5 | +tags: "podbot, bots" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>POD-Bot mm is a classic Counter-Strike 1.6 bot — a Metamod plugin (originally by Count Floyd, kept alive on GitHub) that adds AI players which navigate using waypoint files. It is not an AMX Mod X plugin; it loads directly through Metamod's <code>plugins.ini</code>, alongside AMXX rather than under it. This guide installs it on top of an existing Metamod server.</p> | |
| 10 | +<h2>1. Confirm Metamod is loaded</h2> | |
| 11 | +<p>POD-Bot mm is a Metamod plugin, so Metamod must already be working. If you have not installed it, follow <a href="/tutorials/install-metamod-r">the Metamod-r guide</a>. Confirm from the server console that <code>meta list</code> prints your current Metamod plugins before you add the bot — if that command is unknown, Metamod itself is not loaded and the bot has nothing to hook into.</p> | |
| 12 | +<h2>2. Install the POD-Bot files</h2> | |
| 13 | +<p>POD-Bot lives in its own folder under <code>addons</code>. Copy the whole <code>podbot</code> directory — the binary plus its config and waypoint folders — into place:</p> | |
| 14 | +<pre>cstrike/addons/podbot/podbot_mm_i386.so (Linux) | |
| 15 | +cstrike/addons/podbot/podbot_mm.dll (Windows) | |
| 16 | +cstrike/addons/podbot/botweapons.cfg | |
| 17 | +cstrike/addons/podbot/wptdefault/</pre> | |
| 18 | +<p>The <code>wptdefault/</code> folder is where per-map waypoint files (<code>.pwf</code>) live. Keep the shipped <code>botweapons.cfg</code> — it maps the current CS 1.6 weapons the bot is allowed to buy, and a mismatched one makes bots buy nothing.</p> | |
| 19 | +<h2>3. Register it in Metamod's plugins.ini</h2> | |
| 20 | +<p>Add one line to <code>cstrike/addons/metamod/plugins.ini</code> pointing at the correct binary for your OS. This is the file that tells Metamod which plugins to load, with separate lines for win32 and linux:</p> | |
| 21 | +<pre>linux addons/podbot/podbot_mm_i386.so | |
| 22 | +win32 addons/podbot/podbot_mm.dll</pre> | |
| 23 | +<p>Use the line for your platform, or list both — Metamod ignores the one that does not match. The path columns and the win32/linux split are covered in <a href="/tutorials/metamod-plugins-ini-explained">metamod/plugins.ini explained</a>. Note that POD-Bot and AMXX are peers here: both are lines in the same <code>plugins.ini</code>, and the order between them rarely matters.</p> | |
| 24 | +<h2>4. Waypoints are mandatory</h2> | |
| 25 | +<p>POD-Bot navigates purely by waypoints — a graph of nodes for each map stored as a <code>.pwf</code> file in <code>wptdefault/</code>. On a map with no waypoint file, bots spawn and then stand still or spin uselessly, because they have no path to follow. Bundle a waypoint file for every map in your rotation, named after the map (<code>de_dust2.pwf</code>). If bots refuse to move, a missing or wrong-named waypoint is nearly always why — see <a href="/tutorials/fix-bots-stand-still-no-waypoints">bots stand still with no waypoints</a>.</p> | |
| 26 | +<h2>5. Add bots and control them</h2> | |
| 27 | +<p>POD-Bot is controlled with the <code>pb</code> console command. Change the map after editing <code>plugins.ini</code>, then:</p> | |
| 28 | +<pre>pb add | |
| 29 | +pb bot_quota 6 | |
| 30 | +pb kickall</pre> | |
| 31 | +<p><code>pb add</code> drops in one bot; <code>pb bot_quota</code> keeps a fixed number filled automatically. To fill bots without typing each time, set the quota in the POD-Bot config so it applies on every map. Open the in-game control menu with <code>pb menu</code> (bind it to a key) to add, kick and set difficulty live.</p> | |
| 32 | +<h2>6. Tune difficulty and behaviour</h2> | |
| 33 | +<p>POD-Bot reads its settings from its config folder under <code>addons/podbot/</code>. There you set the default skill (roughly 0 to 100), the minimum and maximum bot count that <code>bot_quota</code> targets, whether bots chatter, and whether they respect the buy economy from <code>botweapons.cfg</code>. Set these once in the config rather than typing <code>pb</code> commands every map — console commands only last until the map changes, whereas the config is re-read on load. On a public server, keep skill mixed rather than maxed so bots feel human and do not wall-beam newer players.</p> | |
| 34 | +<h2>Troubleshooting</h2> | |
| 35 | +<ul> | |
| 36 | +<li><strong>Bots do not appear at all</strong> — the <code>plugins.ini</code> line is wrong or points at the wrong architecture. Confirm the path and that you used the <code>i386.so</code> on Linux. Check the console at map load for a Metamod load error.</li> | |
| 37 | +<li><strong>Bots spawn but stand still or spin</strong> — no waypoint file for this map. Add the correct <code>.pwf</code> to <code>wptdefault/</code>; this is the single most common POD-Bot problem.</li> | |
| 38 | +<li><strong>Bots buy no weapons</strong> — a missing or outdated <code>botweapons.cfg</code>. Restore the shipped file.</li> | |
| 39 | +<li><strong><code>pb</code> is an unknown command</strong> — the plugin did not load. Run <code>meta list</code> and confirm POD-Bot appears and is running, not failed.</li> | |
| 40 | +<li><strong>Bots stutter or lag the server</strong> — too many bots for the CPU, or a stale experience file (<code>.pxp</code>) from an older version. Delete old <code>.pxp</code> files and lower the quota.</li> | |
| 41 | +</ul> | |
| 42 | +<h2>Verification</h2> | |
| 43 | +<p>Change to a waypointed map, run <code>meta list</code> and confirm POD-Bot shows as loaded, then <code>pb add</code> and watch a bot spawn and immediately start pathing toward an objective — movement is the proof the waypoints loaded. Set <code>pb bot_quota 4</code> and confirm the count fills and refills as bots die. If you would rather use a bot that ships its own navigation graphs, compare <a href="/tutorials/install-yapb-bots">YaPB</a>, which installs the same way through <code>plugins.ini</code>.</p> |
update-cs16-server-latest-build/en.md
A
| @@ -0,0 +1,14 @@ | ||
| 1 | +--- | |
| 2 | +title: "How to Update HLDS to the Latest Build Safely" | |
| 3 | +excerpt: "Update an HLDS server to the latest build without breaking Metamod, AMX Mod X or your custom content: back up first, run app_update 90 validate, then re-verify plugins and rebind anything the update reset." | |
| 4 | +category: "installation" | |
| 5 | +tags: "update, hlds" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>Updating HLDS is the same command you used to install it — <code>app_update 90 validate</code> — but running it blind on a live, modded server is how people wake up to a dead Metamod and a server nobody can join. Valve occasionally pushes engine changes that shift file layouts or reset defaults. The safe update is: back up, stop the server, update, re-validate the mod stack, and verify before you re-open. This covers each step and what tends to break.</p><h2>1. Back up before you touch anything</h2><p>An update can overwrite files you customised. Archive the mod folder first, following <a href="/tutorials/backup-configs-bans-stats">the configs, bans and stats backup guide</a>:</p><pre>cd /home/hlds/cstrike-server | |
| 10 | +tar czf pre-update-$(date +%F).tar.gz cstrike/</pre><p>Pay special attention to <code>liblist.gam</code> and any file Metamod or a mod launcher edited — those are the ones a Valve update is most likely to revert.</p><h2>2. Stop the server cleanly</h2><p>Never update a running server. Announce it, empty the box, and stop the process (Ctrl+C in the console, <code>quit</code> via RCON, or stopping the systemd/screen session). SteamCMD writing over files that HLDS has open produces a half-updated, corrupt install.</p><h2>3. Run the update with validate</h2><p>Point SteamCMD at the same install directory you used originally and run the update. The commands mirror <a href="/tutorials/steamcmd-download-appid-90">downloading app 90</a>:</p><pre>./steamcmd.sh +force_install_dir /home/hlds/cstrike-server \ | |
| 11 | + +login anonymous \ | |
| 12 | + +app_update 90 validate \ | |
| 13 | + +quit</pre><p><code>validate</code> is not optional here — it repairs any file the update touched and confirms the tree is consistent. Point <code>force_install_dir</code> at your <em>existing</em> install so the update lands in place rather than creating a second copy.</p><h2>4. Restore anything the update reverted</h2><p>An engine update can overwrite <code>liblist.gam</code>, resetting the <code>gamedll</code> line that Metamod hooks into. If Metamod stops loading after an update, this line is the usual culprit — compare it against your backup and restore the Metamod entry. The update should not touch <code>addons/</code>, but always diff your critical configs against the pre-update tarball to be sure nothing important was reset to default.</p><h2>5. Start and check the mod stack</h2><p>Bring the server up and immediately confirm the plugin chain loaded. In the server console:</p><pre>meta list | |
| 14 | +amxx plugins</pre><p><code>meta list</code> must show Metamod running with AMX Mod X loaded; <code>amxx plugins</code> should show your plugins as <code>running</code>, not <code>bad load</code>. A <code>bad load</code> after an update usually means a module needs recompiling against the new engine, or <code>liblist.gam</code> was not restored.</p><h2>6. Have a rollback ready</h2><p>SteamCMD always pulls the current build — there is no per-version pin for app 90 — so your rollback path is the tarball from step 1, not a downgrade command. If the update breaks something you cannot quickly fix, stop the server, restore the backup over the install, and re-open on the known-good tree while you investigate offline. This is why the backup is the first step and not the last.</p><h2>Common errors</h2><ul><li><strong>Metamod stopped loading after the update</strong> — <code>liblist.gam</code> was overwritten and lost its <code>gamedll</code>/Metamod line. Restore that file from the backup.</li><li><strong>Every plugin shows "bad load"</strong> — a module needs rebuilding against the new engine, or the AMX Mod X path broke. Reinstall the affected modules.</li><li><strong>Server will not start / segfaults on boot</strong> — a half-applied update. Re-run <code>app_update 90 validate</code> to completion, or restore the backup.</li><li><strong>Custom cvar defaults reverted</strong> — the update reset a stock config. Re-apply your <code>server.cfg</code> values; they are read after the defaults.</li><li><strong>Clients get "server is using a different version"</strong> — you updated the server after the client update wave; players on the old build must update their client, or you roll the server back to the legacy branch.</li></ul><h2>Verification</h2><p>After the update, connect from a client and play a round. Confirm <code>meta list</code> shows the full stack and <code>amxx plugins</code> shows everything <code>running</code>. Check that stats still write (<code>say /rank</code> increments) and a banned SteamID is still blocked. Watch the server console during the first map load for any red error lines — a module that failed to load or a config that could not be read announces itself there, and catching it before players arrive is the whole point of updating on an empty server. Restart once more and confirm it comes up clean a second time, since some breakage only appears on the second boot when a regenerated file is re-read. Only when a full map rotation has passed without a <code>bad load</code> should you consider the update settled — and keep the pre-update tarball until then.</p> | |
| 0 | 15 |
