Add fix-module-compiled-newer-amxx/en.md
Browse Source
1 changed file
with 92 additions and 0 deletions
fix-module-compiled-newer-amxx/en.md
A
| @@ -0,0 +1,92 @@ | ||
| 1 | +--- | |
| 2 | +title: "Fix: AMXX Module Compiled for a Newer AMX Mod X Version" | |
| 3 | +excerpt: "What AMX Mod X really prints when a module or plugin comes from a different release than the core, how to read the versions on your server, and how to line up 1.8.2, 1.9 and 1.10 so it stops." | |
| 4 | +category: "errors" | |
| 5 | +tags: "amxx, modules, versions, upgrade, bad load" | |
| 6 | +image: "" | |
| 7 | +read_time: "7 min read" | |
| 8 | +--- | |
| 9 | +<p>You copied a module from another AMX Mod X release, or upgraded the core and kept the old <code>modules/</code> folder, and now <code>amxx modules</code> shows a module as <code>newer</code> instead of <code>running</code> while every plugin that needs it is <code>bad load</code>. Forum posts call this "module was compiled for a newer AMXX version". AMX Mod X never prints that sentence. It prints one of the lines below, and the fix for all of them is the same: core, modules and data files from one release.</p> | |
| 10 | + | |
| 11 | +<h2>1. The real error lines</h2> | |
| 12 | +<p>They appear in the server console at startup and in <code>addons/amxmodx/logs/LYYYYMMDD.log</code>, each after a line that just says <code>Error:</code>. The one you will actually meet:</p> | |
| 13 | +<pre><code>[AMXX] Module requested a not exisitng function (file "cstrike/addons/amxmodx/modules/cstrike_amxx_i386.so") (func "GetConfigManager")</code></pre> | |
| 14 | +<p>When a module starts, it asks the core for every helper function it was built against, by name. AMX Mod X 1.9 added six of them: <code>GetConfigManager</code>, <code>LoadAmxScriptEx</code>, <code>SetAmxStringUTF8Char</code>, <code>SetAmxStringUTF8Cell</code>, <code>GetAmxStringNull</code> and <code>GetAmxVectorNull</code>. A 1.8.2 core does not have them, so any official 1.9 or 1.10 module stops at the first, <code>GetConfigManager</code>, and is marked <code>newer</code>. The misspelling is 1.8.2's own (1.9 and later print <code>not existing</code>), so search for <code>requested a not</code>.</p> | |
| 15 | +<pre><code>[AMXX] Module has a newer interface version (file "cstrike/addons/amxmodx/modules/foo_amxx_i386.so"). Please download a new amxmodx.</code></pre> | |
| 16 | +<p>The module reports a higher interface number than the core. Official releases from 1.8.2 to 1.10 all use the same number, so this means a module built for some other branch or SDK. Status <code>newer</code>.</p> | |
| 17 | +<pre><code>[AMXX] Module has a different interface version (file "cstrike/addons/amxmodx/modules/foo_amxx_i386.so")</code></pre> | |
| 18 | +<p>The reverse: a module from a much older AMX Mod X than your core understands. Status <code>old</code>.</p> | |
| 19 | +<p>Each plugin that needs the failed module then fails with <code>Module/Library "cstrike" required for plugin</code>. That is the consequence, not the cause.</p> | |
| 20 | + | |
| 21 | +<h2>2. Check which versions you actually have</h2> | |
| 22 | +<p>The core:</p> | |
| 23 | +<pre><code>amxx version</code></pre> | |
| 24 | +<p>The first line names the build, for example <code>AMX Mod X 1.10.0.5487</code>. The modules:</p> | |
| 25 | +<pre><code>amxx modules</code></pre> | |
| 26 | +<pre><code>Currently loaded modules: | |
| 27 | + name version author status | |
| 28 | + [ 1] FakeMeta 1.8.2 AMX Mod X Dev Team running | |
| 29 | + [ 2] CStrike 1.10.0.548 AMX Mod X Dev Team newer | |
| 30 | + [ 3] Ham Sandwich 1.8.2 AMX Mod X Dev Team running | |
| 31 | +3 modules, 2 correct</code></pre> | |
| 32 | +<p>Every stock module should carry the same version as the core; here a 1.10 CStrike was dropped into a 1.8.2 install. The column is cut at 10 characters, so 1.10.0.5487 shows as <code>1.10.0.548</code>.</p> | |
| 33 | +<p>To check files without loading them, read the version string out of each binary:</p> | |
| 34 | +<pre><code>cd /home/steam/hlds/cstrike/addons/amxmodx | |
| 35 | +for f in dlls/*.so modules/*.so; do echo "$f: $(strings "$f" | grep -m1 -E '^1\.(8|9|10)\.')"; done</code></pre> | |
| 36 | +<p>Third-party modules use their own numbering, so an empty result for them is normal. File dates (<code>ls -l --time-style=long-iso dlls/ modules/</code>) can hint at a stray file, but they change whenever files are copied or unpacked, so trust the version string. For the compiler, run <code>./amxxpc</code> in <code>scripting/</code>; its first line is <code>AMX Mod X Compiler</code> followed by its version.</p> | |
| 37 | + | |
| 38 | +<h2>3. Fix: one release for core, modules and data</h2> | |
| 39 | +<p>Download the <strong>Base</strong> and <strong>Counter-Strike</strong> packages of one version for your platform, unpack them outside the server, and copy over only the parts that are tied to the version. Copying the whole tree on top of your install would also overwrite <code>configs/</code>, including <code>users.ini</code> and <code>plugins.ini</code>.</p> | |
| 40 | +<pre><code># back up first | |
| 41 | +cp -a /home/steam/hlds/cstrike/addons/amxmodx /home/steam/amxmodx-backup | |
| 42 | + | |
| 43 | +# unpack both packages of ONE release outside the server | |
| 44 | +mkdir -p /tmp/amxx-new && cd /tmp/amxx-new | |
| 45 | +tar -xzf /home/steam/amxmodx-VERSION-base-linux.tar.gz | |
| 46 | +tar -xzf /home/steam/amxmodx-VERSION-cstrike-linux.tar.gz | |
| 47 | + | |
| 48 | +# copy the version-bound parts, leave configs/ alone | |
| 49 | +NEW=/tmp/amxx-new/addons/amxmodx | |
| 50 | +OLD=/home/steam/hlds/cstrike/addons/amxmodx | |
| 51 | +cp -a $NEW/dlls/. $OLD/dlls/ | |
| 52 | +cp -a $NEW/modules/. $OLD/modules/ | |
| 53 | +cp -a $NEW/plugins/. $OLD/plugins/ | |
| 54 | +cp -a $NEW/scripting/. $OLD/scripting/ | |
| 55 | +cp -a $NEW/data/gamedata $OLD/data/ # 1.9 and 1.10 only</code></pre> | |
| 56 | +<p>On Windows it is the same folders from the Windows packages, with <code>.dll</code> files. Then look at whatever is left in <code>modules/</code> that did not come from the packages: each file is either a third-party module (step 4) or a leftover from an old release that should go. Finally, restart the server process. A changelevel is not enough, because a module that already failed stays failed until the process exits.</p> | |
| 57 | +<p>This works because a module is built against the core and data files of its own release, so with one release nothing it asks for is missing. Moving from 1.8.2? Follow <a href="/tutorials/upgrade-amxmodx-1-8-2-to-1-10">the 1.8.2 to 1.10 upgrade guide</a>; for a fresh install see <a href="/tutorials/install-amx-mod-x-1-10">installing AMX Mod X 1.10</a>.</p> | |
| 58 | + | |
| 59 | +<h2>4. Third-party modules</h2> | |
| 60 | +<p>ReAPI, Orpheu, cURL and the rest are built against an AMXX SDK too. Get the build its author lists for your AMXX line. If a third-party module shows <code>newer</code> on 1.8.2 and the log names one of the six functions above, it needs 1.9 or later: upgrade the core or find an older build of the module. When you change a module's version, recompile the plugins that use it against that version's <code>.inc</code>.</p> | |
| 61 | + | |
| 62 | +<h2>5. Plugins: same family, different messages</h2> | |
| 63 | +<p>The <code>.amxx</code> file format did not change between 1.8.2 and 1.10: all three compilers write the same file version. A plugin from a newer compiler is not rejected for being newer. It fails when it calls something your server does not have:</p> | |
| 64 | +<pre><code>[AMXX] Plugin "x.amxx" failed to load: Plugin uses an unknown function (name "client_print_color") - check your modules.ini.</code></pre> | |
| 65 | +<p>Natives added in 1.9 include <code>client_print_color</code>, <code>create_cvar</code>, <code>bind_pcvar_num</code> and <code>register_event_ex</code>, plus cstrike natives such as <code>cs_get_user_weapon_entity</code> and <code>cs_get_weapon_info</code>. A plugin that uses any of them, compiled with 1.9 or 1.10 and loaded on 1.8.2, gives this line. Upgrade the core, or use a 1.8.2-compatible version of the plugin.</p> | |
| 66 | +<p>Two other plugin errors get blamed on versions but are not caused by mixing 1.8.2, 1.9 and 1.10. <code>Plugin uses deprecated format. Update compiler</code> means a file header the loader does not accept, usually from a very old or non-standard compiler: recompile. <code>Invalid Plugin</code> means the file is not a valid <code>.amxx</code> at all, such as a damaged upload or a renamed <code>.sma</code>. These two are written to <code>error_YYYYMMDD.log</code> with the plugin name appended; the unknown-function and module lines go to the <code>L</code> log.</p> | |
| 67 | +<p>The rule that prevents all of it: compile with the <code>amxxpc</code> and <code>include/</code> files from the same release as the server. See <a href="/tutorials/compile-sma-to-amxx">compiling .sma to .amxx</a>.</p> | |
| 68 | + | |
| 69 | +<h2>6. How 1.8.2, 1.9 and 1.10 differ here</h2> | |
| 70 | +<ul> | |
| 71 | +<li><strong>1.8.2</strong> is the real boundary. It has no game data files and lacks the six helper functions, so every official 1.9 or 1.10 module shows <code>newer</code> on it. In the other direction, 1.8.2 modules attach to a 1.9 or 1.10 core and show <code>running</code>, but they lack the newer natives (plugins then fail with the unknown-function line) and run older code. Replace them anyway.</li> | |
| 72 | +<li><strong>1.9</strong> added <code>data/gamedata/</code> and the six functions, with the same interface number as 1.8.2.</li> | |
| 73 | +<li><strong>1.10</strong> has the same interface and the same core function table as 1.9, so a 1.9 module in a 1.10 install (or the reverse) attaches and shows <code>running</code>; official modules never get <code>newer</code> here. The mismatch shows up in the data files instead. Ham Sandwich is the clearest case: the 1.9 module reads its offsets from <code>configs/hamdata.ini</code>, the 1.10 module reads them from <code>data/gamedata/</code>, and each package ships only its own. Mix them without the matching file and hooks fail when plugins register them, with lines like <code>Function ... is not configured in gamedata</code> (1.10 module) or <code>... is not configured in hamdata.ini</code> (1.9 module). The fix is still one release.</li> | |
| 74 | +</ul> | |
| 75 | + | |
| 76 | +<h2>Common errors</h2> | |
| 77 | +<ul> | |
| 78 | +<li><strong><code>newer</code> plus <code>func "GetConfigManager"</code></strong> - a 1.9 or 1.10 module on a 1.8.2 core. Upgrade the core or use the 1.8.2 module.</li> | |
| 79 | +<li><strong>All modules <code>running</code>, plugins fail with an unknown function</strong> - the plugin uses natives your core or an old module lacks. Compare versions in <code>amxx modules</code>.</li> | |
| 80 | +<li><strong>Ham hooks or <code>cs_</code> natives fail after a partial upgrade</strong> - game data from a different release. Copy <code>data/gamedata/</code> from the same package as the modules.</li> | |
| 81 | +<li><strong>Files replaced, nothing changed</strong> - you changed map instead of restarting the process.</li> | |
| 82 | +</ul> | |
| 83 | +<p>For module failures that are not about versions, see <a href="/tutorials/fix-amxx-module-failed-to-load">Module failed to load</a>.</p> | |
| 84 | + | |
| 85 | +<h2>Verification checklist</h2> | |
| 86 | +<ol> | |
| 87 | +<li><code>amxx version</code> and every stock module in <code>amxx modules</code> show the same version.</li> | |
| 88 | +<li>The last line of <code>amxx modules</code> reads <em>N modules, N correct</em>.</li> | |
| 89 | +<li><code>amxx plugins</code> prints no <code>Load fails</code> lines.</li> | |
| 90 | +<li><code>grep -E "requested a not|interface version|gamedata|hamdata" L*.log</code> finds nothing dated after the restart.</li> | |
| 91 | +<li><code>./amxxpc</code> reports the same version as <code>amxx version</code>.</li> | |
| 92 | +</ol> | |
| 0 | 93 |
