Re: [hlds_linux] Upcoming Team Fortress 2/Dedicated Server Update
Ronny Schedel wrote: Then you did it always wrong and it was working until the last patch. You can check it by yourself, you have two tf directories in ~/tf2, one is ~/tf2/tf (wrong one) and one is ~/tf2/orangebox/tf (good one). Umm, nope. Wrong again. Ask the author of Beetlemod who helped him get working/current Linux versions of his plugins going again starting last year. If I can jump into over 100,000 lines of source code I have never seen before and have working linux plugins compiling for these games in less than 2 weeks, do you really think I need anybody's advice on how to write a 10-15 line script to update this game? Anyway, problem solved. the spam messages were related somehow to the updates and us running >24 slots (with strictly valve >24 player support), did not actually prevent players from getting onto the server (as real mandatory update situations do). And all the spam messages about needing to update stopped as soon as I updated the servers with the next update that came out the very next day. Admittedly, I just wanted to see if the update that came out the next day would fix the problem. It did. "Best Regards" ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Upcoming Team Fortress 2/Dedicated Server Update
Ronny Schedel wrote: The correct installation path in your case is ~/tf2/orangebox/ Dude, if my script was really THAT messed up I think I would have had problems trying to update with it starting back in October, not starting just last night. As I said, this has worked flawlessly for me. Doesn't matter though. The TF2 servers are shut down now. vw ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Upcoming Team Fortress 2/Dedicated Server Update
Jason Ruymen wrote:
This is a multi-part message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
If all goes well, we'll be releasing a required Team Fortress 2 later
today. I don't have the exact changlist yet, but one of the things
going live for clients will be the new Server Tags interface. I know we
announced to you that we'd release this as a Beta, but we've been
testing it here with the tags you're already using and think it's ready
for the Public.
Am I the only one who KEEPS getting these messages after updating their
linux server:
MasterRequestRestart
Your server needs to be restarted in order to receive the latest update.
Your server needs to be restarted in order to receive the latest update.
It doesn't matter how many times I run my game-update script (see
below). It doesn't matter if I delete ~/tf2/InstallRecord.blob and try
again. It also doesn't matter if I create a brand new user on the
server and unpack a backup tarball of the entire pristine game tree from
a couple months ago (before any customizations whatsoever were made to
it) in the user's home directory, delete tf2/InstallRecord.blob, and run
the update script on that. I still get the same thing.
The only thing I haven't done is download the entire gameserver tree
again from scratch from a Steam master server and begin the painful
process of recreating the directory trees on the live game servers. All
the configs, etc.
I shouldn't have to re-download the entire gameserver tree from Valve
again. And I'm not going to. It's not worth the trouble. If the steam
client can't update the existing game files correctly then something is
horribly broken which worked just fine before this update. (Imagine
that...)
Why should I burn up 2 more gigabytes of our server bandwidth to pull
the entire tree again, especially if the problem is the steam client itself?
This pretty much settles the question of running this game on our server
anymore.
Valve you need to get your feces consolidated.
"we feel this is ready". pffft.whatever
This game update script has worked flawlessly for me until yesterday.
-
# update game function definition
game_update() {
./steam -command update -game "tf" -dir . -verify_all
}
cd ~/tf2
# run update function once in case we get a zero return value on 1st try:
game_update
## loop - we should keep doing this until we get a zero return
#
until [ $? -eq 0 ] ; do
game_update
done
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Map changing at timelimit instead of end of round time.
AnAkIn . wrote: -- [ Picked text/plain from multipart/alternative ] Hello, There seem to be a problem on my server since the last update, when the timeleft reachs 0:00 (mp_timelimit), the map automatically goes in sudden death or change. This happen on cp_ maps and shouldn't happen, the map should change at the end of the map/round time if the timeleft is 0:00 (mp_timelimit). Yep, it happens to us too. I've gone back over the map-specific .cfg files for these maps (like cp_dustbowl) and set mp_timelimit 0 and mp_stalemate_enable 0 on them to try to see if it would help. However there just hasn't really been any activity on the server since the night the last update got released, and TBH we haven't felt like sitting there as the only 2 players on the server for 2+ hours to try to get other players to come on until we can get a good game going. It seems like once you hit around 7-8 players on the server, it fills up quickly after that -- but getting/keeping that first 7-8 players to show up isn't always easy. We're pretty much burning out on this game. Too much server maint/work (especially when updates come out, having to figure out how to work around a problem that didn't exist before the update), and WAY too much babysitting while trying to play. vw ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Upcoming Team Fortress 2 update
Hmm sudden death/stalemate is fairly different now too. It appears that if a time limit is set (mp_timelimit) and mp_stalemate_enable is enabled on a map, when time limit is hit, it just calls stalemate and goes on to the next map. There doesn't seem to be a way to get an actual sudden death (people fight to the death) but maybe I just have to futz around with the cvars and see if beetlemod isn't getting in the way somehow. But definitely a change since the update. vw ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] RE: [hlds] Team Fortress 2/Dedicated Server Updated
Eric Smith wrote: The new value is 3, and this is the default value for TF2 (unless you override it in your server.cfg). This behavior is what everyone is used to for TF2: 3 = spectate only your team, first-person or chase-cam After Thursday's update I found that almost every custom map we have installed on the server would crash the server as soon as a player chose a team to join (after a map change). These are the maps that would crash our server as described above EVERY TIME: cp_wolf cp_420_crazed__arena_v2 cp_horus_b3 cp_orange_x ctf_canyon_final ctf_stronghold_b5 ctf_valley Setting mp_forcecamera to 3 stopped the crashes. I had it set to mp_forcecamera 0 originally. Since 3 is apparently the default I just commented out the mp_forcecamera cvar in server.cfg and rebooted the servers. Now to try to figure out why custom map files are being changed. Between all these unexpected gotchas, the load TF2 instances put on our server hardware, and attitude of so many of this game's players, we are really starting to question running this game at all. vw ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] ctf_well - no sudden death?
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
[hlds_linux] ctf_well - no sudden death?
I am wondering why valve decided (apparently) to not allow sudden death mode in ctf_well. I cannot even force sudden death mode on the map with Beetlemod's admin plugin. Furthermore, the map does not honor mp_timelimit or mp_maxrounds, and since TF2 does not have an mp_roundtime, then there seems to be no official way (official = something I don't have to use a 3rd party plugin to do) to end the map if things end up in a stalemate, other than just doing a changelevel. Which is of course very abrupt and a non-tasteful way to do things. I wish I could I say that all of the players on our servers always act like a team and coordinate to accomplish the objective of the map, but I would be lying to say so. As a matter of fact, most of the time, they don't. So CTF maps very often end up in stalemate. On every other CTF map we run on our server (Valve map or custom map), even tc_hydro, mp_stalemate_enable switches the map into sudden death mode if neither team has accomplished the objective by the time limit. We use Beetlemod's "melee weapons only" feature for sudden death mode - it is enjoyable for most of our regulars, and for those few who complain about it, we tell them to complete the objective before time limit if they don't like getting stuck in melee only mode. Whether we use melee only or not doesn't really matter though - the point is - we don't want our server stuck on ctf_well for 3 hours because it happens to take that long to cap the intel three times, and the map won't honor mp_timelimit. I do hope this was an oversight on Valve's part. Apparently there is some talk of Valve doing away with sudden death mode across the board in TF2. I do hope there is no truth to this. Please fix this in ctf_well. As it stands currently we have to use a 3rd-party plugin to force the map to change (without a scoreboard/mp_chattime) after x number of minutes just to get on with the map cycle, and spam warnings to the console as the timer end approaches. This is cheesy, and I don't even run like to run custom maps where this is necessary. I would not expect this to be a problem with an official Valve map. Please let the server operators choose how to run their servers and maps need to run. Don't decide for us. Without server operators your customers would have nowhere to play. Thank you. Vince ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] What is your cpu load?
Evaldas Žilinskas wrote: Ou! I have a question. How these Intel 5310 are performing with older engine SRCDS servers? At the moment my Pentium 935’s aren’t doing any good. I mean, that one 66tick 24slot DODS server does about 70% of one core load. But we are talking about 3.2GHz over clocked up to 3.8GHz. Anyway, 5310 is only 1.6GHz and “Protocol 7” doesn’t support any multicore load balancing… and I bet that it will not in the future. How does the 5310 handle? What CPU loads you get? Hi Evaldas, So far we only have TF2 instances running on this box, but I haven't finished migrating stuff over to the new dedicated server (we just got it a few weeks ago). Once I'm finished moving everything we'll be putting one CS:S server up on it and I'll post back here to answer that question. It has been my experience thus far with the other server that CS:S uses about half or just slightly less than half of the CPU resources - we did have a TF2 and CS:S instance running on the other box. Things may be a little different on this one (the 5310 server) but will know for sure soon. Vince ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] What is your cpu load?
We see the same thing. Intel 5310 1.6GHz quadcore Xeon 8MB cache, 4MB RAM. Running Centos 5.1 x86 with a couple different flavors of custom kernels compiled for max performance with these CPU's, and glibc-2.5-18.el5_1.1. (Note: we also saw same issues on a 3GHz dual core box running single instances.) We run 28-slot servers, currently 3 of them, on the box. We have seen CPU utilization at >90% on one server instance with the server full and at a "busy" point, even with the other 2 instances empty, and performance of the game as described below. We only run 1 plugin (beetlesmod), though performance is same without it. Up to this point I have not attempted to use taskset to "lock" processes to individual CPU cores, as I am not sure what its effect would be if there is any multi-core utilization going on in the server. I found some discussion of this the other day when I discovered the host_thread_mode cvar but then subsequently learned googling that it doesn't do anything for dedicated servers, but that some(...) multi-core utilization is already in the dedicated server binaries. So it doesn't seem to make sense to taskset the game to only 1 core unless I'm just not understanding. I'm also thinking that I would probably lose the benefit of trying to keep the gameserver processes running on specific CPU cores, and at the same time accomodate any multicore processing going on in the dedicated server, by using taskset to bind each process to 2 specific cores (and "mixing it up" a bit with which cores each process gets taskset to). I may just be over-analyzing all of this with a less-than-perfect understanding of any of it. But what I do know is, TF2 uses a LOT more CPU on Linux than CS:S does to handle the same level of activity/# of busy player slots - at least twice as much, from what I have seen. I can't help wondering if there is not a lot more optimization that could be done with the code, or how it is compiled, so that it can run more efficiently in Linux. The server drops to low double-digit server fps when things get really busy - for example, heavy firefights, or the end of stage 2 dustbowl when everybody is shooting, all engies banging on their gear, etc., and lags noticeably. The incoming updates from the server sometimes dips as low as 15 per second, and stats output showing as low as 20 server fps. We had to reduce the slots from 32 to 28 to get this more under control. We also use Beetlemod's (small|medium|large)maps.cfg files to vary the max ping limit allowed based on number of players on the server, so when the server is full 300ms ping is max we allow before the player gets kicked. REALTIME/TICKLESS KERNEL I've tried 2.6.24-rc5rt -- tickless kernel, hires timers, compiled with every compiler flag optimization the CPU family supports, kernel IRQ balancing enabled (and userspace irqbalance daemon disabled) etc. The server will hover around 935+ server fps on this kernel under low "in-game demand" (though I normally fps_max much lower - 200), but it can't sustain it when things get busy in the game. Based on top output, the CPU load of each server instance seems to be spread across all 4 CPU cores, but I'm not so sure this is a good thing. (if we really are doing that much task migration it is going to introduce overhead) For me, the problem using the realtime kernel is that I keep seeing "Warning: System clock went backwards 1 seconds" messages come through in bursts in the game console periodically, and when this happens, the server lags for 3-5 seconds - this really annoys the connected players (and me). I've tried both hpet and acpi_pm clocksources (the server has both), but same problem with either. This may be something needing to be addressed in the kernel timers code with realtime patches in use, or maybe even an indication of a jittery timers on the hardware (but I don't think so). Or maybe it's just how the gameserver reads the time. But overall, I haven't seen where the game really runs noticeably better on this kernel, regardless of how I tune the realtime priority (with chrt) or nice levels. "STOCK-ish" 5.1 kernel I also took the stock Centos 5.1 (2.6.18-whatever) .src.rpm, went in and set various performance-related settings available (CONFIG_HZ to 1000, highest available compatible CPU type in menuconfig, full pre-emption, etc.) and compiled it using all compiler flags the CPU supports (core2duo march/mtune, -msse3, -mssse3, -mfpmath=sse, etc.). Under this kernel, I see no problems with the "clock went backwards" messages (and therefore we don't get the big lag spikes periodically), and with fps_max at 200, the server fps hovers around 166 under no/light load. The gameserver processes seem to "stick" to particular cores more consistently (you see the CPU utilization top reports on the process directly impacting 1 core and not really touching the other 3). But we still see the same CPU utilization (approaching and sometimes exceeding 90%) when the game
[hlds_linux] TF2: server allows double quote characters in usernames
Hello, We are having a problem processing the server logs with Psychostats when it encounters lines from the log file in which a player name contains " characters. The developer of Psychostats says that the game server is not supposed to be allowing " to be used in a player name, however, I have confirmed that it is possible to set your player name via the Edit Steam ID interface to something which contains " characters, and am able to get onto the server with this player name (and log entries for me have this player name unmodified). This means we have to figure out some way to "re-process" the log files we have now which contain players having " in their names, or what to code into the Psychostats log parser to handle this, and the Psychostats developer has already said he doesn't know of a way to do this. If it is true that the server should not allow " to be used in a player name, any chance we can get this addressed in a future update? I'm trying to figure out a sed/awk regex I can use in the meantime to "re-process" the log files so I can generate stats on them, but not having a great deal of luck thus far. Thanks, Vince W. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
