Add fix-amxx-cfg-overrides-server-cfg/en.md
Browse Source
Daemon666 committed
parent 3d4535eaeb
commit 2983c4fcd468f49568129c22046043f4bb543919
1 changed file
with 14 additions and 0 deletions
fix-amxx-cfg-overrides-server-cfg/en.md
A
| @@ -0,0 +1,14 @@ | ||
| 1 | +--- | |
| 2 | +title: "Fix: amxx.cfg Overwrites My server.cfg Values" | |
| 3 | +excerpt: "The execution timeline that makes amxx.cfg win over server.cfg, why your carefully set cvars keep reverting, and where to put a value so it is the last word." | |
| 4 | +category: "errors" | |
| 5 | +tags: "amxx.cfg, config" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>You set <code>mp_freezetime</code> or <code>sv_restart</code> in <a href="/tutorials/setup-server-cfg-cs16">server.cfg</a>, restart, and the value is something else entirely. The culprit is execution order: AMX Mod X runs <code>amxx.cfg</code> <em>after</em> the engine has run <code>server.cfg</code>, so whatever <code>amxx.cfg</code> (or a plugin) sets is the last write and it wins. This is not a bug; once you understand the timeline the fix is obvious — put the value where it executes last.</p><h2>1. Understand the execution timeline</h2><p>On a fresh map the configs run in this order:</p><ol><li>The engine executes <code>server.cfg</code> as the server comes up.</li><li>Metamod and AMX Mod X finish loading with the game library.</li><li>AMX Mod X reaches its <code>plugin_cfg</code> stage and executes <code>addons/amxmodx/configs/amxx.cfg</code>.</li><li>AMX Mod X then executes the per-map config, if one exists for this map.</li></ol><p>Because steps 3 and 4 happen after step 1, any cvar set in both files takes the AMXX value. The details of stage 3 are in <a href="/tutorials/amxx-cfg-explained">amxx.cfg explained</a>.</p><h2>2. Find where the value is really being set</h2><p>The conflicting line is in one of three places: <code>amxx.cfg</code> itself, a per-map config, or a plugin that sets the cvar in its own code. Grep the config tree first:</p><pre>grep -rn "mp_freezetime" addons/amxmodx/configs/</pre><p>If nothing turns up there, a plugin is setting it programmatically — and no amount of editing <code>server.cfg</code> will hold, because the plugin runs after every config.</p><h2>3. Fix it by moving the value later, not earlier</h2><p>Do not fight the order; join it. Delete the line from <code>server.cfg</code> and set the value in <code>amxx.cfg</code> instead, where it now executes last and wins:</p><pre>// addons/amxmodx/configs/amxx.cfg | |
| 10 | +mp_freezetime 3 | |
| 11 | +mp_friendlyfire 0</pre><p>For values you want to differ per map, use a <a href="/tutorials/per-map-config-files">per-map config</a> — that runs even later than <code>amxx.cfg</code> and is the true last word for that map.</p><h2>4. When a plugin is the one overwriting</h2><p>If a plugin resets the cvar in <code>plugin_init</code> or on round start, config files cannot beat it — the plugin runs after them and re-sets the value continuously. You have two honest options: configure the plugin through <em>its own</em> cvar (most well-written plugins expose one instead of hard-coding the value), or, if it truly hard-codes it, remove or replace the plugin. Setting the underlying cvar downstream will not stick against a plugin that writes it every round.</p><h2>5. Keep one file authoritative</h2><p>The maintainable pattern is to decide which file owns which cvars. Engine and network cvars — <code>sv_maxrate</code>, <code>sys_ticrate</code>, rcon — stay in <code>server.cfg</code>. Gameplay cvars that plugins also touch live in <code>amxx.cfg</code>. Do not set the same cvar in both; that is what creates the "my value reverts" confusion in the first place.</p><h2>6. Prove the order with a marker</h2><p>When you are not sure which config actually runs last, stop guessing and make each announce itself. Add an <code>echo</code> to the end of each file:</p><pre>// end of server.cfg | |
| 12 | +echo "=== server.cfg finished ===" | |
| 13 | +// end of amxx.cfg | |
| 14 | +echo "=== amxx.cfg finished ==="</pre><p>Restart and read the console top to bottom. The order the markers print is the exact execution order on your build, and whichever file's marker appears <em>last</em> is the one whose cvar values survive. This turns an invisible timing question into something you can see in three lines, and it settles the common argument about whether a per-map config or <code>amxx.cfg</code> wins — the marker that prints later is the winner. Once you have confirmed the order, delete the echoes and place your authoritative value in the file that prints last.</p><h2>Common errors</h2><ul><li><strong>Value reverts after every map</strong> — it is set in <code>amxx.cfg</code> or a per-map config that runs after <code>server.cfg</code>. Move your intended value there.</li><li><strong>Value reverts every round</strong> — a plugin is re-setting it in code. Configure the plugin's own cvar or remove the plugin.</li><li><strong>server.cfg seems ignored entirely</strong> — that is a different fault; the file may not be executing at all, see <a href="/tutorials/fix-server-cfg-not-executing">server.cfg not executing</a>.</li><li><strong>Editing amxx.cfg changes nothing</strong> — you edited a copy in the wrong path; the real one is <code>addons/amxmodx/configs/amxx.cfg</code>.</li><li><strong>Only one map is wrong</strong> — a per-map config for that map overrides the rest. Check <code>configs/maps/</code>.</li></ul><h2>Verification</h2><p>Set the cvar only in <code>amxx.cfg</code>, remove it from <code>server.cfg</code>, restart, and read it back once the map is live:</p><pre>mp_freezetime</pre><p>It should report your intended value. Change the map and read it again — if it holds across a map change, the AMXX-stage config is authoritative and the conflict is resolved. If it still drifts, a plugin owns the cvar and you configure it there instead.</p> | |
| 0 | 15 |
