Cc2iscooL wrote:
--
[ Picked text/plain from multipart/alternative ]
Do you have "mp_stalemate_enable" set to 1 in your startup?
Are you saying you can get sudden death to work for you on ctf_well?
I'd definitely be interested in seeing your config files if you can.
It's in my server.cfg, which gets executed at every map change, and also
in cfg/ctf_well.cfg. I do not have it in autoexec.cfg, but this is the
*ONLY* map we run that sudden death doesn't work for that doesn't have
its own round/mini-round timers. Since it's not the leadoff map and
since every other map we run that having a sudden death at timelimit
makes sense works, I don't believe that putting mp_stalemate_enable 1 in
autoexec.cfg would make any difference.
Furthermore, in all mapcycle files we run, every map that immediately
precedes ctf_well in each cycle also sets "mp_stalemate_enable 1", and
we are able to get sudden death to occur in those maps (if it's a map we
want a time limit on - basically any ctf map, tc_hydro, some cp maps).
snip from server.cfg:
---------------------
// USUAL SETTINGS
mp_maxrounds 1
mp_timelimit 20
mp_winlimit 0
mp_stalemate_enable 1
tf_flag_caps_per_round "3"
cfg/ctf_well.cfg:
-----------------
mp_maxrounds 1 <- note, when we set this to 3, we still only get 1
one round before the map changes
mp_timelimit 20 <- completely ignored by map/server - beetlemod starts
counting up negative time left after 20 minutes and
just keeps counting for foreverness...
mp_winlimit 0
mp_stalemate_enable 1 <- completely ignored - you can't even force a
sudden death with the beetlemod command to do
so
tf_flag_caps_per_round "3"
echo "Ran cfg/ctf_well.cfg!" <- This *DOES* print in the server console
when the map loads/inits, so I know it
is being run, it just isn't being OBEYED
The night the map was released, we did reconfigure the map cycles to
make it the leadoff map on all of our servers, and tried to set it for 3
rounds of 3 intel caps by setting mp_maxrounds 3, tf_flag_caps_per_round
3, and mp_timelimit 60. To get it a little extra airtime as a brand new
Valve map. This absolutely failed. The map still ended and changed
after the first round of 3 caps, no matter what I did to the server.cfg
and cfg/ctf_well.cfg files. I even tried setting mp_maxrounds 9 in case
rounds were being counted that way (which would also be bad). Then the
stalemates started happening, and I discovered that the map will not
allow a sudden death and will NOT end otherwise at mp_timelimit.
If it were not for beetlemod's ability to force a mapchange at a
configurable period of time, or its ability to add "tasks" to run at a
certain amount of time into map start, round start, etc. I would have no
way to automate the ending of this map, and until this idea came to me I
had to pull Valve's brand new map from our mapcycles. Maps that go on
forever make good people leave. Furthermore, forcing a map change from
a plugin generally means no scoreboard/mp_chattime beforehand, so it
doesn't "look" very good to have to do it this way.
I also remember that the interaction between sudden death and
mp_stalemate_enable was one of the items "fixed" in the server update
that included this new map.
If I'm doing something wrong or missing something, please point it out
to me. I'm not going to pretend I know everything there is to know
about running Valve dedicated servers, but I have been doing it for a
year and a half now. The map seems broken to me.
If I'm not overlooking something and this is just the way the map is
right now, I really hope it was an oversight, and not the shape of
things to come with Valve and TF2. I am reminded of Dynamic Weapons
Pricing in CS:S. If they had not "woken up" and given us a cvar to turn
it off (ie, LET THE SERVER OPS CHOOSE HOW TO RUN THEIR SERVERS) we would
have terminated our gameservers the minute the update containing DWP was
shoved down our throats.
Vince
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlds_linux
