Add 3 tutorials (3 files)
Browse Source
Daemon666 committed
parent f701aba00a
commit aea08afc89186b3c029a3de38bb4c20377f74efb
3 changed files
with 190 additions and 0 deletions
A
fix-amxx-module-failed-to-load/en.md
+47 -0
A
install-amxx-plugin-files/en.md
+73 -0
A
install-yapb-bots/en.md
+70 -0
fix-amxx-module-failed-to-load/en.md
A
| @@ -0,0 +1,47 @@ | ||
| 1 | +--- | |
| 2 | +title: "Fix: 'Module failed to load' in AMX Mod X" | |
| 3 | +excerpt: "Work through every reason AMX Mod X reports a module as failed to load: wrong architecture, missing system libraries, version mismatch, and modules.ini configuration." | |
| 4 | +category: "errors" | |
| 5 | +tags: "amxmodx, modules" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>When AMX Mod X cannot bring a module online you see it in the console at boot and in <code>amxx modules</code>: a module sitting at <code>error</code> or <code>bad load</code> instead of <code>running</code>. Modules are native <code>.so</code>/<code>.dll</code> binaries (MySQL, GeoIP, SQLite, cURL, and so on) that expose natives to your plugins, so a failed module takes down every plugin that depends on it. The reason is almost always one of four things, and the AMXX log names which.</p> | |
| 10 | + | |
| 11 | +<h2>1. Read the actual reason</h2> | |
| 12 | +<p>Do not guess from the console. Open the dated log under <code>addons/amxmodx/logs/</code> and find the module line. AMXX states the cause explicitly — <em>compiled for a newer AMX Mod X</em>, <em>couldn't find</em>, <em>wrong architecture</em>. In the console:</p> | |
| 13 | +<pre>amxx modules</pre> | |
| 14 | +<p>lists every module with its status. That plus the log is your whole diagnosis.</p> | |
| 15 | + | |
| 16 | +<h2>2. Wrong architecture (the number-one cause)</h2> | |
| 17 | +<p>Everything in a CS 1.6 server is 32-bit. A module built for x86-64, or a Windows <code>.dll</code> dropped onto Linux, will never load. Check it:</p> | |
| 18 | +<pre>cd addons/amxmodx/modules | |
| 19 | +file mysql_amxx_i386.so</pre> | |
| 20 | +<p>It must report <code>ELF 32-bit LSB shared object, Intel 80386</code>. If it says <code>x86-64</code>, you downloaded the wrong build — get the i386 one. Linux modules end in <code>_i386.so</code> or <code>_amxx_i386.so</code>; Windows ones end in <code>_amxx.dll</code>. They are not interchangeable.</p> | |
| 21 | + | |
| 22 | +<h2>3. Missing system libraries</h2> | |
| 23 | +<p>A module can be the right architecture and still fail because a shared library it links against is not installed — the classic case being the MySQL module needing the 32-bit client library. Check what it needs:</p> | |
| 24 | +<pre>ldd mysql_amxx_i386.so</pre> | |
| 25 | +<p>Any line reading <code>not found</code> is a missing dependency you must install as its 32-bit (<code>:i386</code>) package. This is the same class of problem as the engine's missing loader — see <a href="/tutorials/install-32bit-libraries-cs16-linux">the 32-bit library guide</a>. For the database modules specifically, <a href="/tutorials/install-mysql-module-amxx">installing the MySQL module</a> covers exactly which library the loader wants.</p> | |
| 26 | + | |
| 27 | +<h2>4. Version mismatch</h2> | |
| 28 | +<p>A module compiled against a newer AMXX than you run will refuse to load with a message like <em>module is compiled for a newer version of AMX Mod X</em>. The fix is to match them: either upgrade AMXX, or use a module build for your version. This is why mixing a fresh module into an ancient 1.8.2 install so often fails — the natives it expects do not exist yet. If you are still on 1.8.2, this is a good moment to read <a href="/tutorials/upgrade-amxmodx-1-8-2-to-1-10">upgrading to 1.10</a>. Conversely, a <em>very</em> old module can fail against a current AMXX; keep the whole set from one era.</p> | |
| 29 | + | |
| 30 | +<h2>5. It is not being loaded at all</h2> | |
| 31 | +<p>If the module is not even listed, it is not being loaded. Modules load from <code>addons/amxmodx/configs/modules.ini</code>, or automatically when a plugin declares it needs them. Make sure the file is present in <code>addons/amxmodx/modules/</code> and, if you use an explicit list, that its name is in <code>modules.ini</code> without a leading semicolon (which comments it out). See <a href="/tutorials/install-amxx-modules">installing AMXX modules</a> for the load mechanics.</p> | |
| 32 | +<p>One subtlety catches people: modern AMXX auto-loads a module the instant a plugin <code>#include</code>s its header, whether or not it is in <code>modules.ini</code>. So a module can be "not loaded" simply because no plugin references it — which is harmless — or it can fail to auto-load and take the plugin down with it. Match the log line to the plugin that triggered the load, not just to the module in isolation.</p> | |
| 33 | + | |
| 34 | +<h2>Common errors</h2> | |
| 35 | +<ul> | |
| 36 | +<li><strong><code>Module requires newer AMX Mod X</code></strong> — version mismatch, step 4. Match module and core versions.</li> | |
| 37 | +<li><strong><code>Cstrike module required</code> from a plugin, not a module</strong> — that is a plugin failing because a module it needs is not loaded, often because the module itself failed here. Fix the module first. Details in <a href="/tutorials/fix-module-cstrike-required">that error</a>.</li> | |
| 38 | +<li><strong>Module <code>running</code> but a plugin still says it is missing</strong> — the plugin needs a native the module does not export in your version. Upgrade the module.</li> | |
| 39 | +<li><strong><code>libmysqlclient.so.XX: cannot open shared object file</code></strong> — the exact "missing 32-bit library" case from step 3. Install the i386 MySQL client library.</li> | |
| 40 | +</ul> | |
| 41 | + | |
| 42 | +<h2>Verification</h2> | |
| 43 | +<p>After the fix, restart and run:</p> | |
| 44 | +<pre>amxx modules</pre> | |
| 45 | +<p>Every module you expect should read <code>running</code>. Then load a plugin that uses it and confirm the plugin itself starts:</p> | |
| 46 | +<pre>amxx plugins</pre> | |
| 47 | +<p>A module at <code>running</code> and its dependent plugins at <code>running</code> means the chain is whole. If the module is up but a plugin still errors, the problem has moved into the plugin — check its log line the same way.</p> |
install-amxx-plugin-files/en.md
A
| @@ -0,0 +1,73 @@ | ||
| 1 | +--- | |
| 2 | +title: "How to Install an AMXX Plugin (.amxx) Correctly" | |
| 3 | +excerpt: "The correct way to install an AMX Mod X plugin: where the .amxx goes, registering it in plugins.ini, config and module dependencies, and why plugins silently fail to load." | |
| 4 | +category: "installation" | |
| 5 | +tags: "plugins, amxmodx" | |
| 6 | +image: "" | |
| 7 | +read_time: "7 min read" | |
| 8 | +--- | |
| 9 | +<p>Installing an AMX Mod X plugin is four files-and-folders decisions that people get wrong in predictable ways: the compiled plugin goes in one place, it must be registered in another, its modules must be loaded, and its config must exist. Miss any one and the plugin is silently absent — AMXX does not crash, it just skips what it cannot load. This guide is the correct, boring procedure and the exact console commands that tell you it worked.</p> | |
| 10 | + | |
| 11 | +<h2>1. Put the .amxx in the plugins directory</h2> | |
| 12 | +<p>Compiled plugins live in exactly one place:</p> | |
| 13 | +<pre>cstrike/addons/amxmodx/plugins/</pre> | |
| 14 | +<p>Copy the <code>.amxx</code> there. If you have the source (<code>.sma</code>), the honest and safer path is to compile it yourself first — see <a href="/tutorials/download-cs16-server-files-safely">sourcing files safely</a>:</p> | |
| 15 | +<pre>cd cstrike/addons/amxmodx/scripting | |
| 16 | +./amxxpc myplugin.sma | |
| 17 | +cp compiled/myplugin.amxx ../plugins/</pre> | |
| 18 | +<p>On Linux <code>amxxpc</code> is 32-bit; if it will not run, that is a missing i386 library problem, not a plugin problem.</p> | |
| 19 | + | |
| 20 | +<h2>2. Register it in plugins.ini</h2> | |
| 21 | +<p>AMXX only loads what is listed in:</p> | |
| 22 | +<pre>cstrike/addons/amxmodx/configs/plugins.ini</pre> | |
| 23 | +<p>Add one line with just the filename — no path:</p> | |
| 24 | +<pre>myplugin.amxx</pre> | |
| 25 | +<p>A leading <code>;</code> comments the line out. This is the single most common "installed but not loading" cause: the file is in <code>plugins/</code> but was never added here, or the line is still commented.</p> | |
| 26 | + | |
| 27 | +<h2>3. Provide the modules the plugin needs</h2> | |
| 28 | +<p>Most plugins depend on modules — <code>cstrike</code>, <code>fun</code>, <code>engine</code>, <code>fakemeta</code>, <code>hamsandwich</code>, <code>sqlx</code>, <code>geoip</code> and so on. If the plugin's source has <code>#include <cstrike></code>, the <code>cstrike</code> module must be enabled in:</p> | |
| 29 | +<pre>cstrike/addons/amxmodx/configs/modules.ini</pre> | |
| 30 | +<p>Modern AMXX auto-loads most bundled modules, but not third-party ones. A plugin that needs a module you do not have fails with <code>Plugin failed to load: Function not found</code>. See <a href="/tutorials/install-amxx-modules">installing AMXX modules</a>.</p> | |
| 31 | + | |
| 32 | +<h2>4. Create the config the plugin expects</h2> | |
| 33 | +<p>Plugins register cvars at load; you set them in a config that runs after the plugin exists. The standard file is:</p> | |
| 34 | +<pre>cstrike/addons/amxmodx/configs/amxx.cfg</pre> | |
| 35 | +<p>Put the plugin's cvars there, or in <code>cstrike/server.cfg</code>. Do not set a plugin's cvar in <code>server.cfg</code> if the plugin loads later than the cfg executes — for anything AMXX, prefer <code>amxx.cfg</code> or the plugin's own <code>.cfg</code> under <code>configs/</code>.</p> | |
| 36 | + | |
| 37 | +<h2>5. Reload without a full restart (optional)</h2> | |
| 38 | +<p>You can load a plugin live for testing:</p> | |
| 39 | +<pre>amxx plugins | |
| 40 | +amx_plugins | |
| 41 | +amxx pause myplugin.amxx | |
| 42 | +amxx unpause myplugin.amxx</pre> | |
| 43 | +<p>But a newly-added plugin needs the config re-read at map start, so the reliable way to activate a fresh install is <code>changelevel</code> or a restart. "It works after a map change but not now" is expected, not a bug.</p> | |
| 44 | + | |
| 45 | +<h2>Common errors</h2> | |
| 46 | +<ul> | |
| 47 | +<li><strong><code>Plugin file open error</code></strong> — the filename in <code>plugins.ini</code> does not match a file in <code>plugins/</code>. Check spelling and case; Linux is case-sensitive.</li> | |
| 48 | +<li><strong><code>bad load</code></strong> next to the plugin in <code>amxx plugins</code> — the <code>.amxx</code> was compiled for a newer AMXX than you run. Recompile the <code>.sma</code> for your version, or <a href="/tutorials/upgrade-amxmodx-1-8-2-to-1-10">upgrade AMXX</a>.</li> | |
| 49 | +<li><strong><code>Plugin failed to load: Function not found</code></strong> — a required module is missing. The plugin calls a native that lives in a module you did not load.</li> | |
| 50 | +<li><strong>Plugin shows <code>running</code> but does nothing</strong> — its cvars are unset or set in a cfg that runs before it loads. Move them to <code>amxx.cfg</code> and verify with the cvar name in console.</li> | |
| 51 | +<li><strong>Access-restricted command "you have no access"</strong> — the plugin needs an admin flag you do not hold. Check your entry in <code>users.ini</code>.</li> | |
| 52 | +</ul> | |
| 53 | + | |
| 54 | +<h2>Verification</h2> | |
| 55 | +<p>Change the map, then in the server console:</p> | |
| 56 | +<pre>amxx plugins</pre> | |
| 57 | +<p>Find your plugin's line. It must read <code>running</code>. Anything else — <code>bad load</code>, <code>error</code>, <code>debug</code> — is a real failure, and the reason is printed above in the log at load time. Confirm the plugin's own effect (a menu, a command, a chat line) and check its cvars resolve:</p> | |
| 58 | +<pre>amx_myplugin_enabled</pre> | |
| 59 | +<p>If the line loads and the feature responds, the install is complete. To manage plugins in bulk from in-game, pair this with the <a href="/plugins/csb-admin-menu">CSB Admin Menu</a>.</p> | |
| 60 | + | |
| 61 | +<h2>Where each piece lives — quick reference</h2> | |
| 62 | +<p>Almost every install problem is a file in the wrong one of these four locations. Keep this table next to you:</p> | |
| 63 | +<table> | |
| 64 | +<thead><tr><th>Item</th><th>Path under cstrike/</th><th>Registered in</th></tr></thead> | |
| 65 | +<tbody> | |
| 66 | +<tr><td>Compiled plugin</td><td>addons/amxmodx/plugins/*.amxx</td><td>configs/plugins.ini</td></tr> | |
| 67 | +<tr><td>Plugin source</td><td>addons/amxmodx/scripting/*.sma</td><td>compiled with amxxpc</td></tr> | |
| 68 | +<tr><td>Module (.so/.dll)</td><td>addons/amxmodx/modules/</td><td>configs/modules.ini</td></tr> | |
| 69 | +<tr><td>Cvar values</td><td>configs/amxx.cfg</td><td>runs after plugins load</td></tr> | |
| 70 | +<tr><td>Admin list</td><td>configs/users.ini</td><td>SteamID or name+password</td></tr> | |
| 71 | +</tbody> | |
| 72 | +</table> | |
| 73 | +<p>The mental model that prevents most mistakes: the file in <code>plugins/</code> is what runs, but <code>plugins.ini</code> is what decides <em>whether</em> it runs, <code>modules.ini</code> decides whether it <em>can</em> run, and <code>amxx.cfg</code> decides <em>how</em> it behaves. A plugin needs all four to be right at once, and AMXX will not warn you about the one you missed — it just quietly does less than you expected. When something "does nothing", check them in that order: is it in <code>plugins/</code>, is it listed, are its modules loaded, are its cvars set.</p> |
install-yapb-bots/en.md
A
| @@ -0,0 +1,70 @@ | ||
| 1 | +--- | |
| 2 | +title: "How to Install YaPB Bots on CS 1.6 (2026)" | |
| 3 | +excerpt: "Install YaPB, the actively maintained CS 1.6 bot, as a Metamod plugin, get the navigation graph loaded, and control bot count with yb_quota." | |
| 4 | +category: "installation" | |
| 5 | +tags: "yapb, bots" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>YaPB is the bot that is still maintained. Where the old Podbot/POD-Bot and Zbot forks are frozen, YaPB gets regular releases, understands modern ReHLDS/ReGameDLL servers, and ships an automatic navigation-graph system so you are not hand-placing waypoints on every map. It loads as a Metamod plugin — not an AMX Mod X plugin — which is the detail most failed installs get wrong.</p> | |
| 10 | + | |
| 11 | +<h2>1. Prerequisites</h2> | |
| 12 | +<p>YaPB needs Metamod. It does <strong>not</strong> need AMX Mod X, though it coexists with it happily. Confirm Metamod is loading first:</p> | |
| 13 | +<pre>meta version</pre> | |
| 14 | +<p>If that is an unknown command, install <a href="/tutorials/install-metamod-r">Metamod-r</a> before going further.</p> | |
| 15 | + | |
| 16 | +<h2>2. Place the YaPB files</h2> | |
| 17 | +<p>Download the current YaPB release for your platform from the project's releases page and extract it into <code>cstrike/</code>. The layout is:</p> | |
| 18 | +<pre>cstrike/addons/yapb/bin/yapb.so (Linux; yapb.dll on Windows) | |
| 19 | +cstrike/addons/yapb/conf/ (config files) | |
| 20 | +cstrike/addons/yapb/data/ (graphs, names, chat)</pre> | |
| 21 | +<p>Keep the whole <code>addons/yapb/</code> tree together — the plugin looks for its config and data relative to its own folder, and splitting them is a common cause of "bots load but never spawn".</p> | |
| 22 | + | |
| 23 | +<h2>3. Register YaPB with Metamod</h2> | |
| 24 | +<p>Add YaPB to <code>cstrike/addons/metamod/plugins.ini</code>:</p> | |
| 25 | +<pre>linux addons/yapb/bin/yapb.so</pre> | |
| 26 | +<p>On Windows:</p> | |
| 27 | +<pre>win32 addons/yapb/bin/yapb.dll</pre> | |
| 28 | +<p>Order relative to AMXX does not matter for YaPB, so append it. Restart the server and confirm it loaded:</p> | |
| 29 | +<pre>meta list</pre> | |
| 30 | +<p>YaPB should show as <code>RUN</code>.</p> | |
| 31 | + | |
| 32 | +<h2>4. Add bots</h2> | |
| 33 | +<p>YaPB is driven from the console with the <code>yb</code> command family. The most important cvar is the quota, which keeps a target number of bots topped up as humans join and leave:</p> | |
| 34 | +<pre>yb_quota 8</pre> | |
| 35 | +<p>To add bots manually instead:</p> | |
| 36 | +<pre>yb add // one bot, random team/skill | |
| 37 | +yb fill // fill the server up to maxplayers | |
| 38 | +yb kickall // remove every bot</pre> | |
| 39 | +<p>Put the persistent settings in a config that runs at start. YaPB reads its own config from <code>addons/yapb/conf/</code>; set the quota and difficulty there so bots are present without you typing anything:</p> | |
| 40 | +<pre>yb_quota 8 | |
| 41 | +yb_difficulty 3 | |
| 42 | +yb_quota_mode "fill"</pre> | |
| 43 | +<p>Read the shipped config file for the exact cvar list your version ships — YaPB has renamed cvars across major versions, and a setting that does not exist is silently ignored.</p> | |
| 44 | + | |
| 45 | +<h2>5. The navigation graph</h2> | |
| 46 | +<p>Bots need a navigation graph for a map or they will stand still at spawn. This is the single biggest source of "the bots do nothing" reports. YaPB's graph system replaces the old <code>.pwf</code> waypoints:</p> | |
| 47 | +<ul> | |
| 48 | +<li>For popular maps (de_dust2, de_inferno, cs_office, etc.), YaPB can download a community graph automatically the first time the map loads, provided the server has outbound internet access.</li> | |
| 49 | +<li>Downloaded and generated graphs are stored under <code>addons/yapb/data/graph/</code> as <code><mapname>.graph</code>.</li> | |
| 50 | +<li>For a custom map with no graph, you can have YaPB analyze the map to generate one, or place a graph file yourself.</li> | |
| 51 | +</ul> | |
| 52 | +<p>Check whether the current map has a graph:</p> | |
| 53 | +<pre>ls cstrike/addons/yapb/data/graph/</pre> | |
| 54 | +<p>If <code>de_dust2.graph</code> exists after loading that map, auto-download worked. If your server is firewalled off from the internet, pre-place the graph files manually.</p> | |
| 55 | + | |
| 56 | +<h2>Common errors</h2> | |
| 57 | +<ul> | |
| 58 | +<li><strong>Bots stand at spawn and do nothing</strong> — no navigation graph for that map. Confirm a <code>.graph</code> exists in <code>data/graph/</code>, or let YaPB generate/download one.</li> | |
| 59 | +<li><strong><code>yb_quota</code> is an unknown command</strong> — YaPB is not loaded. Check <code>meta list</code>; if it is missing, the path in <code>plugins.ini</code> is wrong or the module is the wrong platform. Verify with <code>file addons/yapb/bin/yapb.so</code> that it is <em>ELF 32-bit, Intel 80386</em>.</li> | |
| 60 | +<li><strong>Bots ignore <code>maxplayers</code> and overfill</strong> — you set both a manual <code>yb add</code> loop and a quota. Use the quota alone; it manages the count.</li> | |
| 61 | +<li><strong>Graph download fails</strong> — the server has no outbound internet, or the map is unknown to the graph database. Place the <code>.graph</code> file manually under <code>data/graph/</code>.</li> | |
| 62 | +<li><strong>Bots on a ReGameDLL server behave oddly</strong> — update YaPB; older builds predate current <a href="/tutorials/install-regamedll-cs16">ReGameDLL_CS</a> behaviour.</li> | |
| 63 | +</ul> | |
| 64 | + | |
| 65 | +<h2>Verification</h2> | |
| 66 | +<pre>yb_quota 4</pre> | |
| 67 | +<p>Load <code>de_dust2</code>, then type <code>status</code> in the console. You should see four bots listed with bot-style ids, and on the map they should leave spawn, buy, take routes, and engage. If they move and fight, the graph is loaded and the install is complete.</p> | |
| 68 | + | |
| 69 | +<h2>Difficulty and per-map tuning</h2> | |
| 70 | +<p>Out of the box YaPB mixes skill levels so a round is not uniformly brutal. You control the overall level with the difficulty cvar and, in the config, the spread of skills bots are assigned. If bots are too sharp for a public server, lower the difficulty rather than removing them — a wall of aimbots empties a server as fast as an empty one does. YaPB also supports named personalities (aggressive, normal, careful) that change how bots push and hold; those live in the config under <code>addons/yapb/conf/</code>. For a map that plays badly with the auto-downloaded graph, regenerate the graph in-game and save it, and YaPB will prefer your local file from then on. Bots obey the same server cvars as humans, so <code>mp_startmoney</code>, <code>mp_freezetime</code> and <code>mp_buytime</code> all shape how they play — set them in your <a href="/tutorials/setup-server-cfg-cs16">annotated server.cfg</a> and keep the quota there too so a fresh server is never empty. If you also run <a href="/tutorials/install-regamedll-cs16">ReGameDLL_CS</a>, keep YaPB current so it tracks the game library's behaviour.</p> | |
| 0 | 71 |
