---
title: "plugins.ini: Load Order, the debug Flag and Disabling Plugins"
excerpt: "How AMX Mod X reads plugins.ini top to bottom, why order changes behavior, how to run a plugin in debug mode, and how to disable one cleanly."
category: "administration"
tags: "plugins.ini, amxmodx"
image: ""
read_time: "8 min read"
---
<p><code>addons/amxmodx/configs/plugins.ini</code> is the list of AMX Mod X plugins the server loads and the order it loads them in. It looks trivial — one filename per line — but the order is not cosmetic: it decides which plugin gets first crack at menus, chat and events, and getting it wrong produces conflicts that are maddening to debug because nothing errors, the behavior is just subtly off.</p>

<h2>1. The format</h2>
<p>Each line names a compiled plugin in <code>addons/amxmodx/plugins/</code>. No path, just the <code>.amxx</code> filename. Comments start with <code>;</code>:</p>
<pre>; AMX Mod X plugins
admin.amxx          ; admin base — must load early
adminhelp.amxx
adminslots.amxx     ; reserved slots
mapchooser.amxx
nextmap.amxx
timeleft.amxx
; antiflood.amxx    ; disabled
csb_adverts.amxx</pre>
<p>Plugins load strictly top to bottom. That order is also the order in which they register forwards, menus and event hooks.</p>

<h2>2. Why order matters</h2>
<p>Several AMXX subsystems hand an event to plugins in load order and let the first one "claim" it:</p>
<ul>
<li><strong>Menus</strong> — two plugins that bind the same menu key fight; the one loaded first usually wins the keypress.</li>
<li><strong>say / chat handlers</strong> — a plugin that intercepts a chat command can stop later plugins from ever seeing it.</li>
<li><strong>Map / vote control</strong> — <code>nextmap</code>, <code>mapchooser</code> and any RTV plugin all want to set the next map; load order decides the winner. See <a href="/tutorials/rtv-nextmap-setup">the RTV guide</a>.</li>
<li><strong>admin.amxx first</strong> — the admin base that reads <code>users.ini</code> and establishes access should load before plugins that check <code>ADMIN_</code> flags, or early access checks can miss.</li>
</ul>
<p>Rule of thumb: core/admin plugins at the top, gameplay and cosmetic plugins below.</p>

<h2>3. Disabling a plugin</h2>
<p>Three ways, in order of preference:</p>
<ol>
<li><strong>Comment it out</strong> — prefix the line with <code>;</code>. The file stays self-documenting and you can re-enable it later.</li>
<li><strong>Delete the line</strong> — cleaner but you lose the record of what was there.</li>
<li><strong>Runtime pause</strong> — from the server console, <code>amxx pause &lt;plugin&gt;</code> stops it until the next map without editing the file.</li>
</ol>
<p>Do not just remove the <code>.amxx</code> from the plugins folder while leaving the line — you will get a <code>plugin failed to load</code> style error on every map load. Comment the line instead.</p>

<h2>4. The debug flag</h2>
<p>Append <code>debug</code> after a plugin name to load it in debug mode:</p>
<pre>myplugin.amxx debug</pre>
<p>Debug mode makes run-time errors report the exact line and a proper call trace instead of a bare address, at a small performance cost. When a plugin throws <code>Run time error</code> in the logs and you cannot tell where, add <code>debug</code>, reproduce, and read the trace — then remove it once fixed. This is the fastest way to <a href="/tutorials/find-crashing-plugin">find a crashing plugin</a>.</p>

<h2>5. Inspecting what actually loaded</h2>
<p>From the server console (not in-game chat):</p>
<pre>amxx plugins</pre>
<p>This lists every plugin with a status: <code>running</code>, <code>paused</code>, <code>bad load</code>, or <code>error</code>. <code>amxx modules</code> does the same for modules. Trust this over the file — if a line says <code>bad load</code>, the plugin is listed but the engine could not initialise it, which is a different problem from a plugin that simply is not in the file.</p>

<h2>Common errors</h2>
<ul>
<li><strong><code>bad load</code> on a plugin</strong> — usually a missing module the plugin needs (see <a href="/tutorials/fix-amxx-module-failed-to-load">module failed to load</a>) or a version mismatch, e.g. a 1.10-compiled plugin on a 1.8.2 core. Check <a href="/tutorials/fix-plugins-bad-load-after-19">bad load after upgrading</a>.</li>
<li><strong>Two plugins conflict, no error</strong> — same menu key or chat command claimed by both. Reorder so the intended one loads first, or disable the other.</li>
<li><strong>Admin commands ignored</strong> — a gameplay plugin loaded before <code>admin.amxx</code> and checked access before it was set up. Move admin plugins to the top.</li>
<li><strong>Plugin not running but no error</strong> — the line is commented, misspelled, or the <code>.amxx</code> is absent. <code>amxx plugins</code> tells you which.</li>
<li><strong>Edits ignored</strong> — <code>plugins.ini</code> is only re-read on map change or restart; changing it mid-map does nothing until then.</li>
</ul>

<h2>Verification</h2>
<p>After editing, change the map and run <code>amxx plugins</code> in the console. Every plugin you expect should read <code>running</code>; anything <code>bad load</code> or <code>error</code> needs attention before you move on. For a specific plugin you are debugging, add <code>debug</code>, reproduce the fault, and confirm the log now shows a file and line number. Once the list is clean, revisit <a href="/tutorials/amxx-cfg-explained">amxx.cfg</a> to tune how those plugins behave.</p>