mp_timelimit, mp_maxrounds and Map Flow Tuning

What ends a map on CS 1.6 is not mapcycle.txt — the rotation only advances once a map ends, and ending is decided by four cvars that race each other. Set them carelessly and the map either never ends or ends in a way that surprises players mid-round. This explains the four limits, which ones require ReGameDLL, and how to pick a flow that feels intentional.

1. The four ways a map ends

Only mp_timelimit and mp_fraglimit exist on stock Valve CS. mp_maxrounds and mp_winlimit are added by ReGameDLL_CS; on stock CS, setting them is a silent no-op — the value goes nowhere and the map never ends by round count.

2. Whichever fires first wins

These limits are not prioritized; they run in parallel and the first one satisfied ends the map. If you set mp_timelimit 30 and mp_maxrounds 30, a fast-paced map may hit 30 rounds in 22 minutes and end early, while a slow one hits 30 minutes first. That is not a bug — it is the design. The mistake is setting several limits without deciding which you actually want to govern the map, then being confused when the map ends at an unpredictable moment.

3. Pick one primary limit

Decide what your server is for and let one cvar lead:

• Casual public — time-based. Set mp_timelimit (20–30 is common) and leave the others at 0. Everyone knows roughly how long a map lasts.
• Competitive / MR-style — round-based. Set mp_maxrounds (e.g. 30 for an MR15) and set mp_timelimit 0 so the map ends on rounds, not the clock.
• Race to a score — mp_winlimit. The map ends the instant a team clinches, good for short rotations.
• Deathmatch-style — mp_fraglimit, ending on individual kills.

// casual public example
mp_timelimit 25
mp_maxrounds 0
mp_winlimit 0
mp_fraglimit 0

4. Set the limit to 0 to disable it

Every one of these is disabled by 0. The dangerous combination is all four at 0: nothing ends the map, the rotation freezes, and it looks like your mapcycle is broken when in fact nothing is telling the map to end. If a server loops one map forever, check these four cvars before touching the cycle file.

5. Leave room for the end-of-map vote

If you run an end-of-map vote or Rock The Vote, it is scheduled off mp_timelimit — the vote pops in the closing minutes of the time limit. A purely round-based flow (mp_timelimit 0, mp_maxrounds 30) gives the vote nothing to hook onto, so the vote never appears. If you want both a round limit and a vote, keep a generous mp_timelimit as a backstop so the vote still fires. See the RTV and nextmap guide for how the vote timing works, and the full mp_ cvars reference for the round-timing cvars that shape play between these limits.

6. A worked example

Say you run a competitive 5v5 and want a clean MR15 — first team to 16 wins, or 30 rounds played, whichever settles it — with a two-minute buffer at the end for the scoreboard. The flow is round-governed, so the round cvars lead and time is only a safety net:

mp_maxrounds 30       // 30 rounds = MR15
mp_winlimit 16        // a team clinching 16 ends it immediately
mp_timelimit 0        // no clock; rounds decide the map
mp_fraglimit 0        // not a deathmatch
mp_chattime 10        // end-of-map scoreboard window

Here mp_winlimit 16 and mp_maxrounds 30 describe the same ending from two angles — a 16–14 result trips the win limit at round 30, a 16–6 result trips it early at round 22 — and either way the map ends and the cycle advances. Now contrast a casual public box: there you want mp_timelimit 25 leading with every round cvar at 0, so maps last a predictable wall-clock length regardless of score. The two configurations are opposites, and the point is to choose one philosophy — clock or rounds — rather than half-setting both and getting a map that ends at a moment nobody predicted.

Common errors

• Map never changes — all four limits are 0. Set at least one.
• mp_maxrounds does nothing — you are on stock CS. It needs ReGameDLL_CS.
• Map ends earlier than expected — a second limit fired first. Set the ones you do not want to 0.
• End-of-map vote never shows — mp_timelimit 0. The vote is scheduled off the time limit; keep a non-zero backstop.
• Limits keep reverting — ReGameDLL's game.cfg or an AMXX config re-sets them after server.cfg. Trace the execution order.

Verification

Read the four cvars back in the console:

mp_timelimit
mp_maxrounds
mp_winlimit
mp_fraglimit

Confirm only the one you want to govern the map is non-zero. Then lower your primary limit to something small — mp_timelimit 2 or mp_maxrounds 2 — on a test server and confirm the map ends and advances to the next cycle entry exactly when that limit is hit. Restore your real values once the flow behaves.