Re: [hlds_linux] lagg problem on ubuntu 12.04
Well, as long as the updaterate and cmdrate are the same or close to each-other and 30 or above, and 66 or below, with a "sane" rate, the experience will be good. you hinted already: ping 100 or higher is really bad for experience (personally, I start to notice it on ping 60 and higher). But that's ping, nothing to do with these settings. I agree that some servers have really bad configs in that regards for players, the min and max values are to allow a degree of freedom to gamers, not pushing them too far, and not allowing them to be too low. Or servers that have 10 instances running on a dual core, with a cap limit by their hoster. Unfortunately, there are also still a load of countries where dial-up is still the latest technology they know. So while here in the west we have the luxury of good connection, a friend of mine in some east European country has to call his shaman bout everyday to get his ADSL router working for a measly 4096/256 Kbit. > > From: dan >To: Half-Life dedicated Linux server mailing list > >Sent: Thursday, 18 October 2012, 15:38 >Subject: Re: [hlds_linux] lagg problem on ubuntu 12.04 > >On 16/10/2012 11:56, Drogen Viech wrote: >> Why can't you just leave the cmd- and updaterate alone? It seriously >> pisses me of when people think "higher == better" - the default >> settings of updating and sending 30 times per second are just fine. > >I'd say they definitely matter. There's no higher==better of course. >I think they should be 66 - the tic rate of the server. So fixed values. > >Higher shouldn't, aiui, achieve anything. But is there any sane reason for >them to be lower? Unless there's >some country with a significant dialup population (but their experience is >going >to suck anyway) or if someone can show (in a robust way) that the lower values >make >no difference. > >The point is, I don't understand why you can even change these values in the >first place. >Why aren't they constants? And 66? > >The same with rate. <= 3 and its anecdotally not as good. That's over >several >thousand hours of playing. I can tell without looking if I join a server that >has either capped max_rate or >forced it to a particular value compared with the client setting I have. > >But, equally, there are a set popular servers with sv_min_rate 9 for some >bizarre reason, and they seem just as broken as >the ones with it set low. (It's not clear whether their performance issues are >because they have hundreds of servers though or >whether it's the actual config causing them) > >But, I don't really understand why the defaults are what they are. >The defaults should be right in the sense that >- There should be no need for servers to cap anything based up a feeling they >have that clients could break something if they don't. Or that without the >caps it would give some players an advantage over others if they aren't aware >of the client settings. >- There should be no need for servers to change things today because the >defaults are years out of date. >- This should apply to the client settings too. if I can change my settings >and get a better experience - especially if that gives an advantage or edge >over other players, then either the defaults are wrong and/or the fact these >settings are hidden is wrong. > >Although I'd tentatively agree with you that server admins pissing with them is >one of the worst aspects of 3rd party servers it's not because they make them >bigger. >It's usually the reverse. > >Especially now more of Valve's games are forcing matchmaking and, as we saw >last night, as >Valve are trying to slowly hammer a wedge into the "punish you for leaving >early" initiatives. > >Join a server with sv_max_rate 25000 and I'll usually leave. Perhaps >that won't affect mann up (but Valve's French servers are a performance joke >so I hope they aren't punishing >anyone for leaving them) similarly there are umpteen admin foobars and no-nos, >halfwitted plugin use >that the browser and (obviously matchmaking) does not tell you or let you >filter out before you join. > >Hence, it's no wonder lots of people leave games after finding themselves on a >server like that. Valve's French servers could barely manage 12v12 and cannot >run boot camp MvM - so I'm sure some of this will affect mann up servers. > >It would make sense if Valve are phasing out server browsing and having "you >must finish a game" initiatives, to improve the server matching so it takes >into account not just ping but these parameters too, and plugin use. A good >first step might be getting sane defaults in place if they genuinely aren't >sane now (and I would say anecdotally setting cl_updaterate and so on to 66 , >rate to 6 and cl_interp to 0 (which gives you typically 30.0ms instead of >100.0ms but some server admins have managed to break this) is a much better >experience and an advantage over anyone who uses the defaults. > >So either I'
Re: [hlds_linux] Map timelimit 5 minute buffer
We have a 20 minute timer for CP matches. On 10/20/2012 7:34 PM, Ross Bemrose wrote: Why are you using mp_timelimit on a Tournament server? On 10/20/2012 10:17 PM, StevoTVR wrote: From my experience playing TF2, there appears to be a 5 minute buffer zone where the map will change if the round ends. Is there a cvar to change this behavior? This seems to be triggering in tournament mode and we'd prefer it not to. Thanks ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
Re: [hlds_linux] Map timelimit 5 minute buffer
Why are you using mp_timelimit on a Tournament server? On 10/20/2012 10:17 PM, StevoTVR wrote: From my experience playing TF2, there appears to be a 5 minute buffer zone where the map will change if the round ends. Is there a cvar to change this behavior? This seems to be triggering in tournament mode and we'd prefer it not to. Thanks ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
[hlds_linux] Map timelimit 5 minute buffer
From my experience playing TF2, there appears to be a 5 minute buffer zone where the map will change if the round ends. Is there a cvar to change this behavior? This seems to be triggering in tournament mode and we'd prefer it not to. Thanks ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
Re: [hlds_linux] Server Reassigning Public IP - Dropping off master server List
Thank you so much for the iptables rules. Ever since implementing them I haven't had a single problem with the IP address changing on any of my servers. Chris On Tue, Oct 16, 2012 at 4:41 PM, Kyle Sanderson wrote: > Yup. > > iptables -A OUTPUT -p tcp -m multiport --dports 27017:27019 -j REJECT > --reject-with icmp-port-unreachable > > Huge thanks to Ryan for his Windows rules (and discovering the solution). > This statement seems to work fine for me. You can probably define it even > more by specifying the process and or user. It's a shame no one at Valve > sees this as a problem... We weren't listed for a while there. > > Thanks, > Kyle. > > > On Tue, Oct 16, 2012 at 8:41 AM, Chris Oryschak > wrote: > > > Do you have the iptables rule to accomplish this. > > If this has no side effect to the users and forces it UDP every time. > I'd > > be much happier to go this route as a resolution. > > > > Chris > > > > On Tue, Oct 16, 2012 at 11:38 AM, Ryan Stecker > >wrote: > > > > > As a slight correction, it's the TCP connection which doesn't respect > the > > > bind IP. > > > > > > The workaround is to block outgoing TCP connections on port 27017, this > > > forces the server to use a UDP connection to steam. > > > > > > On Tue, Oct 16, 2012 at 10:34 AM, martin v wrote: > > > > > > > This is well know issue. When your machines IP is different from the > > > > gameservers IP and when your gameserver lost connection to steam. > When > > > > gameserver is connecting to steam servers it sends machines main IP > and > > > not > > > > the attached server ip. > > > > > > > > The worst part is that when someone joins your server and you want to > > > check > > > > game info on friends it shows the wrong ip and doasn't detect a > > > gameserver > > > > where this person is playing. > > > > > > > > http://forums.alliedmods.net/showthread.php?t=183574 - my thread on > > this > > > > issue. > > > > > > > > Only way to repair this is to restart gameserver. > > > > > > > > 2012/10/16 Asher Baker > > > > > > > > > I believe Valve have already acknowledged it as an issue in the > past. > > > > > It happens when the server loses connection to Steam, which causes > it > > > > > to switch transport protocols - and the UDP one doesn't respect the > > > > > bind address. > > > > > Other than block the problematic one, forcing it to toggle back to > > the > > > > > other, there isn't really anything you can do. > > > > > > > > > > On Tue, Oct 16, 2012 at 9:25 AM, Rudy Bleeker > > > > wrote: > > > > > > Have you tried setting ip in the server > > > > > > specific config file? server6.cfg in this case. I do this and > > haven't > > > > > > seen this issue so far. > > > > > > > > > > > > On Tue, Oct 16, 2012 at 7:11 AM, Chris Oryschak < > > ch...@oryschak.com> > > > > > wrote: > > > > > >> Sorry forgot the mention my start line. I do use +ip and -port. > > > > > Below is > > > > > >> my startline: > > > > > >> > > > > > >> > > > > > >> /usr/bin/screen -d -m -U -S rb6 /usr/bin/taskset -c 1 > > > > > >> /home/XXX/srcds/railbait/orangebox/nemrun -threads 1 -timeout 3 > > > > > -pidfile > > > > > >> rb6.pid -console -game tf -maxplayers 32 -tickrate 66 +ip > > > > > 142.54.178.234 > > > > > >> -port 27015 +map pl_badwater +sv_pure 1 +servercfgfile > server6.cfg > > > > > -replay > > > > > >> +mm_pluginsfile addons/metamod/metaplugins_6.ini +sm_basepath > > > > > >> addons/sourcemod_6 -onbootcmd './bootnotify.sh 6' -debug > > -corefile > > > > > >> 'cores/rb6_%Y%m%d%H%M%S.core' > > > > > >> > > > > > >> > > > > > >> On Tue, Oct 16, 2012 at 1:07 AM, ics wrote: > > > > > >> > > > > > >>> You should use option +ip instead of -ip and assing -port. On > the > > > > > original > > > > > >>> post, you haven't got that specified on the startline. > > > > > >>> > > > > > >>> -ics > > > > > >>> > > > > > >>> 16.10.2012 7:33, Chris Oryschak kirjoitti: > > > > > >>> > > > > > This has been a known issue for quite sometime. Myself along > > with > > > > > other > > > > > mailing list members have brought it up in the past. > > > > > The past week it seems to of gotten a lot worse. Today alone > > i've > > > > > had to > > > > > fix the problem on two separate occasions. > > > > > > > > > > *The details:* > > > > > > > > > > I have a dedicated server with 4 IP address' assigned to it. > > Each > > > > > server > > > > > instance I run has it's own unique IP Address with the default > > > port > > > > > for > > > > > each instance (27015) > > > > > > > > > > Now randomly the server will lose it's assigned IP address and > > > > > reassign > > > > > itself one of the other IP's that are available. The problem > > with > > > > > this is > > > > > the moment it occurs the server drops from the master server > > list. > > > > > It's > > > > > no > > > > > longer visible on the internet. > > > > > > > > > > When type "status" in the console this is what
Re: [hlds_linux] SourceTV crashing clients?
Seconding this as a valid solution(workaround?) On Sat, Oct 20, 2012 at 7:09 AM, Invalid Protocol < invalidprotocolvers...@gmail.com> wrote: > I had a similar problem and the solution was to add +tv_enable 1 in > server's > command line. If Source TV is enabled later from server's configuration > file > then some clients crash to desktop when viewing the motd or few seconds > after they join the server (when we did tests we used soldiers and scouts > and usually the crashes occurred when jumping). > > -Original Message- > From: hlds_linux-boun...@list.valvesoftware.com > [mailto:hlds_linux-boun...@list.valvesoftware.com] On Behalf Of Essay Tew > Phaun > Sent: Saturday, October 20, 2012 6:19 AM > To: Half-Life dedicated Linux server mailing list > Subject: [hlds_linux] SourceTV crashing clients? > > Kind of a drawn out situation but I'll try to summarize most of it. > > Earlier today I was working on getting some mods installed and testing them > on our private server before deploying them. Noticed I was getting some > random crashes with the following error which almost exclusively happens > when changing teams or joining a team. > > Problem signature: > Problem Event Name:BEX > Application Name:hl2.exe > Application Version:0.0.0.0 > Application Timestamp:505ba1c3 > Fault Module Name:StackHash_0a9e > Fault Module Version:0.0.0.0 > Fault Module Timestamp: > Exception Offset: > Exception Code:c005 > Exception Data:0008 > OS Version:6.1.7601.2.1.0.256.1 > Locale ID:1033 > Additional Information 1:0a9e > Additional Information 2:0a9e372d3b4ad19135b953a78882e789 > Additional Information 3:0a9e > Additional Information 4:0a9e372d3b4ad19135b953a78882e789 > > > I chalked this up as a problem with one of the recent plugins I had added, > so I removed it. > > Fast forward to tonight when we're using this same server for a private > tournament. Multiple people are crashing with the above error. Confused > about what it could be (Because I assumed it was that plugin) I stripped > sourcemod down tot he bare bone plugins. They still crashed out of game > with that error. > > We run 5 servers off of the same installation and I'd already tried a fresh > sourcemod install and earlier in the day when i was experiencing those same > crashes I reinstalled my own copy of TF2 on my PC after a bit of googling > the error. None of our other servers experience these crashes. I further > went on to remove the Pinion MOTD and disable sourcemod entirely, still > crashing clients. The last thing I thought of, which didn't occur to me > until after a while was the SourceTV was the last thing that differed. I > disabled it and away went the crashes. I got them to play for about 15-20 > minutes, no crashes. I then enable STV again and have them rejoin, crashes. > I disable it, no crashes. > > It's pretty safe to say SourceTV is causing clients to crash out of the > game somehow. I'd take a guess there is some logic being run when a player > joins or changes his team that checks the slots and is somehow crashing > clients when hitting the SourceTV. > > Hopefully I'm not missing something blatantly obvious, but I don't think I > am. We didn't have this issue for our last tournament match a month or two > ago. > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux > > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux > ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
Re: [hlds_linux] SourceTV crashing clients?
I had a similar problem and the solution was to add +tv_enable 1 in server's command line. If Source TV is enabled later from server's configuration file then some clients crash to desktop when viewing the motd or few seconds after they join the server (when we did tests we used soldiers and scouts and usually the crashes occurred when jumping). -Original Message- From: hlds_linux-boun...@list.valvesoftware.com [mailto:hlds_linux-boun...@list.valvesoftware.com] On Behalf Of Essay Tew Phaun Sent: Saturday, October 20, 2012 6:19 AM To: Half-Life dedicated Linux server mailing list Subject: [hlds_linux] SourceTV crashing clients? Kind of a drawn out situation but I'll try to summarize most of it. Earlier today I was working on getting some mods installed and testing them on our private server before deploying them. Noticed I was getting some random crashes with the following error which almost exclusively happens when changing teams or joining a team. Problem signature: Problem Event Name:BEX Application Name:hl2.exe Application Version:0.0.0.0 Application Timestamp:505ba1c3 Fault Module Name:StackHash_0a9e Fault Module Version:0.0.0.0 Fault Module Timestamp: Exception Offset: Exception Code:c005 Exception Data:0008 OS Version:6.1.7601.2.1.0.256.1 Locale ID:1033 Additional Information 1:0a9e Additional Information 2:0a9e372d3b4ad19135b953a78882e789 Additional Information 3:0a9e Additional Information 4:0a9e372d3b4ad19135b953a78882e789 I chalked this up as a problem with one of the recent plugins I had added, so I removed it. Fast forward to tonight when we're using this same server for a private tournament. Multiple people are crashing with the above error. Confused about what it could be (Because I assumed it was that plugin) I stripped sourcemod down tot he bare bone plugins. They still crashed out of game with that error. We run 5 servers off of the same installation and I'd already tried a fresh sourcemod install and earlier in the day when i was experiencing those same crashes I reinstalled my own copy of TF2 on my PC after a bit of googling the error. None of our other servers experience these crashes. I further went on to remove the Pinion MOTD and disable sourcemod entirely, still crashing clients. The last thing I thought of, which didn't occur to me until after a while was the SourceTV was the last thing that differed. I disabled it and away went the crashes. I got them to play for about 15-20 minutes, no crashes. I then enable STV again and have them rejoin, crashes. I disable it, no crashes. It's pretty safe to say SourceTV is causing clients to crash out of the game somehow. I'd take a guess there is some logic being run when a player joins or changes his team that checks the slots and is somehow crashing clients when hitting the SourceTV. Hopefully I'm not missing something blatantly obvious, but I don't think I am. We didn't have this issue for our last tournament match a month or two ago. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
