---
title: "Fix: nextmap / mapcycle Not Advancing to the Next Map"
excerpt: "Why a server loops one map forever, the mp_timelimit-is-zero trap, how mapcycle.txt and the nextmap plugin decide what comes next, and pointing the engine at the right cycle file."
category: "errors"
tags: "nextmap, mapcycle"
image: ""
read_time: "8 min read"
---
<p>Your server plays the same map endlessly, or ignores the order in <code>mapcycle.txt</code> and jumps somewhere unexpected. Two separate things govern map flow and people conflate them: something has to <em>end</em> the current map, and then something has to <em>choose</em> the next one. If the map never ends, the cycle never advances no matter how perfect the file is; if the map ends but the next-map logic is wrong, it advances to the wrong place. Diagnose which half is broken before editing files.</p><h2>1. Confirm the map can even end</h2><p>A map that never ends can never advance. The clock is the usual culprit:</p><pre>mp_timelimit 30</pre><p>If <code>mp_timelimit</code> is <code>0</code> and you have no round or frag limit set, nothing tells the map to end and it loops forever &mdash; which looks exactly like a broken cycle but is not. Set a non-zero <code>mp_timelimit</code>, or a round/win limit on ReGameDLL, so there is an end event at all. The full interaction of the end-of-map limits is in <a href="/tutorials/timelimit-maxrounds-flow">the map-flow tuning guide</a>. Fix this first; the rest is moot until the map ends.</p><h2>2. Understand who picks the next map</h2><p>Once a map ends, the next one is chosen by one of two systems, and they can fight:</p><ul><li><strong>The engine's mapcycle</strong> &mdash; the engine reads <code>mapcycle.txt</code> and advances to the next entry.</li><li><strong>The AMXX nextmap plugin</strong> (<code>nextmap.amxx</code>) &mdash; it manages the next map itself, sets the <code>amx_nextmap</code> cvar, and announces "Next map:" in chat.</li></ul><p>When <code>nextmap.amxx</code> is loaded, it is the authority &mdash; it reads the mapcycle and drives the transition. If you also have a map-chooser or RTV plugin, that can override the plain cycle with a vote. Two plugins both trying to set the next map is a classic reason it jumps somewhere you did not expect.</p><h2>3. Check the mapcycle file the engine actually uses</h2><p>The engine reads the file named by the <code>mapcyclefile</code> cvar, which defaults to <code>mapcycle.txt</code> in the mod folder:</p><pre>mapcyclefile "mapcycle.txt"</pre><p>Two things break here: the cvar points at a file that does not exist (so the engine falls back and loops the current map), or the file exists but is malformed. A valid <code>mapcycle.txt</code> is one map name per line, no <code>.bsp</code> extension, and every map must exist in <code>maps/</code>:</p><pre>de_dust2
de_inferno
cs_office</pre><p>A single-entry file loops that one map by definition. A file full of maps you do not have makes the engine skip or stall. Confirm each listed map file is present.</p><h2>4. Watch for the config that resets the map</h2><p>If the map reloads itself rather than advancing, a config executed at map start may be forcing it. Check that no <code>server.cfg</code> line, ReGameDLL config, or plugin is calling <code>changelevel</code> back to the same map, and that <code>amx_nextmap</code> is not being pinned. Read the live next map with:</p><pre>amx_nextmap</pre><p>If it shows the current map, the nextmap plugin computed the wrong target &mdash; usually because the current map is not found in the mapcycle, so the plugin defaults to repeating it.</p><h2>5. Reconcile the vote with the plain cycle</h2><p>If you run an end-of-map vote or Rock The Vote, it deliberately overrides the sequential cycle &mdash; the winning map becomes the next map regardless of what comes next in <code>mapcycle.txt</code>. That is not a bug, it is the point of the vote, but it surprises admins who expect strict file order and instead see the map players voted for. Two consequences to hold in mind: the vote is scheduled off <code>mp_timelimit</code>, so a purely round-based flow with <code>mp_timelimit 0</code> gives it nothing to hook onto and it never appears; and if two plugins both try to set the next map, the last one to run wins and the result looks random. Decide which system owns the next-map decision &mdash; the plain engine cycle, the nextmap plugin, or a vote &mdash; and do not run two that fight. The timing details are in <a href="/tutorials/timelimit-maxrounds-flow">the map-flow guide</a>.</p><h2>Troubleshooting</h2><ul><li><strong>Same map forever, no end at all</strong> &mdash; <code>mp_timelimit 0</code> with no other limit. Set a limit so the map ends.</li><li><strong>Map ends but repeats itself</strong> &mdash; the current map is not listed in <code>mapcycle.txt</code>, so the nextmap logic falls back to it. Add it to the cycle.</li><li><strong>Advances but ignores your order</strong> &mdash; an RTV/map-chooser plugin is overriding the plain cycle with a vote. That is expected; configure the chooser, not the file.</li><li><strong>Cycle file edits do nothing</strong> &mdash; <code>mapcyclefile</code> points at a different file, or the file is read only at map end. Check the cvar and change the map.</li><li><strong>Skips maps</strong> &mdash; listed maps are missing from <code>maps/</code>; the engine passes over what it cannot load.</li></ul><h2>Verification</h2><p>Set a short limit on a test server &mdash; <code>mp_timelimit 2</code> &mdash; put three known-present maps in <code>mapcycle.txt</code>, and let it run. Confirm the map ends on time and advances to the second entry, then the third, then wraps. Read <code>amx_nextmap</code> mid-map and confirm it names the next entry, not the current one. If the ends and the order both behave, both halves &mdash; ending and choosing &mdash; are correct. Restore your real <code>mp_timelimit</code> once the flow is proven.</p>