Per-Map Configs (maps/mapname.cfg)

It is a widespread belief that CS 1.6 automatically runs maps/de_dust2.cfg when it loads de_dust2. It does not. Stock HLDS has no built-in per-map config auto-exec, which is why so many admins swear their maps/*.cfg files are being ignored — they are. This explains what the engine really does, the one stock hook that comes close, and a tiny plugin that gives you true per-map configs.

1. What the engine actually executes on a map change

At the start of every map the engine runs server.cfg, and if you have set it, the file named by mapchangecfgfile. That is the whole list. There is no name-based lookup for maps/<currentmap>.cfg anywhere in stock HLDS. Any tutorial that tells you to just drop maps/de_dust2.cfg and expect it to run is repeating a myth.

2. The stock hook: mapchangecfgfile

The engine does expose one config that runs on every map change:

// server.cfg
mapchangecfgfile "onchange.cfg"

This is useful for settings that must re-apply after each load, but it is the same file for every map — it is not per-map. You can bootstrap per-map behavior from it (read the current map and exec a matching file), but doing that in a config is clumsy. A plugin is cleaner.

3. The reliable way: a small AMXX plugin

The classic solution is a few lines of Pawn that read the current map name and exec a file named after it. This runs once, early, on every map:

#include <amxmodx>

public plugin_init()
{
    register_plugin("Per-Map Config", "1.0", "CSB")

    new mapname[32]
    get_mapname(mapname, charsmax(mapname))

    new path[64]
    formatex(path, charsmax(path), "maps/%s.cfg", mapname)

    // only exec if the file exists, to avoid a console error
    new full[96]
    formatex(full, charsmax(full), "%s", path)
    if (file_exists(full))
        server_cmd("exec %s", path)
}

Compile it, drop the .amxx in addons/amxmodx/plugins/, and add it to plugins.ini. The exec path is relative to the cstrike/ game directory, so the files live in cstrike/maps/de_dust2.cfg and so on. If you would rather not compile your own, a maintained equivalent ships as a CSB Map Config plugin.

4. What belongs in a per-map config

Keep these files small and specific — only the things that genuinely differ per map:

// cstrike/maps/awp_map.cfg
mp_startmoney 16000
mp_buytime 0.1
mp_roundtime 3

// cstrike/maps/cs_assault.cfg
mp_startmoney 800
mp_freezetime 4

Because the engine does not reset cvars between maps, anything you change in one map's cfg persists into the next unless the next map's cfg (or server.cfg) sets it back. That is the number-one per-map gotcha — see the errors below. The cvars themselves are documented in the mp_ cvars reference.

5. Reset what you change

Because settings leak forward, treat per-map configs as overrides that every map must fully declare, or set your baseline in server.cfg and only override the deltas per map. The cleanest pattern: put normal values in server.cfg, and in each map cfg change only what that map needs — then add the reset to any map that would otherwise inherit an unwanted value. A map that bumps mp_startmoney to 16000 must be followed by maps that set it back to 800, or every map after the money map is rich.

Troubleshooting

• maps/mapname.cfg is ignored — you expected stock auto-exec, which does not exist. Install the plugin above or use mapchangecfgfile.
• Settings bleed into the next map — cvars are not reset between maps. Each map cfg must declare, or your baseline in server.cfg must reassert, the values.
• exec prints "couldn't exec" — the file name does not match the map exactly (case, or a stray .cfg.cfg from a Windows editor), or it is not under cstrike/maps/. The plugin's file_exists guard avoids the error for maps with no config.
• Config runs but values do not stick — a later config (amxx.cfg, a plugin) re-sets them. Trace the execution order.
• Plugin does nothing — not listed in plugins.ini, or amxx plugins shows it as bad load. Fix the load first.

Verification

Create cstrike/maps/de_dust2.cfg with an obvious value like mp_startmoney 16000, change to that map, and read it back in the console:

changelevel de_dust2
mp_startmoney   // should echo 16000

Then change to a different map that does not set it and confirm your baseline reasserts — if it stays at 16000, you have found the leak and need a reset line. Once the pattern holds, keep the per-map files short and version them alongside server.cfg.