Fix: amxx.cfg Overwrites My server.cfg Values

You set mp_freezetime or sv_restart in server.cfg, restart, and the value is something else entirely. The culprit is execution order: AMX Mod X runs amxx.cfg after the engine has run server.cfg, so whatever amxx.cfg (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.

1. Understand the execution timeline

On a fresh map the configs run in this order:

1. The engine executes server.cfg as the server comes up.
2. Metamod and AMX Mod X finish loading with the game library.
3. AMX Mod X reaches its plugin_cfg stage and executes addons/amxmodx/configs/amxx.cfg.
4. AMX Mod X then executes the per-map config, if one exists for this map.

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 amxx.cfg explained.

2. Find where the value is really being set

The conflicting line is in one of three places: amxx.cfg itself, a per-map config, or a plugin that sets the cvar in its own code. Grep the config tree first:

grep -rn "mp_freezetime" addons/amxmodx/configs/

If nothing turns up there, a plugin is setting it programmatically — and no amount of editing server.cfg will hold, because the plugin runs after every config.

3. Fix it by moving the value later, not earlier

Do not fight the order; join it. Delete the line from server.cfg and set the value in amxx.cfg instead, where it now executes last and wins:

// addons/amxmodx/configs/amxx.cfg
mp_freezetime 3
mp_friendlyfire 0

For values you want to differ per map, use a per-map config — that runs even later than amxx.cfg and is the true last word for that map.

4. When a plugin is the one overwriting

If a plugin resets the cvar in plugin_init 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 its own 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.

5. Keep one file authoritative

The maintainable pattern is to decide which file owns which cvars. Engine and network cvars — sv_maxrate, sys_ticrate, rcon — stay in server.cfg. Gameplay cvars that plugins also touch live in amxx.cfg. Do not set the same cvar in both; that is what creates the "my value reverts" confusion in the first place.

6. Prove the order with a marker

When you are not sure which config actually runs last, stop guessing and make each announce itself. Add an echo to the end of each file:

// end of server.cfg
echo "=== server.cfg finished ==="
// end of amxx.cfg
echo "=== amxx.cfg finished ==="

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 last 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 amxx.cfg 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.

Common errors

• Value reverts after every map — it is set in amxx.cfg or a per-map config that runs after server.cfg. Move your intended value there.
• Value reverts every round — a plugin is re-setting it in code. Configure the plugin's own cvar or remove the plugin.
• server.cfg seems ignored entirely — that is a different fault; the file may not be executing at all, see server.cfg not executing.
• Editing amxx.cfg changes nothing — you edited a copy in the wrong path; the real one is addons/amxmodx/configs/amxx.cfg.
• Only one map is wrong — a per-map config for that map overrides the rest. Check configs/maps/.

Verification

Set the cvar only in amxx.cfg, remove it from server.cfg, restart, and read it back once the map is live:

mp_freezetime

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.