Add 2 tutorials (2 files)
Browse Source
Daemon666 committed
parent f606940645
commit 066de2afbec5740b7e851149e407255c0082d7c2
2 changed files
with 125 additions and 0 deletions
fix-plugins-bad-load-after-19/en.md
A
| @@ -0,0 +1,57 @@ | ||
| 1 | +--- | |
| 2 | +title: "Fix: Plugins Show 'bad load' After Upgrading to AMXX 1.9/1.10" | |
| 3 | +excerpt: "Why your AMX Mod X plugins report 'bad load' after an upgrade, how to tell a Metamod failure from an AMXX one, and the module mismatch that causes almost all of it." | |
| 4 | +category: "errors" | |
| 5 | +tags: "amxmodx, upgrade" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>You dropped a newer AMX Mod X over an old install, restarted, and now half your plugins sit in the list with the status <code>bad load</code>. This is almost never a corrupt plugin. It is a version-mixing problem: the AMXX core got upgraded but its <em>modules</em> did not, and a plugin that needs a module the core can no longer load fails at start. The good news is that <code>bad load</code> is a precise symptom, and once you know where to read it, the fix is mechanical.</p> | |
| 10 | + | |
| 11 | +<h2>1. Read the right list first</h2> | |
| 12 | +<p>There are two different "bad load" states and they live in two different lists. Check both from the server console (or RCON):</p> | |
| 13 | +<pre>meta list | |
| 14 | +amxx plugins | |
| 15 | +amxx modules</pre> | |
| 16 | +<p><code>meta list</code> is Metamod's view. If <code>amxmodx_mm</code> itself shows <code>bad load</code> here, AMXX never even started and every plugin will look broken — that is an engine/ABI problem, not a per-plugin one. <code>amxx plugins</code> is AMXX's own view; a plugin marked <code>bad load</code> there means the AMXX core loaded fine but that specific plugin could not.</p> | |
| 17 | + | |
| 18 | +<h2>2. If amxmodx_mm is 'bad load' in meta list</h2> | |
| 19 | +<p>This means Metamod could not load the AMXX core binary. The usual causes:</p> | |
| 20 | +<ul> | |
| 21 | +<li>Wrong architecture — a 64-bit or Windows binary in a Linux tree. Confirm with <code>file addons/amxmodx/dlls/amxmodx_mm_i386.so</code>; it must say <em>ELF 32-bit LSB shared object, Intel 80386</em>.</li> | |
| 22 | +<li>A stale path in <code>addons/metamod/plugins.ini</code> pointing at a file you deleted.</li> | |
| 23 | +<li>Metamod itself is too old for the ABI. If you are still on classic Metamod, move to <a href="/tutorials/install-metamod-r">Metamod-r</a>.</li> | |
| 24 | +</ul> | |
| 25 | +<p>Fix that before touching anything else — nothing below matters until <code>meta list</code> shows <code>amxmodx_mm</code> as <code>RUN</code>.</p> | |
| 26 | + | |
| 27 | +<h2>3. Replace the modules, not just the core</h2> | |
| 28 | +<p>This is the actual cause in the large majority of upgrade cases. AMXX modules (<code>fakemeta_amxx_i386.so</code>, <code>hamsandwich_amxx_i386.so</code>, <code>cstrike_amxx_i386.so</code>, <code>sqlite_amxx_i386.so</code>, and so on) are versioned <strong>together</strong> with the core. When you upgraded, you likely overwrote <code>dlls/amxmodx_mm_i386.so</code> and the <code>plugins/</code> folder but left the old 1.8.2 modules in <code>addons/amxmodx/modules/</code>. A 1.8.2 module against a 1.10 core fails to load, and every plugin that <code>#include</code>d it is now missing its natives.</p> | |
| 29 | +<p>Copy the entire modules directory from the same release you upgraded to:</p> | |
| 30 | +<pre>cp /path/to/amxx-1.10/addons/amxmodx/modules/*.so \ | |
| 31 | + /home/steam/hlds/cstrike/addons/amxmodx/modules/</pre> | |
| 32 | +<p>Then check what actually loaded:</p> | |
| 33 | +<pre>amxx modules</pre> | |
| 34 | +<p>Any module that is not <code>running</code> here is your smoking gun. The AMXX log will name it — look in <code>addons/amxmodx/logs/</code> for a line such as <code>Module requires a newer version of AMX Mod X</code> or a native-not-found error.</p> | |
| 35 | + | |
| 36 | +<h2>4. Recompile plugins that use changed natives</h2> | |
| 37 | +<p>Old <code>.amxx</code> bytecode usually keeps working across versions, but a plugin that called a native which was renamed or removed will still <code>bad load</code> even with the right module present. The log entry looks like:</p> | |
| 38 | +<pre>Plugin "yourplugin.amxx" failed to load: Function not found</pre> | |
| 39 | +<p>Recompile the <code>.sma</code> against the matching AMXX includes. If you do not have the source, you have to find a build that targets your version. See <a href="/tutorials/install-amx-mod-x-1-9">installing AMXX 1.9</a> for how the versions line up, and <a href="/tutorials/upgrade-amxmodx-1-8-2-to-1-10">the full 1.8.2 to 1.10 upgrade</a> for the complete file list you must swap.</p> | |
| 40 | + | |
| 41 | +<h2>5. Check plugins.ini and configs</h2> | |
| 42 | +<p>A plugin only loads if it is listed in <code>addons/amxmodx/configs/plugins.ini</code> and the <code>.amxx</code> file exists in <code>addons/amxmodx/plugins/</code>. A typo or a Windows/Linux filename-case mismatch shows as <code>bad load</code> too. Linux is case-sensitive; <code>AdminMenu.amxx</code> and <code>adminmenu.amxx</code> are different files.</p> | |
| 43 | + | |
| 44 | +<h2>Common errors</h2> | |
| 45 | +<ul> | |
| 46 | +<li><strong><code>bad load</code> in <code>amxx plugins</code> but modules are fine</strong> — the plugin needs a native from a module that is present but a different version. Line up all modules to one release.</li> | |
| 47 | +<li><strong><code>Module requires a newer version of AMX Mod X</code></strong> — a module is <em>newer</em> than the core. You upgraded modules but not the core; do both.</li> | |
| 48 | +<li><strong>Everything is <code>bad load</code> at once</strong> — read <code>meta list</code>; the AMXX core itself failed and this is not a per-plugin issue.</li> | |
| 49 | +<li><strong>Works on Windows, breaks on Linux after copying</strong> — filename case, or you copied <code>_amxx.dll</code> modules into a Linux install. Linux needs the <code>_i386.so</code> files.</li> | |
| 50 | +</ul> | |
| 51 | + | |
| 52 | +<h2>Verification</h2> | |
| 53 | +<p>Restart the server and run:</p> | |
| 54 | +<pre>meta list | |
| 55 | +amxx modules | |
| 56 | +amxx plugins</pre> | |
| 57 | +<p>You are done when <code>amxmodx_mm</code> is <code>RUN</code>, every module is <code>running</code>, and every plugin is <code>running</code> with none left in <code>bad load</code>. Change the map once and re-check — a plugin that loads on boot but references a missing native only in a late code path can still be healthy in the list, so spot-test the features you actually rely on. If a single plugin remains stubborn, isolate it with <a href="/tutorials/find-crashing-plugin">the plugin-isolation method</a>.</p> |
fix-server-cfg-not-executing/en.md
A
| @@ -0,0 +1,68 @@ | ||
| 1 | +--- | |
| 2 | +title: "Fix: server.cfg Settings Not Applying" | |
| 3 | +excerpt: "Your server.cfg edits are ignored? It is almost always the execution order or the hidden .txt extension. Here is the exact sequence the engine reads and how to make settings stick." | |
| 4 | +category: "errors" | |
| 5 | +tags: "server.cfg, config" | |
| 6 | +image: "" | |
| 7 | +read_time: "7 min read" | |
| 8 | +--- | |
| 9 | +<p>You edit <code>server.cfg</code>, restart, and half your settings are ignored. This is almost never a "config is broken" problem and almost always an <em>ordering</em> or <em>naming</em> problem: the engine reads several config files in a fixed sequence, a later one overrides an earlier one, and a handful of cvars cannot be set from <code>server.cfg</code> at all. This guide walks the real execution order and the traps that silently discard your settings.</p> | |
| 10 | + | |
| 11 | +<h2>1. Confirm the file is where the engine actually looks</h2> | |
| 12 | +<p><code>server.cfg</code> must live in the mod folder, next to <code>maps/</code> and <code>addons/</code>:</p> | |
| 13 | +<pre>/home/steam/hlds/cstrike/server.cfg</pre> | |
| 14 | +<p>Not in the server root, not in a <code>config/</code> subfolder. HLDS execs <code>cstrike/server.cfg</code> and nothing else by that name.</p> | |
| 15 | + | |
| 16 | +<h2>2. Rule out the hidden .txt extension</h2> | |
| 17 | +<p>On Windows, Explorer hides known extensions, so a file you "named" <code>server.cfg</code> is really <code>server.cfg.txt</code>. The engine never execs it and never warns you.</p> | |
| 18 | +<pre>dir C:\hlds\cstrike\server.cfg*</pre> | |
| 19 | +<p>If that lists <code>server.cfg.txt</code>, rename it, and turn on <em>File name extensions</em> in the Explorer View ribbon first. On Linux, run <code>ls -la</code> and check for a trailing space or a stray capital letter in the name.</p> | |
| 20 | + | |
| 21 | +<h2>3. Understand when server.cfg runs</h2> | |
| 22 | +<p><code>server.cfg</code> is executed <strong>once per map load</strong>, after the map has started — not the instant the process boots. Any cvar you change live in the console is overwritten on the next map by whatever server.cfg contains. Conversely, a value you set in server.cfg is overridden if something later in the chain sets it again. The order that matters:</p> | |
| 23 | +<ol> | |
| 24 | +<li>Command-line <code>+cvar</code> arguments</li> | |
| 25 | +<li><code>cstrike/server.cfg</code> (on map start)</li> | |
| 26 | +<li>A per-map file such as <code>cstrike/de_dust2.cfg</code>, if one exists</li> | |
| 27 | +<li>AMX Mod X configs (<code>addons/amxmodx/configs/amxx.cfg</code> and per-plugin configs), which are exec'd a moment later during <code>plugin_cfg</code></li> | |
| 28 | +</ol> | |
| 29 | +<p>The last writer wins. If <code>amxx.cfg</code> or a plugin sets <code>mp_freezetime</code>, it beats your server.cfg because it runs afterward.</p> | |
| 30 | + | |
| 31 | +<h2>4. Watch it execute</h2> | |
| 32 | +<p>Set a marker at the very top of server.cfg:</p> | |
| 33 | +<pre>echo "===== server.cfg START =====" | |
| 34 | +hostname "My Server"</pre> | |
| 35 | +<p>Restart and watch the console. If the banner never prints, the file is not being read (wrong path or wrong name — go back to steps 1–2). You can also force it in the live console:</p> | |
| 36 | +<pre>exec server.cfg</pre> | |
| 37 | +<p>If a manual <code>exec</code> applies the values but a restart does not, something later in the sequence is overriding them.</p> | |
| 38 | + | |
| 39 | +<h2>5. Cvars server.cfg cannot set</h2> | |
| 40 | +<ul> | |
| 41 | +<li><strong><code>maxplayers</code></strong> — set with <code>+maxplayers 20</code> on the command line. <code>maxplayers 20</code> in server.cfg does nothing.</li> | |
| 42 | +<li><strong><code>port</code> / <code>ip</code></strong> — command line only (<code>-port 27015 -ip 0.0.0.0</code>).</li> | |
| 43 | +<li><strong><code>sv_lan</code></strong> — works in server.cfg, but if you also pass <code>+sv_lan 1</code> on the command line the two can fight; keep it in exactly one place. See <a href="/tutorials/fix-server-only-visible-on-lan">server only visible on LAN</a>.</li> | |
| 44 | +</ul> | |
| 45 | + | |
| 46 | +<h2>6. Syntax traps</h2> | |
| 47 | +<ul> | |
| 48 | +<li>Comments are <code>//</code>, not <code>#</code>. A <code>#</code> line is parsed as a broken command and spams <code>Unknown command</code>.</li> | |
| 49 | +<li>Values with spaces need quotes: <code>hostname "My Cool Server"</code>. Without quotes only the first word is taken.</li> | |
| 50 | +<li>Save as plain UTF-8 <strong>without a BOM</strong>. A byte-order mark makes the engine choke on the first line only.</li> | |
| 51 | +<li>One command per line; no trailing semicolons.</li> | |
| 52 | +</ul> | |
| 53 | + | |
| 54 | +<h2>7. Nested execs and read-only cvars</h2> | |
| 55 | +<p>A single <code>server.cfg</code> can chain into others with <code>exec</code>. If yours does <code>exec rates.cfg</code> and that file is missing, the engine prints <code>Couldn't exec rates.cfg</code> and silently skips whatever you expected it to set — so scan the boot log for any <code>Couldn't exec</code> line. Separately, a few cvars are read-only or <em>latched</em>: they only take a new value on the next map, not immediately. If a value refuses to change even after a manual <code>exec</code>, it is latched — change the map and re-check. And never rely on setting a cvar that belongs to a plugin (an <code>amx_</code> or a ReGameDLL <code>mp_</code> cvar) before that plugin has loaded; put those in a config the plugin execs, or in <code>amxx.cfg</code>, which runs after the plugin is ready.</p> | |
| 56 | + | |
| 57 | +<h2>Common errors</h2> | |
| 58 | +<ul> | |
| 59 | +<li><strong>Setting applies, then reverts on map change</strong> — an AMXX plugin or a per-map <code>.cfg</code> resets it. Grep your configs: <code>grep -rn mp_freezetime cstrike/</code>.</li> | |
| 60 | +<li><strong>Nothing in server.cfg applies</strong> — the file is <code>server.cfg.txt</code>, or it is in the wrong directory.</li> | |
| 61 | +<li><strong>Only the first line applies</strong> — a BOM or a bad character on line 2; re-save as plain UTF-8.</li> | |
| 62 | +<li><strong><code>Unknown command</code> spam at boot</strong> — you used <code>#</code> comments, or referenced a cvar from a plugin that is not loaded yet.</li> | |
| 63 | +</ul> | |
| 64 | + | |
| 65 | +<h2>Verification</h2> | |
| 66 | +<p>After a restart, read the value back by typing the cvar name with no argument:</p> | |
| 67 | +<pre>mp_freezetime</pre> | |
| 68 | +<p>The console prints <code>"mp_freezetime" is "3"</code>. If that matches server.cfg, the setting stuck. Repeat for every cvar you care about — that read-back is the only proof that survives the full exec chain. For a clean annotated file to start from, see <a href="/tutorials/install-cs16-dedicated-server-linux-steamcmd">the Linux install guide</a>.</p> | |
| 0 | 69 |
