It seems that mp_timelimit is virtually useless on most maps. Although I haven't scrutinized every single permutation of map type and round/timelimit combinations, in every case I've observed, mp_timelimit is overridden by mp_maxrounds.
Now, I run a lot of customs on my server (http://www.2fort2furious.com/images/2f2f_status.png), so perhaps this behavior is due to maps not being properly built to respect the mp_timelimit setting. But in the current state of things, I see many maps go on for hours despite mp_timelimit being 20 minutes long. This naturally frustrates my players and myself. My question is: why doesn't mp_timelimit override mp_maxrounds? I'd expect a response to say, "so the round doesn't end/go into sudden death abruptly," but mp_timelimit's purpose, I'd argue, is to prevent rounds from going on into eternity. Why not make it configurable, so that one can preserve the current behavior or force mp_timelimit to always take precedence over mp_maxrounds? Ideally, if mp_timelimit is 0, mp_maxrounds will be the only criteria by which nextmap progression is based on. If mp_timelimit is nonzero, it takes precedence over mp_maxrounds, unless mp_maxrounds is met first. This issue is very important to me. I try to support high-quality and unique custom maps and have been visited by several mapmakers testing out their work, including Furyo and Vilepickle. I find that there are many maps I have to remove from my rotation due to excessively long round times, a problem which could very easily be solved if mp_timelimit behaved intuitively - by ending the round or going into sudden death upon expiring. --- Two other minor issues: there was once a test cvar that would allow one to force sudden death. At some point, it was removed. I wanted to point out that this functionality was extremely useful and I'd request that it be re-added. Secondly, I sent an email to this list earlier about the possibility of being able to turn off the voice command spam protection. Although the message was a bit tongue-in-cheek, my request was sincere and I'm still hoping this can be controlled by the addition of a cvar. Thank you, Ryan _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
