---
title: "amxx.cfg: Every Setting Explained"
excerpt: "A practical walkthrough of addons/amxmodx/configs/amxx.cfg: access control, admin activity visibility, flood control, intro messages and the cvars worth changing."
category: "administration"
tags: "amxx.cfg, config"
image: ""
read_time: "8 min read"
---
<p><code>addons/amxmodx/configs/amxx.cfg</code> is the core config AMX Mod X executes as it loads, before your plugins settle in. It controls who has access, how much of admin activity players see, flood protection, and the built-in message plugins. Most admins skim it once and never touch it again — but a handful of these cvars decide whether your server feels tight or chaotic, so they are worth understanding line by line.</p>

<h2>1. When and where it runs</h2>
<p>The file lives at <code>cstrike/addons/amxmodx/configs/amxx.cfg</code> and is executed by the AMXX core at startup, after <code>server.cfg</code> in practice. Because it runs late, a cvar set here overrides the same cvar set in <code>server.cfg</code>. Keep AMXX-specific settings here and engine/gameplay settings in <a href="/tutorials/setup-server-cfg-cs16">server.cfg</a> so you always know which file owns which value.</p>

<h2>2. Access control cvars</h2>
<pre>amx_default_access ""        // flags given to EVERY player; keep empty
amx_mode 1                  // 1 = admins only load from users.ini
amx_password_field "_pw"    // setinfo field clients use for password auth
amx_vote_ratio 0.02
amx_vote_time 10</pre>
<p><strong>Leave <code>amx_default_access</code> empty.</strong> Putting a flag here grants it to everyone on the server, which is how people accidentally hand admin commands to the public. Admin identities and their flags live in <code>configs/users.ini</code>, not here; this file only sets the machinery. <code>amx_password_field</code> is the client <code>setinfo</code> key used when an admin entry authenticates by password rather than SteamID — if you change it, your password admins must change their <code>setinfo</code> to match.</p>

<h2>3. Admin activity visibility</h2>
<pre>amx_show_activity 2</pre>
<p>This governs what players see when an admin acts (ban, slap, kick). The values:</p>
<ul>
<li><code>0</code> — nobody is told.</li>
<li><code>1</code> — players see the action but not the admin's name.</li>
<li><code>2</code> — players see the action and the admin's name.</li>
<li><code>3</code>–<code>5</code> — variants that show admins more detail than regular players.</li>
</ul>
<p>On a public server <code>2</code> is the honest default; hiding admin actions entirely (<code>0</code>) breeds accusations you cannot answer. If you run a menu-driven admin workflow, pair this with the <a href="/plugins/csb-admin-menu">CSB Admin Menu</a>.</p>

<h2>4. Flood control</h2>
<pre>amx_flood_time 0.75</pre>
<p>The minimum seconds between chat messages from one client before the anti-flood plugin throttles them. Lower it and chat spam gets through; raise it too far and normal fast chat gets blocked. <code>0.75</code> is a reasonable balance. For heavier spam and bind abuse, a dedicated <a href="/plugins/csb-anti-flood">anti-flood plugin</a> gives you more control.</p>

<h2>5. Intro and scrolling messages</h2>
<p>AMXX ships small presentation plugins configured here:</p>
<pre>amx_scrollmsg "Welcome to %hostname% -- have fun" 600
amx_imessage "Welcome to %hostname%" "0 255 0"
amx_imessage "Powered by AMX Mod X" "0 100 200"
amx_freq_imessage 180</pre>
<p><code>amx_scrollmsg</code> is the scrolling HUD banner and its refresh interval. <code>amx_imessage</code> lines are the center-screen intro messages that rotate, with an RGB color per line, and <code>amx_freq_imessage</code> is how often they cycle. Keep these short and few — a busy HUD is noise. Many admins disable these in favor of a chat-based <a href="/plugins/csb-adverts">adverts plugin</a>.</p>

<h2>6. Logging and language</h2>
<pre>amx_logging 1        // 1 = per-map AMXX log files under addons/amxmodx/logs
amx_language "en"    // default language for multilingual plugins
amx_mldebug ""       // list plugins to debug for missing translations</pre>
<p>Leave <code>amx_logging</code> on — the AMXX logs are where plugin run-time errors surface, and you will want them when something misbehaves. <code>amx_language</code> only affects plugins that use the multilingual system; it does not translate everything.</p>

<h2>Common errors</h2>
<ul>
<li><strong>Everyone suddenly has admin</strong> — a flag was left in <code>amx_default_access</code>. Set it back to <code>""</code>.</li>
<li><strong>Password admins can no longer authenticate</strong> — <code>amx_password_field</code> was changed but the admins' <code>setinfo</code> was not, or vice-versa. The two must match.</li>
<li><strong>Admin actions are invisible and players complain</strong> — <code>amx_show_activity 0</code>. Raise it to <code>1</code> or <code>2</code>.</li>
<li><strong>Settings here get overridden</strong> — you also set the same cvar in a plugin config or <code>mapchangecfgfile</code> that runs later. Trace the execution order.</li>
<li><strong>Edits do nothing</strong> — you edited a different <code>amxx.cfg</code> (there is only one that matters, under <code>addons/amxmodx/configs/</code>), or the change needs a map change / restart to re-execute.</li>
</ul>

<h2>Verification</h2>
<p>Change one value, restart or change the map, and read it back from the console:</p>
<pre>amx_show_activity</pre>
<p>The console should echo the new value. Then perform an admin action (a slap on yourself) and confirm the on-screen message matches the visibility level you set. If a cvar refuses to stick, something is executing after <code>amxx.cfg</code> and re-setting it — the load order of <a href="/tutorials/plugins-ini-load-order">plugins.ini</a> and any per-map configs is where to look.</p>