Re: [hlds_linux] Huge sv drops and var spikes in net_graph 4.

[Essay Tew Phaun]

That is exactly it. I've been sending a bunch of data to Fletcher but I
suggest if anyone else has the requested data they send it too.


On Tue, May 14, 2013 at 8:07 PM, pilger  wrote:

> Can anyone confirm if what's seen on this video I recorded (
> http://www.youtube.com/watch?v=nMJ5dsAVZKI ) is the same problem everyone
> is having!?
>
> It's disrupting gameplay and the server never gets full since the SteamPipe
> convertion.
>
> _pilger
> ___
> 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] Huge sv drops and var spikes in net_graph 4.

[Essay Tew Phaun]

Well we at least confirmed it's definitely not a hardware issue. Two
separate systems in separate locations have the exact same problem. The
only difference is one is the 1270 and one is the 1230. Same OS.


On Sat, May 11, 2013 at 1:27 PM, Abdulrahman Abdulkawi  wrote:

> @Fletcher Dunn,
> On linux the CPU affinity is auto-detected/decided by the srcds process,
> which is normal (same as hlds). I monitored the threads created by the
> process: they do not spike and only 3 are consecutively running. The actual
> srcds process is what spikes (the srcds process cpu% does not include the
> threads % usage when monitoring with htop, which is how I know only the
> srcds spikes, not it's threads).
> Without -replay does reduce CPU usage which makes it not go 'overboard'
> when the process spikes.
> I have tried using strace although there's way too many lines/events to
> figure out at which point it spiked. I will however soon try and see if I
> can have it log only certain events with timestamp.
> I've taken the following excerpts from the strace log (in random order):
> --- Lines Beginaccept(12, 0xffe5aeec, [16])= -1 EAGAIN
> (Resource temporarily unavailable)recv(16, 0xffe5bf8f, 1, MSG_PEEK)   =
> -1 EAGAIN (Resource temporarily unavailable)
> send(42, "\2\1\0\0\0\262\2\0\0", 9, MSG_NOSIGNAL) = 9
> futex(0xf73c8598, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0xf73c8594, {FUTEX_OP_SET,
> 0, FUTEX_OP_CMP_GT, 1}) = 1futex(0xf73c857c, FUTEX_WAKE_PRIVATE, 1) =
> 1futex(0xf73c8558, FUTEX_WAKE_PRIVATE, 1) = 1futex(0xdc16fce4,
> FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily
> unavailable)futex(0xdc16fce4, FUTEX_WAKE_PRIVATE, 1) = 0
> futex(0x128048d4, FUTEX_WAIT_PRIVATE, 2, NULL) = 0futex(0x128048d4,
> FUTEX_WAKE_PRIVATE, 1) = 0
> futex(0x9f76a24, FUTEX_WAIT_PRIVATE, 7, {29, 61633}) =
> 0futex(0x9f76a08, FUTEX_WAKE_PRIVATE, 1) = 0--- Lines End
> Upon server startup there are a lot of lines for each
> model/material/scripts...etc:
> open("/home/tf2/badwater/hl2/materials/models/weapons/v_machete/models/weapons/v_machete",
> O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such
> file or directory)
> I doubt that explains the spikes but probably has an impact to server
> restart/startup?
> Does any of that help?
> > Date: Sat, 11 May 2013 10:54:36 -0400
> > From: sc2p...@gmail.com
> > To: uniac...@yahoo.ca; hlds_linux@list.valvesoftware.com
> > Subject: Re: [hlds_linux] Huge sv drops and var spikes in net_graph 4.
> >
> > Just tested without SourceTV, no difference at all.
> >
> >
> >
> >
> > On Sat, May 11, 2013 at 10:07 AM, Essay Tew Phaun 
> wrote:
> >
> > > So I've got two demos here. The first one, go to about tick 19000 and
> wait
> > > to around the point where Fred 2.0 joins. The server drops to 5
> frames. I
> > > removed Sourcemod and recorded on another server. I wasn't able to get
> > > those huge drops but there are big var spikes ~10 and it *seems* to
> happen
> > > as clients join.
> > >
> > > http://dropcanvas.com/8itl3/1
> > > http://dropcanvas.com/8itl3/2
> > >
> > > I can't think of what else it could be. We haven't changed anything
> about
> > > the setup from before Steampipe to after.
> > >
> > >
> > > On Mon, May 6, 2013 at 1:00 PM, Bjorn Wielens 
> wrote:
> > >
> > >>
> > >>
> > >> Thanks for investigating, Fletcher.
> > >>
> > >> I can tell you that in our case, we have an 8 core system with no CPU
> > >> affinity assigned (with 12 TF2 servers running comfortably with CPU to
> > >> spare, srcds generally consumes 30% but can get mid 40s when full of
> > >> players), Watching top, the load is fairly evenly distributed across
> the
> > >> individual cores, and monitoring resource usage showed only one
> process
> > >> spiking in usage at a time.
> > >>
> > >>
> > >> For what it's worth, I haven't had the issue recur after disabling
> replay
> > >> on the servers in question. For me, that would mean the next step is
> to
> > >> re-enable it and see if the problem returns - I'll post back here
> when I
> > >> get those results (though it's entirely possible that the additional
> replay
> > >> overhead is the metaphorical straw on the camel's back) and any
> additional
> > >> information I uncover.
> > >>
> > >>
> > >>
> > >>
> > >>
> > >&

Re: [hlds_linux] SteamPipe CPU Increase?

[Essay Tew Phaun]

Just spent a while this morning watching for the CPU jumps. I set the delay
in TOP to .1 and sure enough, 30-40% CPU usage was spiking to 110+ and
immediately dropping back down. Something is going hayware, for sure. We
have not assigned the servers to specific cores.


On Tue, May 7, 2013 at 9:59 PM, Eli Witt  wrote:

> What's your cron delay for cacti's update script?
>
> I found it's default to be too wide so I said screw it, I've got plenty of
> space and my logfiles/rrds are all on a ramdrive and just move the rotates
> log archives nightly, so I run it every minute. It catches much more now.
>
>
> On Tue, May 7, 2013 at 6:29 AM, Peter Reinhold  >wrote:
>
> > On 06.05.2013 00:35, Essay Tew Phaun wrote:
> >
> >  We have that CPU on 24 player servers and get that issue too.
> >>
> >
> > After updating to SteamPipe, i've been getting complaints from the
> > regulars as well.
> >
> > Average CPU (per Cacti monitoring) does not seem to have changed much, if
> > at all, but apparantly CPU/Lag spikes are occuring.
> >
> >
> > /Peter
> >
> >
> > __**_
> > To unsubscribe, edit your list preferences, or view the list archives,
> > please visit:
> > https://list.valvesoftware.**com/cgi-bin/mailman/listinfo/**hlds_linux<
> 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] Huge sv drops and var spikes in net_graph 4.

[Essay Tew Phaun]

Just tested without SourceTV, no difference at all.




On Sat, May 11, 2013 at 10:07 AM, Essay Tew Phaun  wrote:

> So I've got two demos here. The first one, go to about tick 19000 and wait
> to around the point where Fred 2.0 joins. The server drops to 5 frames. I
> removed Sourcemod and recorded on another server. I wasn't able to get
> those huge drops but there are big var spikes ~10 and it *seems* to happen
> as clients join.
>
> http://dropcanvas.com/8itl3/1
> http://dropcanvas.com/8itl3/2
>
> I can't think of what else it could be. We haven't changed anything about
> the setup from before Steampipe to after.
>
>
> On Mon, May 6, 2013 at 1:00 PM, Bjorn Wielens  wrote:
>
>>
>>
>> Thanks for investigating, Fletcher.
>>
>> I can tell you that in our case, we have an 8 core system with no CPU
>> affinity assigned (with 12 TF2 servers running comfortably with CPU to
>> spare, srcds generally consumes 30% but can get mid 40s when full of
>> players), Watching top, the load is fairly evenly distributed across the
>> individual cores, and monitoring resource usage showed only one process
>> spiking in usage at a time.
>>
>>
>> For what it's worth, I haven't had the issue recur after disabling replay
>> on the servers in question. For me, that would mean the next step is to
>> re-enable it and see if the problem returns - I'll post back here when I
>> get those results (though it's entirely possible that the additional replay
>> overhead is the metaphorical straw on the camel's back) and any additional
>> information I uncover.
>>
>>
>>
>>
>>
>> 
>>  From: Fletcher Dunn 
>> To: Half-Life dedicated Linux server mailing list <
>> hlds_linux@list.valvesoftware.com>
>> Cc: "Half-Life dedicated Win32 server mailing list (
>> h...@list.valvesoftware.com)" 
>> Sent: Monday, May 6, 2013 1:41:18 PM
>> Subject: Re: [hlds_linux] Huge sv drops and var spikes in net_graph 4.
>>
>>
>> I was able to get a trace from a Windows server operator that was
>> experiencing a similar problem.  The problem in that case was that it was
>> spending all of its time compressing snapshots.  The problem was
>> exacerbated by some process affinity settings which were counterproductive
>> and putting all the threads on the same core, while other cores were idle.
>>
>> Tracking the overall CPU usage can be quite deceiving when investigating
>> "lag".  Lower CPU usage is not necessarily better!  For example, in this
>> case if the process affinity were not set and more cores were allowed to be
>> used, then the CPU usage on this 4-core system would have gone above 25%
>> for a shorter burst, which would have been preferable to it being pegged at
>> 25% (a single core saturated for a longer period of time).
>>
>> I think it is a reasonable guess that his problem is similar to the one
>> you guys are seeing.  (Of course they could be totally unrelated, so take
>> all this with a grain of salt.)  But assuming that they are similar
>> problems, there are two things to investigate.  First, did something change
>> that is doing something subtly different with process affinity that it
>> wasn't doing before, or is the process affinity thing totally a config
>> issue with one server?  (Or if anybody else is tweaking processor
>> affinities, do you fully understand the implications of it?)  When you are
>> looking at the CPU usage, is the process pegging a single CPU, or is it
>> pegging at some round fraction like 1/4 or 1/8?  The second thing to
>> investigate is, what is happening at the high level that is causing the
>> snapshot data to be so big?  Do network activity spikes correlates with the
>> CPU spikes?  If that is the case, then we can use -netspike  or other tools
>> that you guys are
>>  probably more familiar with than I am to track down what the entity data
>> is that is causing all the busywork.
>>
>> We have very powerful performance analysis tools we can use on Windows to
>> track these problems down.  I only wish more windows server operators users
>> would get setup with them!  Please help us help you!  It's not that
>> difficult to get set up.  Email me directly and I can get you a CD key.
>> https://support.steampowered.com/kb_article.php?ref=3059-RTXB-2672
>>
>> -Original Message-
>> From: hlds_linux-boun...@list.valvesoftware.com [mailto:
>> hlds_linux-boun...@list.valvesoftware.com] On Behalf Of Essay Tew Phaun
>> Sent: Sat

Re: [hlds_linux] Huge sv drops and var spikes in net_graph 4.

[Essay Tew Phaun]

So I've got two demos here. The first one, go to about tick 19000 and wait
to around the point where Fred 2.0 joins. The server drops to 5 frames. I
removed Sourcemod and recorded on another server. I wasn't able to get
those huge drops but there are big var spikes ~10 and it *seems* to happen
as clients join.

http://dropcanvas.com/8itl3/1
http://dropcanvas.com/8itl3/2

I can't think of what else it could be. We haven't changed anything about
the setup from before Steampipe to after.


On Mon, May 6, 2013 at 1:00 PM, Bjorn Wielens  wrote:

>
>
> Thanks for investigating, Fletcher.
>
> I can tell you that in our case, we have an 8 core system with no CPU
> affinity assigned (with 12 TF2 servers running comfortably with CPU to
> spare, srcds generally consumes 30% but can get mid 40s when full of
> players), Watching top, the load is fairly evenly distributed across the
> individual cores, and monitoring resource usage showed only one process
> spiking in usage at a time.
>
>
> For what it's worth, I haven't had the issue recur after disabling replay
> on the servers in question. For me, that would mean the next step is to
> re-enable it and see if the problem returns - I'll post back here when I
> get those results (though it's entirely possible that the additional replay
> overhead is the metaphorical straw on the camel's back) and any additional
> information I uncover.
>
>
>
>
>
> 
>  From: Fletcher Dunn 
> To: Half-Life dedicated Linux server mailing list <
> hlds_linux@list.valvesoftware.com>
> Cc: "Half-Life dedicated Win32 server mailing list (
> h...@list.valvesoftware.com)" 
> Sent: Monday, May 6, 2013 1:41:18 PM
> Subject: Re: [hlds_linux] Huge sv drops and var spikes in net_graph 4.
>
>
> I was able to get a trace from a Windows server operator that was
> experiencing a similar problem.  The problem in that case was that it was
> spending all of its time compressing snapshots.  The problem was
> exacerbated by some process affinity settings which were counterproductive
> and putting all the threads on the same core, while other cores were idle.
>
> Tracking the overall CPU usage can be quite deceiving when investigating
> "lag".  Lower CPU usage is not necessarily better!  For example, in this
> case if the process affinity were not set and more cores were allowed to be
> used, then the CPU usage on this 4-core system would have gone above 25%
> for a shorter burst, which would have been preferable to it being pegged at
> 25% (a single core saturated for a longer period of time).
>
> I think it is a reasonable guess that his problem is similar to the one
> you guys are seeing.  (Of course they could be totally unrelated, so take
> all this with a grain of salt.)  But assuming that they are similar
> problems, there are two things to investigate.  First, did something change
> that is doing something subtly different with process affinity that it
> wasn't doing before, or is the process affinity thing totally a config
> issue with one server?  (Or if anybody else is tweaking processor
> affinities, do you fully understand the implications of it?)  When you are
> looking at the CPU usage, is the process pegging a single CPU, or is it
> pegging at some round fraction like 1/4 or 1/8?  The second thing to
> investigate is, what is happening at the high level that is causing the
> snapshot data to be so big?  Do network activity spikes correlates with the
> CPU spikes?  If that is the case, then we can use -netspike  or other tools
> that you guys are
>  probably more familiar with than I am to track down what the entity data
> is that is causing all the busywork.
>
> We have very powerful performance analysis tools we can use on Windows to
> track these problems down.  I only wish more windows server operators users
> would get setup with them!  Please help us help you!  It's not that
> difficult to get set up.  Email me directly and I can get you a CD key.
> https://support.steampowered.com/kb_article.php?ref=3059-RTXB-2672
>
> -Original Message-
> From: hlds_linux-boun...@list.valvesoftware.com [mailto:
> hlds_linux-boun...@list.valvesoftware.com] On Behalf Of Essay Tew Phaun
> Sent: Saturday, May 04, 2013 11:54 AM
> To: Half-Life dedicated Linux server mailing list
> Subject: Re: [hlds_linux] Huge sv drops and var spikes in net_graph 4.
>
> Hmm. We didn't have this problem before Steampipe though. We just use the
> STV with a couple of slots open on it so that an admin can connect and
> watch for reported players.
>
>
> On Sat, May 4, 2013 at 2:44 PM, ics  wrote:
>
> > STV is known to cause issues and hogs a lot of memory

Re: [hlds_linux] SteamPipe CPU Increase?

[Essay Tew Phaun]

We have that CPU on 24 player servers and get that issue too.


On Sun, May 5, 2013 at 6:53 PM, Abdulrahman Abdulkawi
wrote:

> I have tried to validate and re-installed the servers, unfortunately the
> spikes still happen (not as bad). Strangely enough all the servers spike at
> the same time - has anyone else noticed this same behavior?
>
> Also tried with and without replay, only minor reduction in CPU.
>
> Does anyone have a E3-1230v2 or of similar range (quad) with normal CPU
> usage (32 player count)?
>
> Sent from my iPhone
>
> On 4 May 2013, at 18:07, "DontWannaName!"  wrote:
>
> > I'm seeing some kind of spikes as well on my servers and players notice.
> I'm on windows though.
> >
> > Sent from my iPhone 5
> >
> > On May 4, 2013, at 9:11 AM, Essay Tew Phaun  wrote:
> >
> >> I created another thread but I may as well post here that I too am
> having
> >> sv drops. They're very random and they don't happen a ton but it happens
> >> enough that people complain. See the "huge sv drops and var spikes"
> topic.
> >>
> >>
> >> On Sat, May 4, 2013 at 7:12 AM, Bjorn Wielens 
> wrote:
> >>
> >>> No FTP either, replays are locally hosted. Thanks for the idea though.
> >>>
> >>>
> >>>
> >>> 
> >>> From: ics 
> >>> To: Half-Life dedicated Linux server mailing list <
> >>> hlds_linux@list.valvesoftware.com>
> >>> Sent: Saturday, May 4, 2013 7:44:23 AM
> >>> Subject: Re: [hlds_linux] SteamPipe CPU Increase?
> >>>
> >>>
> >>> Using FTP method of replay is known to cause issues. I've run
> >>> http-method on 4 servers for long time and i've seen no issues with it.
> >>>
> >>> -ics
> >>>
> >>> Mikael Pedersen kirjoitti:
> >>>> On Fri, 3 May 2013 19:19:08 -0700 (PDT), you wrote:
> >>>>
> >>>>> Further update, is anyone else experiencing spikes running Replay? I
> >>> disabled it and it seems to have helped to some extent as it _looks_
> like
> >>> the servers are no longer spiking into the 100% region.
> >>>>
> >>>> I am running a single 24 man TF2 server on an Intel E7200 (Core 2 Duo,
> >>>> 2.53 GHz). Running it on one core only, and it is using 65 to 75% of
> >>>> that core when the server is full. No spikes that I can see. I haven't
> >>>> received any complaints either.
> >>>> Replay is enabled, but both replays and log files are written to a
> >>>> ramdisk. If replays has anything to do with the spikes, maybe that is
> >>>> why I don't see anything.
> >>>>
> >>>> -Mikael
> >>>>
> >>>> ___
> >>>> 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
> >> ___
> >> 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
>
___
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] Huge sv drops and var spikes in net_graph 4.

[Essay Tew Phaun]

Hmm. We didn't have this problem before Steampipe though. We just use the
STV with a couple of slots open on it so that an admin can connect and
watch for reported players.


On Sat, May 4, 2013 at 2:44 PM, ics  wrote:

> STV is known to cause issues and hogs a lot of memory. That's why rarely
> no one uses it on public servers.
>
> -ics
>
> Essay Tew Phaun kirjoitti:
>
>  Interesting. We're not hosting a replay, but we do have STV.
>>
>>
>> On Sat, May 4, 2013 at 12:06 PM, Bjorn Wielens  wrote:
>>
>>  Sounds like the same problem I'm having (see last few posts in 'CPU
>>> Increase' thread).
>>>
>>>
>>>
>>>
>>> __**__
>>>   From: Michael Johansen 
>>> To: Half-Life dedicated Linux server mailing list <
>>> hlds_linux@list.valvesoftware.**com >
>>> Sent: Saturday, May 4, 2013 12:43:59 PM
>>> Subject: Re: [hlds_linux] Huge sv drops and var spikes in net_graph 4.
>>>
>>>
>>> We've noticed this as well, no complaints though as the players does not
>>> seem to notice it very much.
>>>
>>>  Date: Sat, 4 May 2013 11:40:54 -0400
>>>> From: sc2p...@gmail.com
>>>> To: hlds_linux@list.valvesoftware.**com
>>>> Subject: [hlds_linux] Huge sv drops and var spikes in net_graph 4.
>>>>
>>>> We never had this issue prior to Steampipe, but we're dealing with these
>>>> very random and rare spikes of lag where the server framerate will
>>>>
>>> suddenly
>>>
>>>> drop from 66 to below 20 and var will spike to 20+. We're hosting 6 24
>>>>
>>> slot
>>>
>>>> servers on the following:
>>>>
>>>> E3-1230v2
>>>> 16GB
>>>> CentOS 6.4 64bit
>>>>
>>>> I was able to capture a screenshot of one of the drops but they're very
>>>> hard to catch since they appear very very briefly.
>>>>
>>>> http://i.imgur.com/wxp8P3N.png
>>>>
>>>> server.cfg
>>>>
>>>> sv_minrate 35000
>>>> sv_maxrate 20
>>>> sv_maxupdaterate 67
>>>> sv_minupdaterate 66
>>>> sv_mincmdrate 66
>>>> sv_maxcmdrate 67
>>>> sv_client_cmdrate_difference 100
>>>>
>>>>
>>>> Thanks
>>>> __**_
>>>> To unsubscribe, edit your list preferences, or view the list archives,
>>>>
>>> please visit:
>>>
>>>> https://list.valvesoftware.**com/cgi-bin/mailman/listinfo/**hlds_linux<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<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<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<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<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] SteamPipe CPU Increase?

[Essay Tew Phaun]

I created another thread but I may as well post here that I too am having
sv drops. They're very random and they don't happen a ton but it happens
enough that people complain. See the "huge sv drops and var spikes" topic.


On Sat, May 4, 2013 at 7:12 AM, Bjorn Wielens  wrote:

> No FTP either, replays are locally hosted. Thanks for the idea though.
>
>
>
> 
>  From: ics 
> To: Half-Life dedicated Linux server mailing list <
> hlds_linux@list.valvesoftware.com>
> Sent: Saturday, May 4, 2013 7:44:23 AM
> Subject: Re: [hlds_linux] SteamPipe CPU Increase?
>
>
> Using FTP method of replay is known to cause issues. I've run
> http-method on 4 servers for long time and i've seen no issues with it.
>
> -ics
>
> Mikael Pedersen kirjoitti:
> > On Fri, 3 May 2013 19:19:08 -0700 (PDT), you wrote:
> >
> >> Further update, is anyone else experiencing spikes running Replay? I
> disabled it and it seems to have helped to some extent as it _looks_ like
> the servers are no longer spiking into the 100% region.
> >
> > I am running a single 24 man TF2 server on an Intel E7200 (Core 2 Duo,
> > 2.53 GHz). Running it on one core only, and it is using 65 to 75% of
> > that core when the server is full. No spikes that I can see. I haven't
> > received any complaints either.
> > Replay is enabled, but both replays and log files are written to a
> > ramdisk. If replays has anything to do with the spikes, maybe that is
> > why I don't see anything.
> >
> > -Mikael
> >
> > ___
> > 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
>
___
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] Huge sv drops and var spikes in net_graph 4.

[Essay Tew Phaun]

Interesting. We're not hosting a replay, but we do have STV.


On Sat, May 4, 2013 at 12:06 PM, Bjorn Wielens  wrote:

> Sounds like the same problem I'm having (see last few posts in 'CPU
> Increase' thread).
>
>
>
>
> 
>  From: Michael Johansen 
> To: Half-Life dedicated Linux server mailing list <
> hlds_linux@list.valvesoftware.com>
> Sent: Saturday, May 4, 2013 12:43:59 PM
> Subject: Re: [hlds_linux] Huge sv drops and var spikes in net_graph 4.
>
>
> We've noticed this as well, no complaints though as the players does not
> seem to notice it very much.
>
> > Date: Sat, 4 May 2013 11:40:54 -0400
> > From: sc2p...@gmail.com
> > To: hlds_linux@list.valvesoftware.com
> > Subject: [hlds_linux] Huge sv drops and var spikes in net_graph 4.
> >
> > We never had this issue prior to Steampipe, but we're dealing with these
> > very random and rare spikes of lag where the server framerate will
> suddenly
> > drop from 66 to below 20 and var will spike to 20+. We're hosting 6 24
> slot
> > servers on the following:
> >
> > E3-1230v2
> > 16GB
> > CentOS 6.4 64bit
> >
> > I was able to capture a screenshot of one of the drops but they're very
> > hard to catch since they appear very very briefly.
> >
> > http://i.imgur.com/wxp8P3N.png
> >
> > server.cfg
> >
> > sv_minrate 35000
> > sv_maxrate 20
> > sv_maxupdaterate 67
> > sv_minupdaterate 66
> > sv_mincmdrate 66
> > sv_maxcmdrate 67
> > sv_client_cmdrate_difference 100
> >
> >
> > 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
>
___
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] Huge sv drops and var spikes in net_graph 4.

[Essay Tew Phaun]

Ours notice it. I guess they're picky :P


On Sat, May 4, 2013 at 11:43 AM, Michael Johansen  wrote:

> We've noticed this as well, no complaints though as the players does not
> seem to notice it very much.
>
> > Date: Sat, 4 May 2013 11:40:54 -0400
> > From: sc2p...@gmail.com
> > To: hlds_linux@list.valvesoftware.com
> > Subject: [hlds_linux] Huge sv drops and var spikes in net_graph 4.
> >
> > We never had this issue prior to Steampipe, but we're dealing with these
> > very random and rare spikes of lag where the server framerate will
> suddenly
> > drop from 66 to below 20 and var will spike to 20+. We're hosting 6 24
> slot
> > servers on the following:
> >
> > E3-1230v2
> > 16GB
> > CentOS 6.4 64bit
> >
> > I was able to capture a screenshot of one of the drops but they're very
> > hard to catch since they appear very very briefly.
> >
> > http://i.imgur.com/wxp8P3N.png
> >
> > server.cfg
> >
> > sv_minrate 35000
> > sv_maxrate 20
> > sv_maxupdaterate 67
> > sv_minupdaterate 66
> > sv_mincmdrate 66
> > sv_maxcmdrate 67
> > sv_client_cmdrate_difference 100
> >
> >
> > 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

[hlds_linux] Huge sv drops and var spikes in net_graph 4.

[Essay Tew Phaun]

We never had this issue prior to Steampipe, but we're dealing with these
very random and rare spikes of lag where the server framerate will suddenly
drop from 66 to below 20 and var will spike to 20+. We're hosting 6 24 slot
servers on the following:

E3-1230v2
16GB
CentOS 6.4 64bit

I was able to capture a screenshot of one of the drops but they're very
hard to catch since they appear very very briefly.

http://i.imgur.com/wxp8P3N.png

server.cfg

sv_minrate 35000
sv_maxrate 20
sv_maxupdaterate 67
sv_minupdaterate 66
sv_mincmdrate 66
sv_maxcmdrate 67
sv_client_cmdrate_difference 100


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] Valve, can you remove clients required to download nav files?

[Essay Tew Phaun]

They weren't guaranteed to have the navs in the first place, for
unsupported maps. So they could just generate the nav for it.


On Sun, Apr 28, 2013 at 8:40 PM, Saul Rennison wrote:

> What about if they want to host the map on a listen server?
>
>
>
> Kind regards,
> Saul Rennison
>
>
> On 29 April 2013 00:55, Essay Tew Phaun  wrote:
>
> > The option to turn it off would be nice at least. I haven't noticed a
> > difference on the client end from using blank navs.
> >
> >
> > On Sun, Apr 28, 2013 at 7:32 PM, 1nsane <1nsane...@gmail.com> wrote:
> >
> > > The nav files have extra data in certain games like CS:S (place names)
> so
> > > the clients would need those files in order to display that data.
> > >
> > > TF2 might have something similar as well, previously nav files were not
> > > sent in TF2. It happened with some update.
> > >
> > >
> > > On Sat, Apr 27, 2013 at 10:14 PM, Essay Tew Phaun 
> > > wrote:
> > >
> > > > The clients don't need these nav files for the bots to function on
> the
> > > > server. Some servers serve the nav files as empty from a fast
> download
> > to
> > > > get around sending it. This is bad because now the client has a nav
> > file
> > > > that doesn't actually do anything if they chose to play locally.
> > > >
> > > > With all the recent optimizations and separating map downloads from
> > other
> > > > file downloads + SteamPipe, this change makes sense.
> > > >
> > > > 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
> >
> ___
> 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] Valve, can you remove clients required to download nav files?

[Essay Tew Phaun]

The option to turn it off would be nice at least. I haven't noticed a
difference on the client end from using blank navs.


On Sun, Apr 28, 2013 at 7:32 PM, 1nsane <1nsane...@gmail.com> wrote:

> The nav files have extra data in certain games like CS:S (place names) so
> the clients would need those files in order to display that data.
>
> TF2 might have something similar as well, previously nav files were not
> sent in TF2. It happened with some update.
>
>
> On Sat, Apr 27, 2013 at 10:14 PM, Essay Tew Phaun 
> wrote:
>
> > The clients don't need these nav files for the bots to function on the
> > server. Some servers serve the nav files as empty from a fast download to
> > get around sending it. This is bad because now the client has a nav file
> > that doesn't actually do anything if they chose to play locally.
> >
> > With all the recent optimizations and separating map downloads from other
> > file downloads + SteamPipe, this change makes sense.
> >
> > 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

[hlds_linux] Valve, can you remove clients required to download nav files?

[Essay Tew Phaun]

The clients don't need these nav files for the bots to function on the
server. Some servers serve the nav files as empty from a fast download to
get around sending it. This is bad because now the client has a nav file
that doesn't actually do anything if they chose to play locally.

With all the recent optimizations and separating map downloads from other
file downloads + SteamPipe, this change makes sense.

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] Mandatory Team Fortress 2 update released

[Essay Tew Phaun]

Let's be realistic though, if the plugin has been widely used in the
competitive community for such a long time with no action taken by Valve it
would seem to be a little harsh to VAC ban players for it because they
didn't catch the note about it buried in some random update notes.


On Thu, Apr 18, 2013 at 7:39 PM, thesupremecommander <
thesupremec...@gmail.com> wrote:

> Doesn't look like anyone has asked yet, so... can this update be synced to
> the SteamPipe beta?
>
>
> On Thu, Apr 18, 2013 at 7:25 PM, Weasel  wrote:
>
> > Will this mean that with HTML MOTD's we don't have to build a
> > "meta refresh" or such work-around's into the MOTD content to
> > ensure it gets refreshed each time it's opened?
> >
> > 
> >
> > Tony Paloma Thu, 18 Apr 2013 14:13:03 -0700
> >
> > Anyways, the sv_motd_unload_on_dismissal ConVar is about
> > what happens to the MOTD when the user closes it. Before we
> > would just hide it, but the page would still be loaded and taking
> > resources. This gives server operators the option to have it
> > unloaded completely.
> >
> > ___
> > To unsubscribe, edit your list preferences, or view the list archives,
> > please visit:
> > https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
> >
>
>
>
> --
> thesupremecommander (Steam<
> http://steamcommunity.com/id/thesupremecommander>
> )
> Chief Admin, SPUFserver 
> Chief Admin, OverPowered League 
> ___
> 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] Mandatory Team Fortress 2 update released

[Essay Tew Phaun]

Still crying? (This is a rhetorical question BTW.)


On Mon, Apr 15, 2013 at 3:46 AM, dan  wrote:

> On 15/04/2013 08:34, Essay Tew Phaun wrote:
>
>> LOL, there he is, he's back. He won't let it go. It's okay to be wrong
>> Dan,
>> it really is.
>>
>
> I'm not sure what you're harping on about, although I'm not sure that you
> are either.
>
> So I'll respond on face value. Todd asked me a question, I answered it.
>
> I imagine that won't be an unexpected thing to most people, but if it's
> new to you, whoo - exciting stuff eh?
> (This is a rhetorical question BTW. So that means it doesn't actually need
> an answer. It gets quite complicated
> but don't fret, if you get stuck someone will try to help)
>
>
> --
> Dan
>
> __**_
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> https://list.valvesoftware.**com/cgi-bin/mailman/listinfo/**hlds_linux<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] Mandatory Team Fortress 2 update released

[Essay Tew Phaun]

LOL, there he is, he's back. He won't let it go. It's okay to be wrong Dan,
it really is.


On Mon, Apr 15, 2013 at 2:52 AM, dan  wrote:

> On 12/04/2013 23:02, Todd Pettit wrote:
>
>> I suppose Valve has a built in store and creates new hats continuously
>> because they care so dearly for their players too right?
>>
>
> I'm not sure what point you're trying to make, but I'm not sure you are
> either?
>
> So I'll just answer it on face value.
>
> From what Gabe was saying in a talk the other day they don't create
> anything much for TF2 these days because the community are 10x more
> efficient at doing it than they were.
>
> But, yes, they do lots of stuff because they've figured doing this stuff
> makes their customers happy - and this is reflected in their bottom line. I
> think it's clear the focus on customers is reflected in more than just
> purely financial terms too.
>
> By comparison, If EA gave away their games on origin for free, it'd
> probably take a couple of years until anyone said "Well I suppose they are
> not that bad" (until they played a few of the games perhaps)
>
> A modified P. T. Barnum / Lincoln applies of course (as an aside why does
> the internet attribute every quotation to every old American president?)
> you can't please all of the people all of time and so on, but that seems to
> be the essence of what they do, yes.
>
>
> --
> Dan
> __**_
> 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] Mandatory Team Fortress 2 update released

[Essay Tew Phaun]

You won't get a straight answer to your first question because it's
impossible to have one. Instead, he'll wait a few weeks and type up a few
paragraphs that don't even address that very relevant question. "If it was
breaking the rules, why were the servers re-listed?"

It's sad because I don't even think he's trolling, he's just that ignorant.
We removed the plugins because I personally don't like the idea that we may
accidentally have all of our servers de-listed..


On Fri, Apr 12, 2013 at 3:24 PM, 1nsane <1nsane...@gmail.com> wrote:

> How was he correctly de-listed if valve reversed it? It was a bug.
>
> The problem was that valve changed it so the tag doesn't get set
> immediately. Running a plugin like that is fine but you need to monitor the
> tags to make sure they get set.
> No de-listing happened since then and more servers are bringing it back.
>
> You just can not rely on the built in function anymore to avoid de-listing,
> you NEED to make sure the tags are set immediately and you will be OK.
>
> Like valve said, it would be "straying into the grey area" for them to
> de-list such servers and they re-listed the ones they got last time due to
> that bug.
>
>
> On Fri, Apr 12, 2013 at 3:11 PM, dan  wrote:
>
> > On 04/04/2013 06:41, Essay Tew Phaun wrote:
> >
> >> Now can you finally put that other thread to rest and admit you were
> >> wrong?
> >> The servers that didn't have their tags updated were mistakenly
> delisted.
> >> I
> >> don't know how anyone can have a conversation with you if you can't even
> >> read and comprehend what Fletcher point blank said.
> >>
> >
> > You were correctly delisted and the plugin you used that caused the
> > delisting no longer exists on your server.
> >
> > if you're still unsure of that, put the plugin back and see what happens
> > to your servers.
> >
> > As I said, the relevance to this thread is that you squealed like a stuck
> > pig when you were taken to task and now you're suggesting they delist
> > others.
> >
> > If you want good features stop abusing them. You cannot moan about Valve
> > removing features that are abused when you abused them yourself.
> >
> > --
> > Dan.
> >
> >
> >
> > __**_
> > To unsubscribe, edit your list preferences, or view the list archives,
> > please visit:
> > https://list.valvesoftware.**com/cgi-bin/mailman/listinfo/**hlds_linux<
> 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] Mandatory Team Fortress 2 update released

[Essay Tew Phaun]

Uh, I expect for them to clear up a mistake. What's so unreasonable about
that, Dan? That's what the delisting thing was about. They admitted it, go
back and re-read the thread.

This has absolutely nothing to do with that, at all. They know what they're
affecting with this change. My proposition was that instead of removing
something that hurts servers in other ways, you could rely on the report a
server function if advertisements were being abused like that. I mean,
that's certainly more reasonable than just removing features I would think.
It's like cutting off your nose to spite your face.

Now can you finally put that other thread to rest and admit you were wrong?
The servers that didn't have their tags updated were mistakenly delisted. I
don't know how anyone can have a conversation with you if you can't even
read and comprehend what Fletcher point blank said.


On Thu, Apr 4, 2013 at 12:17 AM, dan  wrote:

> On 04/04/2013 00:17, Essay Tew Phaun wrote:
>
>>   What's the report a server feature for, anyway?
>>
>
> You can't expect Valve be tough on others because you weren't willing to
> accept them being tough with you.
>
> Perhaps it's much easier to remove the feature and then you can't use it
> or abuse it. You don't really expect them to trust anyone's judgement or
> take it on face value what the spirit of rules are do you?
>
> Most of all, you can't abuse it and then claim that it's not abuse either
> because the game lets you do it or because there isn't a 150 page bill of
> rights written by lawyers and signed in blood explicitly going over every
> permitted or prohibited thing that one or more of you might dream up next
> to try and get a few bucks by annoying your players in the hope they'll pay
> for you to stop annoying you.
>
> --
> Dan
>
>
> __**_
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> https://list.valvesoftware.**com/cgi-bin/mailman/listinfo/**hlds_linux<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] Mandatory Team Fortress 2 update released

[Essay Tew Phaun]

Eh, I think most players understand that in order to utilize something like
a radio or similar that a web page is opened to provide it. They're
essentially requesting that by typing in a command and sending it.


On Wed, Apr 3, 2013 at 7:26 PM, DontWannaName! wrote:

> I think it's a good idea. Servers have no business opening motd windows on
> clients that do not request them. It makes sense to do it for match made
> players who are usually newer.
>
> Spam: Verb
> Send the same message indiscriminately to (large numbers of recipients) on
> the Internet.
>
> Sent from my iPhone 5
>
> On Apr 3, 2013, at 4:17 PM, Essay Tew Phaun  wrote:
>
> > Similar to the removal of /me. Taking out good features for the actions
> of
> > the malicious. How about you just punish those doing it. What's the
> report
> > a server feature for, anyway?
> >
> >
> > On Wed, Apr 3, 2013 at 7:11 PM, Kyle Sanderson 
> wrote:
> >
> >>> - Prevent game servers from opening the MOTD panel more than once if
> the
> >> player connected through matchmaking or quickplay
> >>
> >> Pathetic.
> >>
> >> Thanks,
> >> Kyle.
> >>
> >>
> >> On Wed, Apr 3, 2013 at 4:08 PM, Eric Smith 
> >> wrote:
> >>
> >>> We've released a mandatory update for Team Fortress 2. The notes for
> the
> >>> update are below.
> >>>
> >>> -Eric
> >>>
> >>> --
> >>>
> >>> Team Fortress 2
> >>> - Prevent game servers from opening the MOTD panel more than once if
> the
> >>> player connected through matchmaking or quickplay
> >>> - Added new promo items
> >>> - Fixed a bug where dispensers sapped by a Red-Tape Recorder would
> >>> continue to heal players
> >>> - Fixed buildings destroyed by the Red-Tape Recorder not always
> >> displaying
> >>> a death notice
> >>> - Fixed a bug in Mann Vs. Machine related to carrying buildings and
> using
> >>> the "Upgrade Buildings" canteen
> >>> - Fixed the guitar sound not always playing when taunting with the Neon
> >>> Annihilator
> >>> - Fixed missing cloak effect for the Wanga Prick
> >>> - Fixed the Bat Outta Hell using the Red team arms skin while on the
> Blue
> >>> team
> >>> - Fixed custom cursors in VR mode
> >>> - Fixed Hydra input in VR mode
> >>> - Improved performance of Linux dedicated server binaries
> >>>
> >>>
> >>>
> >>> ___
> >>> 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
> ___
> 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] Mandatory Team Fortress 2 update released

[Essay Tew Phaun]

Here's one suggestion I have for those of you who may of been impacted by
this. One thing you can do is make any features of your servers that rely
on opening the MOTD a donor only feature, such as radio. I realize this
doesn't cover rules, but it at least means your donors who connect manually
will still have access to these features.


On Wed, Apr 3, 2013 at 7:17 PM, Essay Tew Phaun  wrote:

> Similar to the removal of /me. Taking out good features for the actions of
> the malicious. How about you just punish those doing it. What's the report
> a server feature for, anyway?
>
>
> On Wed, Apr 3, 2013 at 7:11 PM, Kyle Sanderson wrote:
>
>> > - Prevent game servers from opening the MOTD panel more than once if the
>> player connected through matchmaking or quickplay
>>
>> Pathetic.
>>
>> Thanks,
>> Kyle.
>>
>>
>> On Wed, Apr 3, 2013 at 4:08 PM, Eric Smith 
>> wrote:
>>
>> > We've released a mandatory update for Team Fortress 2. The notes for the
>> > update are below.
>> >
>> > -Eric
>> >
>> > --
>> >
>> > Team Fortress 2
>> > - Prevent game servers from opening the MOTD panel more than once if the
>> > player connected through matchmaking or quickplay
>> > - Added new promo items
>> > - Fixed a bug where dispensers sapped by a Red-Tape Recorder would
>> > continue to heal players
>> > - Fixed buildings destroyed by the Red-Tape Recorder not always
>> displaying
>> > a death notice
>> > - Fixed a bug in Mann Vs. Machine related to carrying buildings and
>> using
>> > the "Upgrade Buildings" canteen
>> > - Fixed the guitar sound not always playing when taunting with the Neon
>> > Annihilator
>> > - Fixed missing cloak effect for the Wanga Prick
>> > - Fixed the Bat Outta Hell using the Red team arms skin while on the
>> Blue
>> > team
>> > - Fixed custom cursors in VR mode
>> > - Fixed Hydra input in VR mode
>> > - Improved performance of Linux dedicated server binaries
>> >
>> >
>> >
>> > ___
>> > 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] Mandatory Team Fortress 2 update released

[Essay Tew Phaun]

Similar to the removal of /me. Taking out good features for the actions of
the malicious. How about you just punish those doing it. What's the report
a server feature for, anyway?


On Wed, Apr 3, 2013 at 7:11 PM, Kyle Sanderson  wrote:

> > - Prevent game servers from opening the MOTD panel more than once if the
> player connected through matchmaking or quickplay
>
> Pathetic.
>
> Thanks,
> Kyle.
>
>
> On Wed, Apr 3, 2013 at 4:08 PM, Eric Smith 
> wrote:
>
> > We've released a mandatory update for Team Fortress 2. The notes for the
> > update are below.
> >
> > -Eric
> >
> > --
> >
> > Team Fortress 2
> > - Prevent game servers from opening the MOTD panel more than once if the
> > player connected through matchmaking or quickplay
> > - Added new promo items
> > - Fixed a bug where dispensers sapped by a Red-Tape Recorder would
> > continue to heal players
> > - Fixed buildings destroyed by the Red-Tape Recorder not always
> displaying
> > a death notice
> > - Fixed a bug in Mann Vs. Machine related to carrying buildings and using
> > the "Upgrade Buildings" canteen
> > - Fixed the guitar sound not always playing when taunting with the Neon
> > Annihilator
> > - Fixed missing cloak effect for the Wanga Prick
> > - Fixed the Bat Outta Hell using the Red team arms skin while on the Blue
> > team
> > - Fixed custom cursors in VR mode
> > - Fixed Hydra input in VR mode
> > - Improved performance of Linux dedicated server binaries
> >
> >
> >
> > ___
> > 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] [hlds] Reminder about server tags

[Essay Tew Phaun]

Since when has more than 24 players not been eligible for Quickplay? Also,
when the count goes up the penalty is applied.
1nsane had a good post on this elsewhere about all the other settings that
can be changed while you're on a server that can disqualify it at any time
from Quickplay. Increasing the player count is hardly the worst thing that
can be done to impact the experience of players who've joined from
Quickplay.

On Wed, Mar 6, 2013 at 8:55 PM, Rudy Bleeker  wrote:

> On Thu, Mar 7, 2013 at 2:41 AM, 1nsane <1nsane...@gmail.com> wrote:
> > Do you really think interrupting people by kicking them is the better way
> > of doing reserved slots? Because I don't see how.
>
> How badly can you miss the point? I'll try to explain it one more
> time: if at ANY time during a server's lifetime you plan on changing
> your server settings from less than 24 players with quickplay enabled
> to more than 24 players (and thus not eligible for quickplay) you
> should NOT be eligible for quickplay AT ALL. You're ruining the
> experience of players that came in through quickplay, expecting a
> balanced game with at most 24 players, but who end up in a 32 player
> explosive damage spamfest for which TF2 wasn't designed. The fact that
> the game is 7 years old and computers can now handle 32 players more
> easily is irrelevant, it's about the game experience.
>
> --
> Idleness is not doing nothing. Idleness is being free to do anything.
>   - Floyd Dell
>
> ___
> 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] [hlds] Reminder about server tags

[Essay Tew Phaun]

Nicely put, too hard for some to figure out.

On Wed, Mar 6, 2013 at 6:47 PM, Robert Paulson wrote:

> It seems like people on the internet have issues reading (what a big
> surprise), so I am going to try to keep this as short as possible.
>
> I am repeating myself because I have problems with people in this mailing
> list not even playing TF2 anymore trying to ruin other people's favorite
> settings. And it is funny seeing 24-slot server owners trying anything to
> get their competitors banned. You know who you are.
>
> * 1. Servers were mistakenly banned for a mistake on Valve's part. They
> did
> not know that changing sv_visiblemaxplayers after startup does not set a
> tag. Anyone that changed this setting was banned because Valve thought it
> set a tag but it didn't. This includes unarguably legitimate uses like
> reserved slots. Thus the bans were rightfully removed.
>
> 2. Fletcher himself said "But it’s not ban worthy *and I think it’d be
> *
> *straying into a grey area on our part to take action against it."*
>
> 3. In no first world country has anyone ever been convicted for not
> following the "spirit of the law".
>
> 4. The root of the problem is that quickplay is Valve's backhanded way to
> get the community to accept the "custom tabs" ghetto under the premise that
> quickplay is only for a few noobs. Anyone that actually runs a server can
> tell you that having quickplay will make or break any server close to
> vanilla. Remove the penalty so servers can compete EQUALLY as it should
> have been, or have an opt-in for 24 slots only.
>
> 5. The truth is that larger servers are popular, but quickplay is too much
> of an advantage. Valve has the data to confirm this, and will be doing a
> disservice to themselves by penalizing them at a time when MvM is running
> out of steam to keep TF2 popular. If larger servers were not popular,
> people wouldn't keep joining, and thus it is a self-correcting problem.
>
> Get rid of this quickplay penalty and level the playing field. TF2 was made
> in 2007 computers can handle more than 24 slots now.
>
> 6. The quickplay FAQ says
>
> Are there any server side mods that will disqualify me from Quickplay since
> some do not change sv_tags? No, we are not automatically disqualifying
> servers for server side mods. If the mods results in a better or worse
> player experience, that will be reflected in the back-end server score.
>
> So whatever happened to this? If Valve is banning servers from quickplay
> for changing sv_visiblemaxplayers, then I would request Fletcher to also
> remove the following:
>
> - Reserved slots: Ruins my vanilla experience by getting randomly kicked.
> - Donation benefits: Ruins my vanilla experience when I can't kill donators
> end of round or have autobalance immunity. I already paid Valve and those
> hat modelers, why do server owners have the audacity to ask me for any more
> of my money?
> - Class limits: I don't care if my team has 10 snipers. If I can't play a
> class, it isn't a vanilla experience.
> - Alltalk: I really need to strategize with quickplay noobs, and alltalk
> ruins my vanilla experience.
> - Ability to change maps: As a player, I am entitled to an accurate
> indication that the servers I am sent to only has quickplay maps or that
> the map doesn't switch right after I join.
>
> F*ck these server owners right? Who the do they think they are ruining the
> way I want to play TF2? This is satire if you couldn't tell. All I see here
> is a constant erosion of the rights of server owners. Valve penalizing
> larger servers while letting pay-to-win servers off the hook is a sad
> perversion of priorities.
>
> On Wed, Mar 6, 2013 at 2:01 PM, Rudy Bleeker  wrote:
>
> > I kinda hoped this thread was over, but apparently it's not. In that
> > case let me chip in as well. I also kind of agree with Dan. It's all
> > about the difference between the exact wording of the rules and their
> > intention. Some people on here would do well to read up on that, so
> > for your convenience:
> > http://en.wikipedia.org/wiki/Letter_and_spirit_of_the_law
> >
> > In this case I think it's clear that with the quickplay system Valve
> > intended to give Team Fortress 2 players a predictable and constant
> > game experience. So farming the quickplay system for traffic to your
> > server and then changing that server to something that's not eligible
> > for quickplay is wrong, no matter how the rules were written. I
> > sincerely hope this practice will stop and that the servers in
> > question will be banned (again).
> >
> > On Wed, Mar 6, 2013 at 9:55 PM, Game-Over 
> > wrote:
> > >
> > > I have to say I'm with Dan on this one, and he often seems to stand
> > alone,
> > > so I felt I had to say something.
> > >
> > > Having monitored this group for nearly 2 years, I have come to the
> > > conclusion that it is mostly populated
> > > by youngsters, who have no life experience to speak of. The excuses
> used
> > > here by some that "Valve never

Re: [hlds_linux] [hlds] Reminder about server tags

[Essay Tew Phaun]

Cry about it, Dan. The bans were reversed for a reason. They were going
after servers set as 32 players and not setting the tag at all. Servers
that were changing the visible max players got caught up with it. Right or
wrong as you think it was, it wasn't against the rules because those
settings are freely editable and reflect those changes in the server tags.
Problem is, the tag didn't get updated promptly and some servers were
caught up in that.

Here is what Fletcher had to say on the matter when asked some time back
about it:

Fletcher Dunn

"It’s sort of pushing the boundaries of the “policy of truth” to advertise
a server as 24-players max, when you know full well that you are going to
bump it up to 32.  *It’s definitely not ideal.  But it’s not ban worthy *and
I think it’d be straying into a grey area on our part to take action
against it.



Sounds like we need to adjust our quickplay heuristics, seeing that it
creates this perverse optimal strategy for server operators to get traffic."


So the problem is in the way which Quickplay functions, not the "perverse
optimal strategy".


The door is that way.

On Thu, Feb 21, 2013 at 8:35 AM, Doctor McKay  wrote:

> Dan, this discussion has been over for a while. Valve reversed the bans and
> all's good.
>
> Dr. McKay
>
> On Thursday, February 21, 2013, dan wrote:
>
> > On 19/02/2013 00:10, Invalid Protocol wrote:
> >
> >> I assume that most community servers have few hidden slots reserved for
> >> administrators or regular players. These slots are usually not used,
> >> except
> >> few hours every evening. This means that a 24 public slots + 4 reserved
> >> slots has 24 players most of the time (when is full), and only in rare
> >> cases
> >> it has more players (in very rare cases it may even have 28 players for
> a
> >> short period of time). If you fix the "loophole" then how can we have
> >> reserved slots? Are you going to add a penalty or even delist all
> servers
> >> that have reserved slots?
> >>
> >
> > It's easy really.
> >
> > Figure out the maximum number of people you want to have on your server.
> >
> > Forget whether they are reserved or not. Just add them all together.
> >
> > Right, now you have a number. It might be 12, 24, 32 or something else
> >
> > This is the number your server should report in the server browser.
> >
> > Note, if the number is more than 24 players, this may affect the
> quickplay
> > traffic you do or don't get.
> >
> > --
> > Dan
> >
> > __**_
> > To unsubscribe, edit your list preferences, or view the list archives,
> > please visit:
> > https://list.valvesoftware.**com/cgi-bin/mailman/listinfo/**hlds_linux<
> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux>
> >
>
>
> --
> Sent from Gmail Mobile
> ___
> 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] [hlds] Reminder about server tags

[Essay Tew Phaun]

The choice would still ultimately be up to the player connecting. If it was
a 32 player server it would be communicated to them. My suggestion was to
remove the scoring penalty because a large portion of the TF2 player base
likes 32 player servers.

On Mon, Feb 18, 2013 at 9:06 PM, Gordon Reynolds <
thisisgordonsem...@gmail.com> wrote:

> Please do not speak for the TF2 playerbase as a whole by saying people want
> 32 man servers. For every person you find who gets "bored" with 24 man, or
> doesn't like 24 people, I can find just as many that would suggest that
> line of reasoning is crazy. My entire server/community really enjoys 24 man
> servers, and if we ever found ourselves on a non-vanilla server we would
> melt and wither like ants under a vengeful magnifying glass god.
>
> Same goes for shorter respawn times. Just because you cannot wait your
> 5/10/30 seconds to respawn doesn't mean we need a complete rehaul of a 5+
> year old game's default modes.
>
> This is a really boring debate to have here, but 32 man servers with
> altered respawn times are (in my opinion) pretty terrible ideas. This is
> why we all run different servers though, to play what we want. If you want
> to get "free" traffic however, I don't think it's much of a downside to
> play by the rules set by Valve as the best way to play their game. If
> players really get bored with 24 man servers then eventually they will go
> to the Server List and find someone offering something different.
>
> If they never manage to find the Server List then well, you can only save
> so many souls.
>
>
> On Mon, Feb 18, 2013 at 4:22 PM, Todd Pettit 
> wrote:
>
> > How about banning use of plugins that don't comply and banning servers
> > that use it? I know you can rename them but many admins obviously are
> > completely ignoring this violation.
> >
> > - Original Message -
> > From: "Doctor McKay" 
> > To: "Half-Life dedicated Linux server mailing list" <
> > hlds_linux@list.valvesoftware.com>
> > Sent: Monday, February 18, 2013 6:57:03 PM
> > Subject: Re: [hlds_linux] [hlds] Reminder about server tags
> >
> > Unfortunately, I would imagine that detecting servers that run respawn
> > plugins would be a lot more difficult than detecting servers that don't
> > properly report the increased_maxplayers tag. To detect the former, your
> > have to actually join. To detect the latter, you simply need to query the
> > server's info.
> >
> > In addition it wasn't a bug with the plugin, it was a bug with the server
> > itself. I fired up my local test server with maxplayers 32 and
> > sv_visiblemaxplayers 24. Then I changed sv_visiblemaxplayers to 32 and no
> > tag was added.
> >
> > Dr. McKay
> > http://www.doctormckay.com
> >
> > On Feb 18, 2013, at 6:44 PM, Todd Pettit  wrote:
> >
> > > Fletcher, can you please also do something about all the admins running
> > the fast respawn plugins that they have been getting away with forever
> now?
> > I see so many fast respawn servers without the appropriate tags getting
> > sent quickplay traffic?
> > >
> > > https://forums.alliedmods.net/showthread.php?t=69997&highlight=respawn
> > >
> >
> https://forums.alliedmods.net/showthread.php?t=73929&highlight=fast+respawn
> > >
> > > According to the server counts on sourcemod that is 488 servers
> > circumventing quickplay penalties. It is really quite ridiculous.
> > >
> > >
> > > - Original Message -
> > > From: "Fletcher Dunn" 
> > > To: "Half-Life dedicated Linux server mailing list" <
> > hlds_linux@list.valvesoftware.com>
> > > Sent: Monday, February 18, 2013 6:20:07 PM
> > > Subject: Re: [hlds_linux] [hlds] Reminder about server tags
> > >
> > > We banned some servers who had a maxplayers great than 24 but did not
> > have the increased_maxplayers tag.  It looks like it is possible that
> > changing sv_visiblemaxplayers dynamically can result in this tag not
> being
> > set.  We'll undo those bans.
> > >
> > > If the maxplayers column doesn't inform players, "This server will
> > generally limit the max number of players to X" then what does the value
> > mean?  The only possible way I can imagine a player would interpret the
> > consistent, automated upward adjustment of the maxplayers value is that
> the
> > server is lying to them about what is happening on the server.
> > >
> > > We'll fix this loophole.  Players are entitled to an accurate
> indication
> > of the max number of players allowed on the server.
> > >
> > > -Original Message-
> > > From: hlds_linux-boun...@list.valvesoftware.com [mailto:
> > hlds_linux-boun...@list.valvesoftware.com] On Behalf Of Abdulrahman
> > Abdulkawi
> > > Sent: Monday, February 18, 2013 2:54 PM
> > > To: Half-Life dedicated Linux server mailing list
> > > Subject: Re: [hlds_linux] [hlds] Reminder about server tags
> > >
> > > I just checked my servers and they are actually NOT reporting the
> > increased_maxplayers server tag - I think it may have broke after an
> > update...
> > >
> > >> Date: Mon,

Re: [hlds_linux] [hlds] Reminder about server tags

[Essay Tew Phaun]

Guess you'll have to rely on something like connect/CBaseServer if you'd
want to avoid the scoring penalty :(

On Mon, Feb 18, 2013 at 7:10 PM, Invalid Protocol <
invalidprotocolvers...@gmail.com> wrote:

> I assume that most community servers have few hidden slots reserved for
> administrators or regular players. These slots are usually not used, except
> few hours every evening. This means that a 24 public slots + 4 reserved
> slots has 24 players most of the time (when is full), and only in rare
> cases
> it has more players (in very rare cases it may even have 28 players for a
> short period of time). If you fix the "loophole" then how can we have
> reserved slots? Are you going to add a penalty or even delist all servers
> that have reserved slots?
>
> -Original Message-
> From: hlds_linux-boun...@list.valvesoftware.com
> [mailto:hlds_linux-boun...@list.valvesoftware.com] On Behalf Of Fletcher
> Dunn
> Sent: Tuesday, February 19, 2013 1:20 AM
> To: Half-Life dedicated Linux server mailing list
> Subject: Re: [hlds_linux] [hlds] Reminder about server tags
>
> We banned some servers who had a maxplayers great than 24 but did not have
> the increased_maxplayers tag.  It looks like it is possible that changing
> sv_visiblemaxplayers dynamically can result in this tag not being set.
> We'll undo those bans.
>
> If the maxplayers column doesn't inform players, "This server will
> generally
> limit the max number of players to X" then what does the value mean?  The
> only possible way I can imagine a player would interpret the consistent,
> automated upward adjustment of the maxplayers value is that the server is
> lying to them about what is happening on the server.
>
> We'll fix this loophole.  Players are entitled to an accurate indication of
> the max number of players allowed on the server.
>
> -Original Message-
> From: hlds_linux-boun...@list.valvesoftware.com
> [mailto:hlds_linux-boun...@list.valvesoftware.com] On Behalf Of
> Abdulrahman
> Abdulkawi
> Sent: Monday, February 18, 2013 2:54 PM
> To: Half-Life dedicated Linux server mailing list
> Subject: Re: [hlds_linux] [hlds] Reminder about server tags
>
> I just checked my servers and they are actually NOT reporting the
> increased_maxplayers server tag - I think it may have broke after an
> update...
>
> > Date: Mon, 18 Feb 2013 17:50:24 -0500
> > From: sc2p...@gmail.com
> > To: hlds_linux@list.valvesoftware.com
> > Subject: Re: [hlds_linux] [hlds] Reminder about server tags
> >
> > I've already talked to someone else who has servers delisted for the
> > same reason. There are also a few other communities running some
> > servers that have been delisted. I can't say whether they're for the
> > same tags or not, but we weren't the only ones affected by this.
> >
> > On Mon, Feb 18, 2013 at 5:45 PM, Abdulrahman Abdulkawi
> >  > > wrote:
> >
> > > Well said - I think this does need to be addressed by Valve
> > > otherwise everything is just speculation / assumption.
> > >
> > > Personally, I think the plugin may have glitched or along those
> > > lines and the required tag (increased_maxplayers) was not
> > > automatically added when the slots increased; this is if we're
> > > reading the reason to the letter "server not reporting required
> > > tags"; which if you did have the increased_maxplayers, then you did
> report the required tags.
> > >
> > > I guess if that's a problem, then so will changing any server tag
> mid-game.
> > >
> > > I hope that nobody else does get blacklisted, without any clear
> > > confirmation for whether it is or is not permitted.
> > >
> > > > Date: Mon, 18 Feb 2013 17:20:15 -0500
> > > > From: 1nsane...@gmail.com
> > > > To: hlds_linux@list.valvesoftware.com
> > > > Subject: Re: [hlds_linux] [hlds] Reminder about server tags
> > > >
> > > > Loophole? It's by design and valve knows it. This is an oversight
> > > > which
> > > I'm
> > > > almost entirely convinced they'll fix soon.
> > > >
> > > > Nowhere does it say that once you start your server you can't
> > > > change any settings to be quickplay eligble.
> > > >
> > > > What if a server goes on a map quickplay doesn't support or is
> > > > outside of the chosen range of CP,CTF,whatever of the player
> > > > picked initially. What about servers that let you vote for crits
> > > > or vote for maps? There's
> > > servers
> > > > that enable fast respawn after XX players join.
> > > >
> > > > There's also other changes that quickplay disqualifies for so
> > > > those
> > > servers
> > > > should also be blacklisted when they do it.
> > > > Why? Because it's exactly the same. They make the server quickplay
> > > capable
> > > > initially and then change something that would make it non capable.
> > > >
> > > > In fact actually changing maxplayers is not nearly as bad as those
> > > > other things because quickplay technically supports 32 player
> > > > servers. Just
> > > gives
> > > > them a score penalty. Now filling your server with quickplay and
> > > 

Re: [hlds_linux] [hlds] Reminder about server tags

[Essay Tew Phaun]

I would like to make one final suggestion, though. I think it's apparent by
this point that a large portion of the TF2 community prefers the style of
gameplay that 32 player servers provide. I know it's not exactly balanced
nor in line with what Valve may test with, but It would be nice if that
scoring penalty were removed as the prompt a client gets when joining said
servers should be enough of a penalty. Clearly if they want to join the
server beyond that prompt, that should be enough.
___
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] [hlds] Reminder about server tags

[Essay Tew Phaun]

Understood, we've removed the dynamic slots plugin from all of our servers.

On Mon, Feb 18, 2013 at 6:20 PM, Fletcher Dunn
wrote:

> We banned some servers who had a maxplayers great than 24 but did not have
> the increased_maxplayers tag.  It looks like it is possible that changing
> sv_visiblemaxplayers dynamically can result in this tag not being set.
>  We'll undo those bans.
>
> If the maxplayers column doesn't inform players, "This server will
> generally limit the max number of players to X" then what does the value
> mean?  The only possible way I can imagine a player would interpret the
> consistent, automated upward adjustment of the maxplayers value is that the
> server is lying to them about what is happening on the server.
>
> We'll fix this loophole.  Players are entitled to an accurate indication
> of the max number of players allowed on the server.
>
> -Original Message-
> From: hlds_linux-boun...@list.valvesoftware.com [mailto:
> hlds_linux-boun...@list.valvesoftware.com] On Behalf Of Abdulrahman
> Abdulkawi
> Sent: Monday, February 18, 2013 2:54 PM
> To: Half-Life dedicated Linux server mailing list
> Subject: Re: [hlds_linux] [hlds] Reminder about server tags
>
> I just checked my servers and they are actually NOT reporting the
> increased_maxplayers server tag - I think it may have broke after an
> update...
>
> > Date: Mon, 18 Feb 2013 17:50:24 -0500
> > From: sc2p...@gmail.com
> > To: hlds_linux@list.valvesoftware.com
> > Subject: Re: [hlds_linux] [hlds] Reminder about server tags
> >
> > I've already talked to someone else who has servers delisted for the
> > same reason. There are also a few other communities running some
> > servers that have been delisted. I can't say whether they're for the
> > same tags or not, but we weren't the only ones affected by this.
> >
> > On Mon, Feb 18, 2013 at 5:45 PM, Abdulrahman Abdulkawi
> >  > > wrote:
> >
> > > Well said - I think this does need to be addressed by Valve
> > > otherwise everything is just speculation / assumption.
> > >
> > > Personally, I think the plugin may have glitched or along those
> > > lines and the required tag (increased_maxplayers) was not
> > > automatically added when the slots increased; this is if we're
> > > reading the reason to the letter "server not reporting required
> > > tags"; which if you did have the increased_maxplayers, then you did
> report the required tags.
> > >
> > > I guess if that's a problem, then so will changing any server tag
> mid-game.
> > >
> > > I hope that nobody else does get blacklisted, without any clear
> > > confirmation for whether it is or is not permitted.
> > >
> > > > Date: Mon, 18 Feb 2013 17:20:15 -0500
> > > > From: 1nsane...@gmail.com
> > > > To: hlds_linux@list.valvesoftware.com
> > > > Subject: Re: [hlds_linux] [hlds] Reminder about server tags
> > > >
> > > > Loophole? It's by design and valve knows it. This is an oversight
> > > > which
> > > I'm
> > > > almost entirely convinced they'll fix soon.
> > > >
> > > > Nowhere does it say that once you start your server you can't
> > > > change any settings to be quickplay eligble.
> > > >
> > > > What if a server goes on a map quickplay doesn't support or is
> > > > outside of the chosen range of CP,CTF,whatever of the player
> > > > picked initially. What about servers that let you vote for crits
> > > > or vote for maps? There's
> > > servers
> > > > that enable fast respawn after XX players join.
> > > >
> > > > There's also other changes that quickplay disqualifies for so
> > > > those
> > > servers
> > > > should also be blacklisted when they do it.
> > > > Why? Because it's exactly the same. They make the server quickplay
> > > capable
> > > > initially and then change something that would make it non capable.
> > > >
> > > > In fact actually changing maxplayers is not nearly as bad as those
> > > > other things because quickplay technically supports 32 player
> > > > servers. Just
> > > gives
> > > > them a score penalty. Now filling your server with quickplay and
> > > disabling
> > > > crits or changing maps... Well those things completely disqualify
> > > > a
> > > server
> > > > from quickplay and should clearly be blacklisted as well then.
> > > >
> > > > On Mon, Feb 18, 2013 at 4:56 PM, Ross Bemrose 
> > > wrote:
> > > >
> > > > > Soo... you're abusing a loophole in the quickplay system
> > > > > then
> > > getting
> > > > > upset when your server gets delisted because of it?
> > > > >
> > > > >
> > > > ___
> > > > 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] [hlds] Reminder about server tags

[Essay Tew Phaun]

I've already talked to someone else who has servers delisted for the same
reason. There are also a few other communities running some servers that
have been delisted. I can't say whether they're for the same tags or not,
but we weren't the only ones affected by this.

On Mon, Feb 18, 2013 at 5:45 PM, Abdulrahman Abdulkawi  wrote:

> Well said - I think this does need to be addressed by Valve otherwise
> everything is just speculation / assumption.
>
> Personally, I think the plugin may have glitched or along those lines and
> the required tag (increased_maxplayers) was not automatically added when
> the slots increased; this is if we're reading the reason to the letter
> "server not reporting required tags"; which if you did have the
> increased_maxplayers, then you did report the required tags.
>
> I guess if that's a problem, then so will changing any server tag mid-game.
>
> I hope that nobody else does get blacklisted, without any clear
> confirmation for whether it is or is not permitted.
>
> > Date: Mon, 18 Feb 2013 17:20:15 -0500
> > From: 1nsane...@gmail.com
> > To: hlds_linux@list.valvesoftware.com
> > Subject: Re: [hlds_linux] [hlds] Reminder about server tags
> >
> > Loophole? It's by design and valve knows it. This is an oversight which
> I'm
> > almost entirely convinced they'll fix soon.
> >
> > Nowhere does it say that once you start your server you can't change any
> > settings to be quickplay eligble.
> >
> > What if a server goes on a map quickplay doesn't support or is outside of
> > the chosen range of CP,CTF,whatever of the player picked initially. What
> > about servers that let you vote for crits or vote for maps? There's
> servers
> > that enable fast respawn after XX players join.
> >
> > There's also other changes that quickplay disqualifies for so those
> servers
> > should also be blacklisted when they do it.
> > Why? Because it's exactly the same. They make the server quickplay
> capable
> > initially and then change something that would make it non capable.
> >
> > In fact actually changing maxplayers is not nearly as bad as those other
> > things because quickplay technically supports 32 player servers. Just
> gives
> > them a score penalty. Now filling your server with quickplay and
> disabling
> > crits or changing maps... Well those things completely disqualify a
> server
> > from quickplay and should clearly be blacklisted as well then.
> >
> > On Mon, Feb 18, 2013 at 4:56 PM, Ross Bemrose 
> wrote:
> >
> > > Soo... you're abusing a loophole in the quickplay system then
> getting
> > > upset when your server gets delisted because of it?
> > >
> > >
> > ___
> > 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] [hlds] Reminder about server tags

[Essay Tew Phaun]

Excellent points that I actually didn't even consider. I'll say it again,
if Valve *really* doesn't want servers doing this than they need not do
more than simply say so. I know some server owners would perhaps tempt fate
but it would have taken us all of 2 minutes to remove the plugins from the
servers. There just isn't much to go off of here and flat out delisting
servers without communicating these things very well just doesn't feel
right to me, so I'm still standing by my thoughts that this is a mistake on
their part. Either way it winds up going, I'll be sure to provide the
answer here if Valve only responds to me privately. I think other server
owners should know the reason so that they don't risk being delisted.

On Mon, Feb 18, 2013 at 5:20 PM, 1nsane <1nsane...@gmail.com> wrote:

> Loophole? It's by design and valve knows it. This is an oversight which I'm
> almost entirely convinced they'll fix soon.
>
> Nowhere does it say that once you start your server you can't change any
> settings to be quickplay eligble.
>
> What if a server goes on a map quickplay doesn't support or is outside of
> the chosen range of CP,CTF,whatever of the player picked initially. What
> about servers that let you vote for crits or vote for maps? There's servers
> that enable fast respawn after XX players join.
>
> There's also other changes that quickplay disqualifies for so those servers
> should also be blacklisted when they do it.
> Why? Because it's exactly the same. They make the server quickplay capable
> initially and then change something that would make it non capable.
>
> In fact actually changing maxplayers is not nearly as bad as those other
> things because quickplay technically supports 32 player servers. Just gives
> them a score penalty. Now filling your server with quickplay and disabling
> crits or changing maps... Well those things completely disqualify a server
> from quickplay and should clearly be blacklisted as well then.
>
> On Mon, Feb 18, 2013 at 4:56 PM, Ross Bemrose  wrote:
>
> > Soo... you're abusing a loophole in the quickplay system then getting
> > upset when your server gets delisted because of it?
> >
> >
> ___
> 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] [hlds] Reminder about server tags

[Essay Tew Phaun]

Right, but where is it expressed that it's against the rules? When it's
above 24 players it's advertised with the proper tag. I definitely don't
see it as any worse than joining some RTD server within the Quickplay pool.
Most of all, had Valve simply said "Don't do this". We would of removed it.
It's not that big of a deal to remove it really, had I thought they were
ever going to delist servers for it.

I'm still having trouble figuring out how this could be intended, because
there are a bunch of servers listed right now that are breaking this "rule".

On Mon, Feb 18, 2013 at 4:30 PM, Gordon Reynolds <
thisisgordonsem...@gmail.com> wrote:

> "The *only* reason we were doing it was to avoid the initial hit to our
> quickplay score. The intention isn't to trick players, though I can see how
> one may think that was the intention."
>
> Yeah that's the problem right here, nobody believes it was your intention
> to do wrong, but you ARE hosting a 32 man server, and then trying to still
> score on the no-penalty quickplay traffic until you get more than 24
> players. That's using the system to get more players into your server than
> you'd normally get otherwise - because they might think they are here for a
> good ol' 12 on 12 action. Not a 12 on 12 until more show up kind of game.
>
>
> On Mon, Feb 18, 2013 at 1:01 PM, Essay Tew Phaun 
> wrote:
>
> > It's pretty simple to me, let server owners know it's a violation of the
> > policy and most will remove it. I've removed it from all of the servers.
> > The *only* reason we were doing it was to avoid the initial hit to our
> > quickplay score. The intention isn't to trick players, though I can see
> how
> > one may think that was the intention. My problem is that the subject has
> > been brought up a few times and we've never gotten a direct answer on it
> > and by definition, it does not break the policy. The server is advertised
> > properly by the tag when the server goes beyond 24 players. We don't set
> > tags anywhere because we don't need to, when you enable/disable features
> > the server usually handles that for you. It seems really strange to me
> that
> > you would automatically delist a server like that without answering the
> > question about whether this is a violation or not and without making it
> so
> > when servers go above 24 players the tag is changed immediately.
> >
> > I don't like the idea that we're not breaking the rules the way they
> > currently exist yet we've had a server delisted. I don't like the idea
> that
> > we were never given a direct answer yet we had a server delisted. I also
> > see tons of servers right now running 32 players without the tag. It is
> > very very very bothersome that I've reported servers in the past who were
> > grossly breaking the policy of truth rules and it took them months to get
> > delisted, yet one of our servers is now breaking a rule that was never
> > clarified as breaking a rule? I have big problems with that, because I
> > would have not had a problem removing the dynamic slot changer had this
> > been expressed as a violation by Valve. The tag is changed when the
> player
> > counts rise but because it's not done immediately (Don't ask me why this
> > is) a lot of servers were blacklisted for those few moments where the tag
> > doesn't exist?
> >
> > I really believe this has to be a mistake, because there are a bunch of
> > servers right now as I type this that are breaking tag rules and are not
> > delisted. It's not enough that we have to work as a community as hard as
> we
> > do to keep our servers full on a daily basis with client crashes and
> server
> > crashes, now we've got a server delisted that really doesn't break any
> > rules.
> >
> > On Mon, Feb 18, 2013 at 2:51 PM, HyperionGaming.org Admin <
> > ad...@hyperiongaming.org> wrote:
> >
> > > Exactly. Valve never talked about the dynamicslots plugin as a
> violation
> > > before. If the plugin is now considered as "cheating" and can get
> servers
> > > blacklisted, then it's quite simple: don't use it. Right now, we still
> > > don't know if that's the reason his server was delisted. Hopefully,
> > someone
> > > from Valve will clear up the issue either here or privately. And if
> they
> > > do, please let us know the verdict.
> > >
> > > Question: If you start the server with 32 slots, use the dynamicslots
> > > plug

Re: [hlds_linux] [hlds] Reminder about server tags

[Essay Tew Phaun]

delisted, but you DO run a 32 man server, and
> advertise
> > > it as a 24 man server. You do correctly change the tags once you near
> 24,
> > > but it is false advertisement. If I'm looking for a vanilla 24 man
> > server,
> > > end up on your server, and then 10 minutes later I notice there are 32
> > > people, I'm going to be a little miffed.
> > >
> > > This isn't breaking the letter of the policy but it might be treading
> > along
> > > the "spirit" of it. Just keep the increased_maxplayers tag on at all
> > times,
> > > because you -are- running a 32 man server.
> > >
> > >
> > > On Mon, Feb 18, 2013 at 9:59 AM, StevoTVR 
> wrote:
> > >
> > > > It does sound like a violation of the policy's intent. What is the
> > > > difference between a 32 slot server and one that allows people to
> join
> > > > until there are 32 players? I think people would expect the displayed
> > > > player limit to stay the same during the session. The only reason I
> can
> > > > think of for why you do that is to make your server appear to be
> > > something
> > > > that it isn't.
> > > >
> > > >
> > > > On 2/18/2013 8:06 AM, Essay Tew Phaun wrote:
> > > >
> > > >> It doesn't violate it. Whether it's "ideal" to do so is another
> thing
> > > >> entirely. The tag is dependent upon sv_visiblemaxplayers which can
> be
> > > >> changed at any time. If you're going to have some automated system
> > going
> > > >> around delisting servers then you should at least make sure the
> > features
> > > >> enabled/disabled set the flags *immediately*. Other features set
> those
> > > >> flags immediately, such as bots. In my opinion, they should have
> > linked
> > > >> "increased_maxplayers" to maxplayers and not sv_visiblemaxplayers.
> > Then
> > > if
> > > >> you want to lower the visible players you can set
> sv_visiblemaxplayers
> > > to
> > > >> something lower than 32 and remove the increased_maxplayers tag. It
> > > >> shouldn't work in the opposite way, especially if they're going to
> > > delist
> > > >> servers for it.
> > > >>
> > > >> TL;DR: It doesn't violate any policy the way it currently works.
> When
> > > >> sv_visiblemaxplayers is changed, the tag "increased_maxplayers" is
> > > added.
> > > >> The problem is that it isn't changed immediately and if my guess is
> > > >> correct, their automated tag checker has delisted some servers that
> > > didn't
> > > >> have this tag set at the time of the check.
> > > >>
> > > >> On Mon, Feb 18, 2013 at 10:34 AM, dan 
> wrote:
> > > >>
> > > >>  On 17/02/2013 21:32, Essay Tew Phaun wrote:
> > > >>>
> > > >>>  The servers are all started as 32 player servers,
> > sv_visiblemaxplayers
> > > >>>> is
> > > >>>> set to 24 players. Once 23 players join the sv_visiblemaxplayers
> is
> > > set
> > > >>>> to
> > > >>>> 32 players. The tag "increased_maxplayers" is then applied. This
> > > isn't a
> > > >>>> violation of the tag rules, which is what it's showing we were
> > > delisted
> > > >>>> for.
> > > >>>>
> > > >>>>  Why do you change sv_visiblemaxplayers?
> > > >>>
> > > >>> I think, without some overwhelming answer to the above question
> > > >>> what you do definitely violates increased_maxplayers.
> > > >>>
> > > >>> You have to think from the point of view of someone joining the
> > server
> > > >>> thinking it's a 24 slot server
> > > >>> or someone using the tags to filter out servers with
> > > >>> increased_maxplayers.
> > > >>>
> > > >>> Even if strictly in the pedantic sense the tags are correct before
> > and
> > > >>> after
> > > >>> you make the change, clearly in the intent of those tags you are
> > > breaking
> > > >>> the rules imo.
> > > >>>
> > > >>> -

Re: [hlds_linux] [hlds] Reminder about server tags

[Essay Tew Phaun]

It doesn't violate it. Whether it's "ideal" to do so is another thing
entirely. The tag is dependent upon sv_visiblemaxplayers which can be
changed at any time. If you're going to have some automated system going
around delisting servers then you should at least make sure the features
enabled/disabled set the flags *immediately*. Other features set those
flags immediately, such as bots. In my opinion, they should have linked
"increased_maxplayers" to maxplayers and not sv_visiblemaxplayers. Then if
you want to lower the visible players you can set sv_visiblemaxplayers to
something lower than 32 and remove the increased_maxplayers tag. It
shouldn't work in the opposite way, especially if they're going to delist
servers for it.

TL;DR: It doesn't violate any policy the way it currently works. When
sv_visiblemaxplayers is changed, the tag "increased_maxplayers" is added.
The problem is that it isn't changed immediately and if my guess is
correct, their automated tag checker has delisted some servers that didn't
have this tag set at the time of the check.

On Mon, Feb 18, 2013 at 10:34 AM, dan  wrote:

> On 17/02/2013 21:32, Essay Tew Phaun wrote:
>
>> The servers are all started as 32 player servers, sv_visiblemaxplayers is
>> set to 24 players. Once 23 players join the sv_visiblemaxplayers is set to
>> 32 players. The tag "increased_maxplayers" is then applied. This isn't a
>> violation of the tag rules, which is what it's showing we were delisted
>> for.
>>
>
> Why do you change sv_visiblemaxplayers?
>
> I think, without some overwhelming answer to the above question
> what you do definitely violates increased_maxplayers.
>
> You have to think from the point of view of someone joining the server
> thinking it's a 24 slot server
> or someone using the tags to filter out servers with increased_maxplayers.
>
> Even if strictly in the pedantic sense the tags are correct before and
> after
> you make the change, clearly in the intent of those tags you are breaking
> the rules imo.
>
> --
> Dan.
>
>
> __**_
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> https://list.valvesoftware.**com/cgi-bin/mailman/listinfo/**hlds_linux<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] [hlds] Reminder about server tags

[Essay Tew Phaun]

Yeah I wouldn't think so either. We don't change anything else that could
cause it. Our server.cfg has nothing that would disqualify us from
Quickplay and we run nothing but Quickplay eligible maps. We don't set any
tags manually. The only plugins we have that set tags themselves are
SourcemodDJ and GameME. Every other tag is controlled by srcds itself. I'm
thankful I even thought to go check this. I normally wouldn't of thought to
because we're in compliance with the tag policies and Quickplay policies.
Our server was low on the players for the past day or two and it didn't
make any sense. So I went to check it and then there it was, blacklisted.



On Sun, Feb 17, 2013 at 5:08 PM, 1nsane <1nsane...@gmail.com> wrote:

> That shouldn't be the reason for why you got de-listed. At least I hope
> not.
>
> You are using functions built in to the game by valve and those functions
> are what control tags.
>
> Perhaps you had some other tag missing or it's just an error on valve's
> part.
>
>
> On Sun, Feb 17, 2013 at 4:32 PM, Essay Tew Phaun 
> wrote:
>
> > The servers are all started as 32 player servers, sv_visiblemaxplayers is
> > set to 24 players. Once 23 players join the sv_visiblemaxplayers is set
> to
> > 32 players. The tag "increased_maxplayers" is then applied. This isn't a
> > violation of the tag rules, which is what it's showing we were delisted
> > for.
> >
> > On Sun, Feb 17, 2013 at 4:27 PM, Ross Bemrose 
> wrote:
> >
> > > "When the server is above 24 players" ?
> > >
> > > Doesn't that deserve some sort of explanation?  Like, as in how are you
> > > adjusting the player count?
> > >
> > >
> > > On 2/17/2013 4:21 PM, Essay Tew Phaun wrote:
> > >
> > >> fwiw, I haven't appealed to neither Todd nor McKay to make these
> posts.
> > >> McKay has developed several of the plugins for our community and has
> > >> access
> > >> to our systems. I would hope it counts for something that a SourceMod
> > >> plugin approver is vouching for us. I really am at a loss for why this
> > >> delisting could have happened. We don't manually set tags anywhere and
> > we
> > >> don't attempt to remove tags. The server that got delisted runs pretty
> > >> much
> > >> vanilla. No modified respawn times, when bots are online they are
> > >> reflected
> > >> in the auto-added "bots" tag. When the server is above 24 players it
> is
> > >> reflected in "increased_maxplayers". I have emailed Tony, Eric,
> Fletcher
> > >> and Mike attempting to get an answer about this and will update the
> > thread
> > >> when I receive the answer, in case we're somehow breaking a rule, but
> I
> > >> have no earthly idea what that rule could be. This delisting seems to
> > have
> > >> happened shortly after this post.
> > >>
> > >> Here are the tags the currently delisted server has, which are the
> same
> > >> ones it would have had before the delisting:
> > >>
> > >> "sv_tags" = "SMDJ,_registered,bots,ctf,**gameME,replays"
> > >>
> > >>
> > >>
> > >> On Sun, Feb 17, 2013 at 4:14 PM, Todd Pettit 
> > >> wrote:
> > >>
> > >>  I agree I have a good relationship with their community and the
> > >>> definitely
> > >>> obey all of valve's rules.
> > >>>
> > >>> - Original Message -
> > >>> From: "Doctor McKay" 
> > >>> To: "Half-Life dedicated Linux server mailing list" <
> > >>> hlds_linux@list.valvesoftware.**com <
> hlds_linux@list.valvesoftware.com
> > >>
> > >>> Sent: Sunday, February 17, 2013 3:51:26 PM
> > >>> Subject: Re: [hlds_linux] [hlds] Reminder about server tags
> > >>>
> > >>> I can vouch for him in that he's not breaking any rules.
> > >>>
> > >>> Dr. McKay
> > >>> http://www.doctormckay.com
> > >>>
> > >>> -Original Message-
> > >>> From: Essay Tew Phaun
> > >>> Sent: Sunday, February 17, 2013 3:15 PM
> > >>> To: Half-Life dedicated Linux server mailing list
> > >>> Subject: Re: [hlds_linux] [hlds] Reminder about server tags
> > >>>
> > >>> Just wanted to say 

Re: [hlds_linux] [hlds] Reminder about server tags

[Essay Tew Phaun]

I've mailed them privately, but there's no reason why I can't bring this to
the attention of other server owners and then provide the resulting answer
here as well.

On Sun, Feb 17, 2013 at 4:48 PM, Tim Bagheri  wrote:

> Maybe an issue for you and Valve to discuss in private?
>
> On Mon, Feb 18, 2013 at 8:32 AM, Essay Tew Phaun 
> wrote:
>
> > The servers are all started as 32 player servers, sv_visiblemaxplayers is
> > set to 24 players. Once 23 players join the sv_visiblemaxplayers is set
> to
> > 32 players. The tag "increased_maxplayers" is then applied. This isn't a
> > violation of the tag rules, which is what it's showing we were delisted
> > for.
> >
> > On Sun, Feb 17, 2013 at 4:27 PM, Ross Bemrose 
> wrote:
> >
> > > "When the server is above 24 players" ?
> > >
> > > Doesn't that deserve some sort of explanation?  Like, as in how are you
> > > adjusting the player count?
> > >
> > >
> > > On 2/17/2013 4:21 PM, Essay Tew Phaun wrote:
> > >
> > >> fwiw, I haven't appealed to neither Todd nor McKay to make these
> posts.
> > >> McKay has developed several of the plugins for our community and has
> > >> access
> > >> to our systems. I would hope it counts for something that a SourceMod
> > >> plugin approver is vouching for us. I really am at a loss for why this
> > >> delisting could have happened. We don't manually set tags anywhere and
> > we
> > >> don't attempt to remove tags. The server that got delisted runs pretty
> > >> much
> > >> vanilla. No modified respawn times, when bots are online they are
> > >> reflected
> > >> in the auto-added "bots" tag. When the server is above 24 players it
> is
> > >> reflected in "increased_maxplayers". I have emailed Tony, Eric,
> Fletcher
> > >> and Mike attempting to get an answer about this and will update the
> > thread
> > >> when I receive the answer, in case we're somehow breaking a rule, but
> I
> > >> have no earthly idea what that rule could be. This delisting seems to
> > have
> > >> happened shortly after this post.
> > >>
> > >> Here are the tags the currently delisted server has, which are the
> same
> > >> ones it would have had before the delisting:
> > >>
> > >> "sv_tags" = "SMDJ,_registered,bots,ctf,**gameME,replays"
> > >>
> > >>
> > >>
> > >> On Sun, Feb 17, 2013 at 4:14 PM, Todd Pettit 
> > >> wrote:
> > >>
> > >>  I agree I have a good relationship with their community and the
> > >>> definitely
> > >>> obey all of valve's rules.
> > >>>
> > >>> - Original Message -
> > >>> From: "Doctor McKay" 
> > >>> To: "Half-Life dedicated Linux server mailing list" <
> > >>> hlds_linux@list.valvesoftware.**com <
> hlds_linux@list.valvesoftware.com
> > >>
> > >>> Sent: Sunday, February 17, 2013 3:51:26 PM
> > >>> Subject: Re: [hlds_linux] [hlds] Reminder about server tags
> > >>>
> > >>> I can vouch for him in that he's not breaking any rules.
> > >>>
> > >>> Dr. McKay
> > >>> http://www.doctormckay.com
> > >>>
> > >>> -Original Message-
> > >>> From: Essay Tew Phaun
> > >>> Sent: Sunday, February 17, 2013 3:15 PM
> > >>> To: Half-Life dedicated Linux server mailing list
> > >>> Subject: Re: [hlds_linux] [hlds] Reminder about server tags
> > >>>
> > >>> Just wanted to say that we've had a server blacklisted for the
> reason:
> > >>>
> > >>> 
> > >>> Server browser not reporting required tags (e.g.
> increased_maxplayers,
> > >>> bots, etc)
> > >>> 
> > >>>
> > >>> And we've always obeyed the tag rules. We don't use any plugins that
> > aim
> > >>> to
> > >>> remove them and any features we use, such as bots and
> > >>> increased_maxplayers
> > >>> automatically change the sv_tags and we've made no attempts at all to
> > >>> remove them. This has to be a mistake on Valves part, the server of
> > ours
> > >>> which 

Re: [hlds_linux] [hlds] Reminder about server tags

[Essay Tew Phaun]

The servers are all started as 32 player servers, sv_visiblemaxplayers is
set to 24 players. Once 23 players join the sv_visiblemaxplayers is set to
32 players. The tag "increased_maxplayers" is then applied. This isn't a
violation of the tag rules, which is what it's showing we were delisted for.

On Sun, Feb 17, 2013 at 4:27 PM, Ross Bemrose  wrote:

> "When the server is above 24 players" ?
>
> Doesn't that deserve some sort of explanation?  Like, as in how are you
> adjusting the player count?
>
>
> On 2/17/2013 4:21 PM, Essay Tew Phaun wrote:
>
>> fwiw, I haven't appealed to neither Todd nor McKay to make these posts.
>> McKay has developed several of the plugins for our community and has
>> access
>> to our systems. I would hope it counts for something that a SourceMod
>> plugin approver is vouching for us. I really am at a loss for why this
>> delisting could have happened. We don't manually set tags anywhere and we
>> don't attempt to remove tags. The server that got delisted runs pretty
>> much
>> vanilla. No modified respawn times, when bots are online they are
>> reflected
>> in the auto-added "bots" tag. When the server is above 24 players it is
>> reflected in "increased_maxplayers". I have emailed Tony, Eric, Fletcher
>> and Mike attempting to get an answer about this and will update the thread
>> when I receive the answer, in case we're somehow breaking a rule, but I
>> have no earthly idea what that rule could be. This delisting seems to have
>> happened shortly after this post.
>>
>> Here are the tags the currently delisted server has, which are the same
>> ones it would have had before the delisting:
>>
>> "sv_tags" = "SMDJ,_registered,bots,ctf,**gameME,replays"
>>
>>
>>
>> On Sun, Feb 17, 2013 at 4:14 PM, Todd Pettit 
>> wrote:
>>
>>  I agree I have a good relationship with their community and the
>>> definitely
>>> obey all of valve's rules.
>>>
>>> - Original Message -
>>> From: "Doctor McKay" 
>>> To: "Half-Life dedicated Linux server mailing list" <
>>> hlds_linux@list.valvesoftware.**com >
>>> Sent: Sunday, February 17, 2013 3:51:26 PM
>>> Subject: Re: [hlds_linux] [hlds] Reminder about server tags
>>>
>>> I can vouch for him in that he's not breaking any rules.
>>>
>>> Dr. McKay
>>> http://www.doctormckay.com
>>>
>>> -Original Message-
>>> From: Essay Tew Phaun
>>> Sent: Sunday, February 17, 2013 3:15 PM
>>> To: Half-Life dedicated Linux server mailing list
>>> Subject: Re: [hlds_linux] [hlds] Reminder about server tags
>>>
>>> Just wanted to say that we've had a server blacklisted for the reason:
>>>
>>> 
>>> Server browser not reporting required tags (e.g. increased_maxplayers,
>>> bots, etc)
>>> 
>>>
>>> And we've always obeyed the tag rules. We don't use any plugins that aim
>>> to
>>> remove them and any features we use, such as bots and
>>> increased_maxplayers
>>> automatically change the sv_tags and we've made no attempts at all to
>>> remove them. This has to be a mistake on Valves part, the server of ours
>>> which got blacklisted runs the exact same way our other servers run and
>>> they're not blacklisted.
>>>
>>> On Fri, Feb 15, 2013 at 6:52 AM, Robert Paulson
>>> wrote:
>>>
>>>  You can see the number of players on the stats page. TF2 is always in
>>>>> the
>>>>>
>>>> top 3 or 4 games.
>>>> It's 2nd right now.
>>>>
>>>> Sure look at the games list during the least active part of the day when
>>>> many of those players are idling in the only game with a huge incentive
>>>>
>>> to
>>>
>>>> idle. Try looking at the list during peak hours. The number of TF2
>>>>
>>> players
>>>
>>>> have stagnated and even dropped after 2 huge updates.
>>>>
>>>>  There are or were big long threads on SPUF moaning about how badly TF2
>>>>> is
>>>>>
>>>> optimised and moaning about how sentry guns should be removed or such
>>>> and
>>>> such are overpowered
>>>>
>>>> There's always people complaining about anything. Again, I encourage
>>>> Fletcher to look at the ev

Re: [hlds_linux] [hlds] Reminder about server tags

[Essay Tew Phaun]

fwiw, I haven't appealed to neither Todd nor McKay to make these posts.
McKay has developed several of the plugins for our community and has access
to our systems. I would hope it counts for something that a SourceMod
plugin approver is vouching for us. I really am at a loss for why this
delisting could have happened. We don't manually set tags anywhere and we
don't attempt to remove tags. The server that got delisted runs pretty much
vanilla. No modified respawn times, when bots are online they are reflected
in the auto-added "bots" tag. When the server is above 24 players it is
reflected in "increased_maxplayers". I have emailed Tony, Eric, Fletcher
and Mike attempting to get an answer about this and will update the thread
when I receive the answer, in case we're somehow breaking a rule, but I
have no earthly idea what that rule could be. This delisting seems to have
happened shortly after this post.

Here are the tags the currently delisted server has, which are the same
ones it would have had before the delisting:

"sv_tags" = "SMDJ,_registered,bots,ctf,gameME,replays"



On Sun, Feb 17, 2013 at 4:14 PM, Todd Pettit  wrote:

> I agree I have a good relationship with their community and the definitely
> obey all of valve's rules.
>
> - Original Message -
> From: "Doctor McKay" 
> To: "Half-Life dedicated Linux server mailing list" <
> hlds_linux@list.valvesoftware.com>
> Sent: Sunday, February 17, 2013 3:51:26 PM
> Subject: Re: [hlds_linux] [hlds] Reminder about server tags
>
> I can vouch for him in that he's not breaking any rules.
>
> Dr. McKay
> http://www.doctormckay.com
>
> -Original Message-
> From: Essay Tew Phaun
> Sent: Sunday, February 17, 2013 3:15 PM
> To: Half-Life dedicated Linux server mailing list
> Subject: Re: [hlds_linux] [hlds] Reminder about server tags
>
> Just wanted to say that we've had a server blacklisted for the reason:
>
> 
> Server browser not reporting required tags (e.g. increased_maxplayers,
> bots, etc)
> 
>
> And we've always obeyed the tag rules. We don't use any plugins that aim to
> remove them and any features we use, such as bots and increased_maxplayers
> automatically change the sv_tags and we've made no attempts at all to
> remove them. This has to be a mistake on Valves part, the server of ours
> which got blacklisted runs the exact same way our other servers run and
> they're not blacklisted.
>
> On Fri, Feb 15, 2013 at 6:52 AM, Robert Paulson
> wrote:
>
> > > You can see the number of players on the stats page. TF2 is always in
> > > the
> > top 3 or 4 games.
> > It's 2nd right now.
> >
> > Sure look at the games list during the least active part of the day when
> > many of those players are idling in the only game with a huge incentive
> to
> > idle. Try looking at the list during peak hours. The number of TF2
> players
> > have stagnated and even dropped after 2 huge updates.
> >
> > > There are or were big long threads on SPUF moaning about how badly TF2
> > > is
> > optimised and moaning about how sentry guns should be removed or such and
> > such are overpowered
> >
> > There's always people complaining about anything. Again, I encourage
> > Fletcher to look at the evidence that people join fast respawn servers
> > with
> > hidden tags by the boat-load, and stay there all night. And they don't do
> > it when tags are listed. This should tell you 2 things: there's a real
> > demand for faster respawn, and not being on quickplay is a huge
> > disadvntage. Again, I don't care
> >
> > > The server software is free so I'm not sure what you bought. Was it
> some
> > magic beans in exchange for a cow? :)
> >
> > I don't know about you but I purchased TF2 with the expectation that
> > servers would be moddable like previous Source games AND not be relegated
> > to a ghetto deprived of new players. You really think people run modded
> > servers without buying the game? There is no formal contract saying that
> > server owners have any rights, but there is an unspoken one. And it is up
> > to Valve how much they want to erode this good will so that future games
> > don't end up like CS:GO.
> >
> > Anyone that has been looking at TF2 servers now knows that you are out of
> > touch with what is happening right now. No one is using fake players on a
> > large scale anymore. Of course you wouldn't know given your 1 hour of TF2
> > per week.
> >
> > This will be my final response to you on this matter. Don

Re: [hlds_linux] [hlds] Reminder about server tags

[Essay Tew Phaun]

Just wanted to say that we've had a server blacklisted for the reason:


Server browser not reporting required tags (e.g. increased_maxplayers,
bots, etc)


And we've always obeyed the tag rules. We don't use any plugins that aim to
remove them and any features we use, such as bots and increased_maxplayers
automatically change the sv_tags and we've made no attempts at all to
remove them. This has to be a mistake on Valves part, the server of ours
which got blacklisted runs the exact same way our other servers run and
they're not blacklisted.

On Fri, Feb 15, 2013 at 6:52 AM, Robert Paulson wrote:

> > You can see the number of players on the stats page. TF2 is always in the
> top 3 or 4 games.
> It's 2nd right now.
>
> Sure look at the games list during the least active part of the day when
> many of those players are idling in the only game with a huge incentive to
> idle. Try looking at the list during peak hours. The number of TF2 players
> have stagnated and even dropped after 2 huge updates.
>
> > There are or were big long threads on SPUF moaning about how badly TF2 is
> optimised and moaning about how sentry guns should be removed or such and
> such are overpowered
>
> There's always people complaining about anything. Again, I encourage
> Fletcher to look at the evidence that people join fast respawn servers with
> hidden tags by the boat-load, and stay there all night. And they don't do
> it when tags are listed. This should tell you 2 things: there's a real
> demand for faster respawn, and not being on quickplay is a huge
> disadvntage. Again, I don't care
>
> > The server software is free so I'm not sure what you bought. Was it some
> magic beans in exchange for a cow? :)
>
> I don't know about you but I purchased TF2 with the expectation that
> servers would be moddable like previous Source games AND not be relegated
> to a ghetto deprived of new players. You really think people run modded
> servers without buying the game? There is no formal contract saying that
> server owners have any rights, but there is an unspoken one. And it is up
> to Valve how much they want to erode this good will so that future games
> don't end up like CS:GO.
>
> Anyone that has been looking at TF2 servers now knows that you are out of
> touch with what is happening right now. No one is using fake players on a
> large scale anymore. Of course you wouldn't know given your 1 hour of TF2
> per week.
>
> This will be my final response to you on this matter. Don't take a lack of
> response to mean that anyone is convinced by your essay long tirades about
> how non-vanilla servers are worthless and that they all cheat. My only
> purpose here was to notify Valve to look at the clear evidence.
>
>
>
> On Fri, Feb 15, 2013 at 3:11 AM, dan  wrote:
>
> > On 14/02/2013 22:23, Robert Paulson wrote:
> >
> >> Bring the facts, not your assumptions. Step outside your quickplay
> bubble
> >> once in a while and notice that there's been a huge drop in players on
> the
> >> server browser.
> >>
> >
> > No there hasn't, not really.
> >
> > You can see the number of players on the stats page. TF2 is always in the
> > top 3 or 4 games.
> > It's 2nd right now.
> >
> > 51k peak today. It's not the highest it's ever been, but it's not the
> > lowest either.
> >
> > Player numbers have always risen and fallen in between big updates
> > appearing. That's nothing new.
> >
> > There is probably some seasonal variation, variation based on school
> > holidays, and variation caused by other games being released on steam
> too.
> >
> > Case in point, it wasn't so long ago, just after Halloween, that Fletcher
> > pointed out that some of the Valve servers were empty
> > the lux ones they'd added. These servers are generally full now (with the
> > exception of over night)
> > I hop from one to another for hours and hours at a time.
> >
> > So I'd say your rumours of TF2's death are greatly exaggerated.
> >
> >
> >  Given the few complaints about it until now, very few people care, and I
> >> don't think I'm alone in not having our rights further eroded
> >>
> >
> > What "rights" are these?
> >
> > I think this thread exists because someone at Valve was reminding people
> > about these tags,
> > which I imagine precludes your idea that no one is still abusing them
> (I'm
> > not sure why you think anyone needs to be smart or rich
> > to do it? It's just a plugin and any buffoon can write a plugin. If
> people
> > have paid significant money for them they must be out of their tree)
> >
> > Nor that there are no complaints about them. How do you suppose you would
> > hear complaints? Why would someone complain
> > to you?
> >
> >
> >  to the point where we can't even change the number of slots on our
> server.
> >>
> >
> > Changing the number of slots occasionally is not a problem I'm sure.
> >
> > Dynamically changing it to game the quickplay system or fool people
> > browsing for 24 slot servers clearly is.
> >
> > This is my opinion. But I see no reaso

Re: [hlds_linux] Freezes

[Essay Tew Phaun]

Yeah I've been talking with MikeS from Valve about this. The next time you
get a 100% freeze attach gdb and attempt to get through the code to where
it's actually crashing. I had a server freeze recently and got a gdb log
and backtrace but didn't attempt to step through any of it. I'm quite green
when it comes to doing this so anyone who is better capable should do this
the next time their server freezes at 100%.

On Fri, Feb 15, 2013 at 1:11 PM, Chris Strand wrote:

> I had a console freeze the other day, right after running the server to
> check the update. Haven't sat watching the console since though!
>
> Chris
> From: Erik-jan Riemers
> Sent: 15/02/2013 09:06
> To: Half-Life dedicated Linux server mailing list
> Subject: Re: [hlds_linux] Freezes
> Mine just crash/hang during a restart/exit (see mails restart issue)
>
>
> 2013/2/15 Cameron Munroe 
>
> >
> >
> > I am, but not during map changes, mine are occurring randomly while
> > the game is in session.
> >
> > No error logs, just freezes solid.
> >
> > On
> > 02/15/2013 12:05 AM, Tim Bagheri wrote:
> >
> > > Hi all,
> > >
> > > Lately we have
> > seen a number of servers freeze on console, over the last
> > > few updates
> > this has started extending to the changelevel command.
> > >
> > > Updating to
> > the latest sourcemod / metamod snapshops, or disabling all 3rd
> > > party
> > mods all together seems to have no effect.
> > > Just wondering if anyone
> > else has experienced this problem or has any
> > > solutions?
> > >
> > > --
> > > --
> >
> > > Regards,
> > >
> > > Tim Bagheri
> > >
> > > *Gamers United*
> > > *Administrator*
> > >
> > >
> > This message and any attachments are confidential and are intended for
> > the
> > > addressee only.
> > >
> > ___
> > > To unsubscribe, edit
> > your list preferences, or view the list archives, please visit:
> > >
> > https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
> > [1]
> >
> > ---
> > Cameron Munroe
> >
> > Owner and Operator of (G-S.N) &
> > Munroenet.com
> >
> > Computer Tech
> >
> > http://www.munroenet.com
> > [2]
> > http://www.gaming-servers.net [3]
> > https://www.town-assembly.com
> >
> >
> >
> >
> > Links:
> > --
> > [1]
> > https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
> > [2]
> > http://www.munroenet.com
> > [3] http://www.gaming-servers.net
> > ___
> > 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
>
___
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] daily restarrt manually

[Essay Tew Phaun]

If we're talking about the 100% CPU hang then I recently got a gdb log of
it and sent it to MikeS. I'm on CentOS 6.3.

On Mon, Feb 11, 2013 at 2:59 AM, Steven Haigh  wrote:

> On 11/02/2013 6:46 PM, Erik-jan Riemers wrote:
>
>> Appreciate the ideas, but this is something that been going on for a long
>> long time. Normally I am a patient person and I assume they fix stuff at
>> some point. But since this only impact I believe a certain amount of
>> people with a specific library set / debian it is hard to troubleshoot I
>> presume. All my tools rely on rcon to restart / maintain the servers, I do
>> not want to install clients on every box to simple "monitor" if they are
>> hanging or not because they never did that in the past. A "hanging" server
>> could just as well be doing a update which takes forever (or perhaps you
>> have a solution for that too?)
>>
>
> I agree - although mine is on RHEL6.3 (well, Scientific Linux 6.3 to be
> exact). Servers have been hanging on and off since around November 2011 -
> but it seems to be much worse lately.
>
> I too would rather just see the server fixed - even if its as simple as
> static binaries.
>
>
> __**_
> 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] tf_use_fixed_weaponspreads & Quickplay

[Essay Tew Phaun]

Nope.

On Thu, Feb 7, 2013 at 3:19 AM, DontWannaName! wrote:

> Does it add a server tag? If so then I would assume even more so.
>
>
> On Thu, Feb 7, 2013 at 12:18 AM, Essay Tew Phaun 
> wrote:
>
> > This was my assumption as well but one of our players requested it,
> noting
> > that he couldn't find any information on it disabling Quickplay. I did
> some
> > searching and couldn't find any info on it either. The only mention of
> > something similar is for damage spread and the nodmgspread tag.
> >
> > On Thu, Feb 7, 2013 at 3:02 AM, DontWannaName!  > >wrote:
> >
> > > I would assume it does, its too game changing for new players.
> > >
> > >
> > > On Thu, Feb 7, 2013 at 12:00 AM, Essay Tew Phaun 
> > > wrote:
> > >
> > > > The quickplay article here makes no mention of it:
> > > >
> https://support.steampowered.com/kb_article.php?ref=2825-AFGJ-3513and I
> > > > can't find anywhere where it is explicitly stated that fixed weapon
> > > spreads
> > > > disables you from Quickplay. Googling really doesn't result in any
> > > concrete
> > > > answers. There are a few people who are saying it's in the
> > "blacklisted"
> > > > cvars which I can't find any reference to.
> > > >
> > > > "Just go try it" Well, I'd rather have official word from Valve on
> > > whether
> > > > this is okay for Quickplay or not.
> > > > ___
> > > > 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
> >
> ___
> 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] tf_use_fixed_weaponspreads & Quickplay

[Essay Tew Phaun]

This was my assumption as well but one of our players requested it, noting
that he couldn't find any information on it disabling Quickplay. I did some
searching and couldn't find any info on it either. The only mention of
something similar is for damage spread and the nodmgspread tag.

On Thu, Feb 7, 2013 at 3:02 AM, DontWannaName! wrote:

> I would assume it does, its too game changing for new players.
>
>
> On Thu, Feb 7, 2013 at 12:00 AM, Essay Tew Phaun 
> wrote:
>
> > The quickplay article here makes no mention of it:
> > https://support.steampowered.com/kb_article.php?ref=2825-AFGJ-3513 and I
> > can't find anywhere where it is explicitly stated that fixed weapon
> spreads
> > disables you from Quickplay. Googling really doesn't result in any
> concrete
> > answers. There are a few people who are saying it's in the "blacklisted"
> > cvars which I can't find any reference to.
> >
> > "Just go try it" Well, I'd rather have official word from Valve on
> whether
> > this is okay for Quickplay or not.
> > ___
> > 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

[hlds_linux] tf_use_fixed_weaponspreads & Quickplay

[Essay Tew Phaun]

The quickplay article here makes no mention of it:
https://support.steampowered.com/kb_article.php?ref=2825-AFGJ-3513 and I
can't find anywhere where it is explicitly stated that fixed weapon spreads
disables you from Quickplay. Googling really doesn't result in any concrete
answers. There are a few people who are saying it's in the "blacklisted"
cvars which I can't find any reference to.

"Just go try it" Well, I'd rather have official word from Valve on whether
this is okay for Quickplay or not.
___
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] Random server oddities.

[Essay Tew Phaun]

Forgot to mention. Valve responded to me directly that it could be related
to "rdtsc discrepancies"  and suggested I set each server to use a single
core. So I'm going to do that and see if it resolves the problem.

On Sat, Jan 26, 2013 at 7:51 AM, dan  wrote:

> On 25/01/2013 22:46, Essay Tew Phaun wrote:
>
>> Any idea what specifically about CentOS causes this? I'd prefer not to
>> switch the distro if at all possible. Could Valve possibly comment on
>> this?
>>
>
> It'll presumably be the kernel or the libraries. Not very specific though.
>
> If you have more than one server, I would switch one (I'd make it vanilla
> too), because finding the cause,
> assuming there even is one, will be far more effort than the half an hour
> it takes to install debian -
> and if it turns out there isn't one you'll have wasted a lot more time.
>
> Plus, if running one Debian machine fixes it you can either switch them
> all or, if you care, find what
> specifically causes it yourself by comparing things on the good and bad
> machines.
>
> My bet is, it won't, as the issues sound a bit too specific.
>
> Unless the payload thing is caused by whatever the engine uses to time
> things
> being different (which is no doubt a kernel config thing)
> I can't see how the game rules would be affected in the way described.
>
> I'd think it far more likely to be a plugin or a game bug.
>
> I've not really played any payload to say anything about those bugs though.
>
> I've certainly never seen through walls. 2fort's spawn door can have a
> glitch
> and refuse to open and let people out if there's a cloaked spy knocking
> around occasionally
> (at least I've attributed it to the presence of the spy, that could be
> coincidence)
>
> I've never had a problem picking up the intel in hundreds of hours of CTF
> - but perhaps the
> rule change to sticky and rocket jumper isn't well known and that explains
> it. Are we talking
> intel that is in the enemy base or that has been dropped somewhere along
> the way?
>
> Intel that is run into a spawn takes a tad longer to pick up as you exit.
>
> --
> Dan
>
>
> __**_
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> https://list.valvesoftware.**com/cgi-bin/mailman/listinfo/**hlds_linux<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] Random server oddities.

[Essay Tew Phaun]

I am positive that that is not the case and that walls are see through for
everyone. If I hadn't seen it happen to an entire server on multiple
occasions I would have probably thought the same thing.

http://cloud.steampowered.com/ugc/596977147797869396/DD97BD0D26B24D5EE167F0E7DC7FD471A1F9F767/http://cloud-2.steampowered.com/ugc/594725980421023007/F8361AC3D0AC65E4783A7E681ECBDDAA7FD78A87/


On Sat, Jan 26, 2013 at 7:29 AM, dan  wrote:

> On 25/01/2013 22:05, Essay Tew Phaun wrote:
>
>> Doorways will turn to flat colors that allow you to see through walls.
>> Everyone experiences this and it's not clientside.
>>
>
> I can't see how this can be anything other than clientside, the
> server doesn't render walls or colours.
>
>
>
>  Randomly you won't be able to pick up the Intel on 2Fort. This may happen
>> elsewhere, this is the only CTF map we run.
>>
>
> Sure this isn't people using the training rocket and sticky jumpers?
>
> --
> Dan
>
>
> __**_
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> https://list.valvesoftware.**com/cgi-bin/mailman/listinfo/**hlds_linux<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] Random server oddities.

[Essay Tew Phaun]

Any idea what specifically about CentOS causes this? I'd prefer not to
switch the distro if at all possible. Could Valve possibly comment on this?

On Fri, Jan 25, 2013 at 5:20 PM,  wrote:

>
>
> Don't have that issue with Debian 64bit 6.0.3. Also there is a ton
> of issues known to occur with Centos and SRCDS. The Valve servers run on
> Ubuntu, which is a derivative of Debian.
>
> On , Jake Forrester wrote:
>
>
> > Seconded.
> >
> > On 1/25/2013 5:05 PM, Essay Tew Phaun wrote:
> >
> >> I
> feel like I've been posting a lot here lately. Either that's a testament
> to my stupidity or there are a lot of issues with SRCDS. Here's another
> one I posted about months ago but got no real answers on. We've recent
> switched providers and have a brand new TF installation and this problem
> still occurs as it did with our previous provider (We didn't change
> providers due to this, just saying). Any of the following will happen at
> random: Doorways will turn to flat colors that allow you to see through
> walls. Everyone experiences this and it's not clientside. Payload carts
> will get stuck on the track or when the round begins will show on the
> progress indicator as being near the end. Doors will be open during
> setup when they shouldn't be, allowing the BLU team to exit. Doors will
> not open after setup ends. Randomly you won't be able to pick up the
> Intel on 2Fort. This may happen elsewhere, this is the only CTF map we
> run. All of these happen at random but happen with enough frequency
> where it's a real problem for us. We usually have to reload the map to
> fix it. Doomsday had a similar problem where the rocket would completely
> disappear. Is this sort of thing specific to a SRCDS installation on
> Linux? We've already tried deleting the contents of maps/graphs and that
> doesn't seem to prevent the issue. 2.6.32-279.19.1.el6.i686 #1 CentOS
> 6.3 32bit Thank you. ___ To
> unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux [1]
>
>
>
>
> Links:
> --
> [1]
> 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

[hlds_linux] Random server oddities.

[Essay Tew Phaun]

I feel like I've been posting a lot here lately. Either that's a testament
to my stupidity or there are a lot of issues with SRCDS. Here's another one
I posted about months ago but got no real answers on. We've recent switched
providers and have a brand new TF installation and this problem still
occurs as it did with our previous provider (We didn't change providers due
to this, just saying). Any of the following will happen at random:

Doorways will turn to flat colors that allow you to see through walls.
Everyone experiences this and it's not clientside.
Payload carts will get stuck on the track or when the round begins will
show on the progress indicator as being near the end.
Doors will be open during setup when they shouldn't be, allowing the BLU
team to exit.
Doors will not open after setup ends.
Randomly you won't be able to pick up the Intel on 2Fort. This may happen
elsewhere, this is the only CTF map we run.

All of these happen at random but happen with enough frequency where it's a
real problem for us. We usually have to reload the map to fix it. Doomsday
had a similar problem where the rocket would completely disappear. Is this
sort of thing specific to a SRCDS installation on Linux? We've already
tried deleting the contents of maps/graphs and that doesn't seem to prevent
the issue.

 2.6.32-279.19.1.el6.i686 #1
CentOS 6.3 32bit

Thank you.
___
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] Mandatory TF2, DoD:S, and HL2:DM updates coming

[Essay Tew Phaun]

Here's praying for stringtable crash fixes and spec crash fixes.

On Thu, Jan 24, 2013 at 8:18 PM, wickedplayer494 . <
wickedplayer...@gmail.com> wrote:

> Please don't tell me this will change some arbitrary HUD-related thing
> that'll mess up HUDs for players in tonight's ESEA-I game...
>
> On Thu, Jan 24, 2013 at 7:11 PM, Eric Smith 
> wrote:
> > We're working on mandatory updates for TF2, DoD:S, and HL2:DM. We should
> have them ready soon.
> >
> > -Eric
> >
> >
> > ___
> > 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] Huge disconnects due to steam auth tickets?

[Essay Tew Phaun]

Well, everyone was disconnected across all 5 of our servers.

On Thu, Jan 24, 2013 at 6:12 PM,  wrote:

>
>
> Then a AMD 1045T shouldn't have the issue correct when it has a load
> of 0.00, right? Yet it still happens.
>
> On , Bruno Garcia wrote:
>
> > I
> believe most of the problem was because Steam client took too much CPU
> >
> and since the auth ticket has a time window to be sent and received
> the
> > lack of CPU made it impossible to be sent in time and the steam
> server
> > would UN-authenticate you and the game server would eventually
> kick you.
> >
> > This I believe, has been fixed, but perhaps (being VALVe
> and all) the bug
> > was re-introduced in some internal changes they might
> have done.
> >
> > On Wed, Jan 23, 2013 at 7:44 PM,
>  wrote:
> >
> >> The issue revolves around where
> the steam servers loose connection to a client, thus reporting a crash
> statement. However when whole routes and 1000's of gamers are hit it
> seems like the whole server gets kicked. On top of this if the server
> looses connection to steam there is always the no VAC connection
> statement which kicks all players as well. Both of which are common and
> happen to pretty much any server when there is problems with the route
> to steam servers, or the steam servers them selves. Also was it during a
> map change? If so that is also common, but not all players should have
> been kicked by that one. Just means they crashed during map change. On ,
> Kyle Sanderson wrote:
> >>
> >>> It's been a
> >> problem for years, they're
> probably never going to address itunfortunately. There was a backend bug
> that caused the problem to occur
> >>
> >>> randomly, now it just happens
> daily when Steam goes down. There
> >> was an with any game besides CS:S
> (it would need to be recompiled). Are we the only ones? Anyone else? Our
> servers just completely emptied
> >
> >
> ___
> > To unsubscribe, edit
> your list preferences, or view the list archives, please visit:
> >
> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux [2]
>
>
>
>
> Links:
> --
> [1] http://store.steampowered.com/stats/
> [2]
> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
> [3]
> https://list.
>
> > o/hlds_linux [2] 
> http://store.steampowered.com/stats/ [1] ___ To unsubscribe, edit your list p
> rviewthelistarchives,pleasevisit: ___
> 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] Huge disconnects due to steam auth tickets?

[Essay Tew Phaun]

Are we the only ones? Anyone else? Our servers just completely emptied out.
___
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] [TF2] Stringtable overflows and crashes caused by precaching

[Essay Tew Phaun]

Eh, I wasn't really saying you can't tell the difference between when one
crashes or another doesn't. I said it to bring to light how often they both
crash. We've switched hosts and that problem went away. Thanks for the help
though.

On Sat, Jan 19, 2013 at 11:38 AM, dan  wrote:

> On 18/01/2013 21:22, Essay Tew Phaun wrote:
>
>> I just think it's pathetic that you can't even tell anymore what is at
>> fault.Is it the clients? Is it the servers? Who knows.
>>
>
> You can tell whether it's a server that's crashing or a client that's
> crashing.
>
> So it's not really relevant for this thread.
>
> You could have found out the cause of your issue in the other thread too
> had you
> wanted to.
>
> The way to do it is to eliminate things. So, for example, is it a specific
> map? How to find out? Try different maps. Is it the client or the server?
> Run the game without a server (i.e a listen server) then if your problem
> happens, it happens on that one computer. Or try different servers. If you
> can, try different computers, renaming your config so it uses the defaults
> etc etc.
>
> For client things you have lots to try, different drivers, configs and so
> on.
>
> Read Sherlock Holmes. Once you've eliminated stuff it can't be, you get
> left with what it must be. You can then make some meaningful noises that
> would help someone recreate it if you're sure it's a bug in the game.
>
> But, if it's the client I would say use a different group. Why?
>
> 1. Because no one here knows anything special to help you. The group
> doesn't contain any existing threads that will help you either.
> 2. People are more likely to moan about this group being for server issues
> 3. If you find a group you may find people with the same problem and
> people without a problem at all. Which will help you spot patterns.
> 4. If it's the client you need to post machine specs and driver versions
> and try different ones and so on and so on.
> In a different group with lots of people that play TF2 someone will say "I
> have a C2D E8400 and a Pomegranate 5462 high overhead cam fuel injected
> speedy Mark 5 Pan European Hogwash PCIe series graphics card and I use
> windows 7 and the game runs fine for me" - so you can eliminate things that
> just won't get eliminated if you try to solve the client problem by posting
> here.
>
> Perhaps then you will find something that Valve have broken (like this
> thread suggests is happening elsewhere) but, given the symptoms you
> described a while back unless you have some esoteric hardware I'd say the
> problem is most likely not the game. But I'll happily be proven wrong.
>
> --
> Dan
>
>
> __**_
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> https://list.valvesoftware.**com/cgi-bin/mailman/listinfo/**hlds_linux<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] [TF2] Stringtable overflows and crashes caused by precaching

[Essay Tew Phaun]

I just think it's pathetic that you can't even tell anymore what is at
fault. Is it the clients? Is it the servers? Who knows. Both crash with
just about as much frequency and you can bet your bottom dollar that every
big update will be replete with crashing issues. Steam going down,
Quickplay logging out, crashing on map changes, crashing on MOTD, crashing
for being in spectator, crashing due to stringtable overflows, it never
ends.

*SPEND*
*SOME*
*TIME
OPTIMIZING
THE
SERVERS
AND
CLIENT
STOP
RELEASING
HUGE
UPDATES
UNTIL
THESE
ARE
STABLE*
___
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] Servers not coming up after a map change?

[Essay Tew Phaun]

I'm having an issue where our servers are sometimes not accessible after a
map change. The map changes, the server is still up but it does not respond
in the server browser nor can you connect to it. It's not at 100% CPU
either, it's not crashing at all or generating any logs.
___
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] Large Gaps in the net_graph

[Essay Tew Phaun]

Okay, and? It wasn't until just a reply or so ago where I suspected that it
may be just that.

On Fri, Jan 11, 2013 at 4:01 PM, j m  wrote:

> Again,  it's a client issue.  The answer is not to be found here.
> On Jan 11, 2013 12:54 PM, "Essay Tew Phaun"  wrote:
>
> > I get it everywhere, on all servers. Like mentioned in my post above, I'm
> > starting to think it's some kind of client problem now.
> >
> > On Fri, Jan 11, 2013 at 2:21 PM, dan  wrote:
> >
> > > On 10/01/2013 16:52, Essay Tew Phaun wrote:
> > >
> > >> I've narrowed it down. It occurs when turning corners or viewing a new
> > >> area
> > >> of a map that has enemies and it's a hard pause, too. There's
> absolutely
> > >> nothing normal with these pauses. It's completely unreasonable to
> expect
> > >> people to play that way. You lose all control for a 1/2 a second to a
> > full
> > >> second. At this point it's really starting to look like a client
> issue.
> > >>
> > >
> > > Narrow it down to help determine the cause, not the symptoms :-)
> > >
> > > You haven't narrowed it down to whether it's your servers, all servers
> or
> > > not even the servers at all but caused by the client etc etc.
> > >
> > > But my point wasn't really whether what's happening to you when you
> see a
> > > graph like that is normal or not, but simply that a gap in that graph
> > does
> > > happen normally as well. So showing someone a picture of a graph with a
> > gap
> > > in it, is unlikely to either tell them what's happening or to let them
> > see
> > > what's happening.
> > >
> > > If it happened to me I'd be "Yeah, it sucks, let's hope Valve fix it",
> > but
> > > I've played for hundreds of hours since the
> > > Halloween update without the issue.
> > >
> > > That said, if you think it's the client you want to think what you've
> > > changed - Video card drivers, OS updates etc, TF2 config since it
> started
> > > to happen, or just go through the list to narrow it down and eliminate
> > > these things - I'd write a list but I feel like I wasted my time last
> > time,
> > > so  I suppose you'll be better off sorting out client problems like
> that
> > on
> > > different forums / groups.
> > >
> > >
> > > --
> > > Dan.
> > >
> > > __**_
> > > To unsubscribe, edit your list preferences, or view the list archives,
> > > please visit:
> > > https://list.valvesoftware.
> **com/cgi-bin/mailman/listinfo/**hlds_linux<
> > 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
>
___
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] Large Gaps in the net_graph

[Essay Tew Phaun]

I get it everywhere, on all servers. Like mentioned in my post above, I'm
starting to think it's some kind of client problem now.

On Fri, Jan 11, 2013 at 2:21 PM, dan  wrote:

> On 10/01/2013 16:52, Essay Tew Phaun wrote:
>
>> I've narrowed it down. It occurs when turning corners or viewing a new
>> area
>> of a map that has enemies and it's a hard pause, too. There's absolutely
>> nothing normal with these pauses. It's completely unreasonable to expect
>> people to play that way. You lose all control for a 1/2 a second to a full
>> second. At this point it's really starting to look like a client issue.
>>
>
> Narrow it down to help determine the cause, not the symptoms :-)
>
> You haven't narrowed it down to whether it's your servers, all servers or
> not even the servers at all but caused by the client etc etc.
>
> But my point wasn't really whether what's happening to you when you see a
> graph like that is normal or not, but simply that a gap in that graph does
> happen normally as well. So showing someone a picture of a graph with a gap
> in it, is unlikely to either tell them what's happening or to let them see
> what's happening.
>
> If it happened to me I'd be "Yeah, it sucks, let's hope Valve fix it", but
> I've played for hundreds of hours since the
> Halloween update without the issue.
>
> That said, if you think it's the client you want to think what you've
> changed - Video card drivers, OS updates etc, TF2 config since it started
> to happen, or just go through the list to narrow it down and eliminate
> these things - I'd write a list but I feel like I wasted my time last time,
> so  I suppose you'll be better off sorting out client problems like that on
> different forums / groups.
>
>
> --
> Dan.
>
> __**_
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> https://list.valvesoftware.**com/cgi-bin/mailman/listinfo/**hlds_linux<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] Large Gaps in the net_graph

[Essay Tew Phaun]

It's not just me, either. I've had several members of our community report
the exact same thing.

On Thu, Jan 10, 2013 at 11:52 AM, Essay Tew Phaun  wrote:

> I've narrowed it down. It occurs when turning corners or viewing a new
> area of a map that has enemies and it's a hard pause, too. There's
> absolutely nothing normal with these pauses. It's completely unreasonable
> to expect people to play that way. You lose all control for a 1/2 a second
> to a full second. At this point it's really starting to look like a client
> issue.
>
>
> On Thu, Jan 10, 2013 at 11:42 AM, dan  wrote:
>
>> On 10/01/2013 12:13, Essay Tew Phaun wrote:
>>
>>> Here's something on our private server, no mods running, bots only.
>>> Middle
>>> of the morning (3AM or so)
>>>
>>
>> But gaps in the net_graph like that are perfectly normal, for example,
>> when the round ends I get a gap
>> as you get teleported to the spawn and the next round is about to start.
>>
>> As others have said, when spectating (e.g after a death) switching
>> between players creates a small gap too.
>>
>> And it looks like you just hit F12 to capture a screenshot when nothing
>> is wrong,
>> so the rest of the figures tell us nothing.
>>
>> I think whatever problem you have you aren't showing anything that
>> demonstrates it well.
>>
>> You could try some of the things on the list I typed in my last post to
>> try and narrow down the problem.
>>
>> --
>> Dan.
>>
>>
>> __**_
>> To unsubscribe, edit your list preferences, or view the list archives,
>> please visit:
>> https://list.valvesoftware.**com/cgi-bin/mailman/listinfo/**hlds_linux<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] Large Gaps in the net_graph

[Essay Tew Phaun]

I've narrowed it down. It occurs when turning corners or viewing a new area
of a map that has enemies and it's a hard pause, too. There's absolutely
nothing normal with these pauses. It's completely unreasonable to expect
people to play that way. You lose all control for a 1/2 a second to a full
second. At this point it's really starting to look like a client issue.

On Thu, Jan 10, 2013 at 11:42 AM, dan  wrote:

> On 10/01/2013 12:13, Essay Tew Phaun wrote:
>
>> Here's something on our private server, no mods running, bots only. Middle
>> of the morning (3AM or so)
>>
>
> But gaps in the net_graph like that are perfectly normal, for example,
> when the round ends I get a gap
> as you get teleported to the spawn and the next round is about to start.
>
> As others have said, when spectating (e.g after a death) switching between
> players creates a small gap too.
>
> And it looks like you just hit F12 to capture a screenshot when nothing is
> wrong,
> so the rest of the figures tell us nothing.
>
> I think whatever problem you have you aren't showing anything that
> demonstrates it well.
>
> You could try some of the things on the list I typed in my last post to
> try and narrow down the problem.
>
> --
> Dan.
>
>
> __**_
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> https://list.valvesoftware.**com/cgi-bin/mailman/listinfo/**hlds_linux<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] Large Gaps in the net_graph

[Essay Tew Phaun]

Here's something on our private server, no mods running, bots only. Middle
of the morning (3AM or so)

http://i.imgur.com/tIq2u.jpg

On Thu, Jan 10, 2013 at 2:20 AM, dan  wrote:

> On 10/01/2013 05:11, Essay Tew Phaun wrote:
>
>> Thought I had fixed this problem with a recent change I did, but nope.
>> It's
>> still here and in full effect. Tends to always have gaps when you're
>> viewing new map scenes and seems to also happen at random. If you enter an
>> area with a lot of enemies by turning a corner or coming out of a trench
>> there is a near full second lockup until everything else resumes.
>>
>> http://i.imgur.com/C1Kjc.jpg
>>
>
> Well it's either client or server.
>
> Find out which one
>
> 1a) Join other low ping servers near you and see if the same problem
> happens
> 1b) Try local listen maps like tr_walkway_rc2 and bot matches to see if
> they render and play fine
> 2) Post screenshots with the full net_graph 5 output when the problem
> happens not just the graph.
> 3) Get other people on your server to do the same if/when they are having
> a similar problem
> 4) Make sure your (and their) client settings are good (wrt the other
> posts in this thread)
>
> AFAICT It's not a general problem, I've played for hours and hours over
> Xmas / New Year and not had issues with lag or lockups,
> certainly not repeatable issues caused by walking into new map areas -
> (unless you're using the linux client of TF2 on AMD hardware, in which
> case, don't, life's too short)
>
> But it's likely Valve can't recreate the issue.
>
> If it's your client, the most likely issue is either some borked config or
> something to do with the configuration of your PC (video drivers,
> networking or whatever)
> Similarly, if it's your server, it's most likely some aspect of the
> install or maybe even some issue with the kernel config etc that's causing
> it.
> Aren't there some documented slowdowns with 3.7's networking? I only saw a
> headline so that could be completely unrelated but if you're using that
> kernel it might be worth checking.
>
> Of course it could be some bug in TF2 itself, the best way to try and see
> there (using the theory that it's not universal) would be to broaden the
> testing as much as possible, use every map you can, every game type and see
> if some work and some don't.
>
> But, I would start with your client, if you can't connect to any server
> without this issue I'd say the problem must be your client or your network
> connection to the servers. Without a client you are confident works, you
> can't really test servers using it. Once you've got that, change any and
> everything one at a time until you find the cause.
>
> Generally speaking I play CTF and koth most of the time, so if there's big
> issues with mvm or pl or some such I wouldn't notice.
>
>
> --
> Dan
>
> __**_
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> https://list.valvesoftware.**com/cgi-bin/mailman/listinfo/**hlds_linux<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] Large Gaps in the net_graph

[Essay Tew Phaun]

Thought I had fixed this problem with a recent change I did, but nope. It's
still here and in full effect. Tends to always have gaps when you're
viewing new map scenes and seems to also happen at random. If you enter an
area with a lot of enemies by turning a corner or coming out of a trench
there is a near full second lockup until everything else resumes.

http://i.imgur.com/C1Kjc.jpg

No choke, no loss. Tested without MM:SM as well, problem remains. Can
this *please
*get some more attention?
___
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] Large Gaps in the net_graph

[Essay Tew Phaun]

Tried this already. Thanks for the suggestion though, Kyle.

On Sat, Jan 5, 2013 at 2:36 PM, Kyle Sanderson  wrote:

> Try increasing net_splitpacket_maxrate to something usable like 50k (We're
> using 75k, but we have 64 players). It looks like we also have
> net_splitrate set as well (to 5), but I don't remember that having a huge
> effect.
>
> Thanks,
> Kyle.
>
>
> On Sat, Jan 5, 2013 at 10:51 AM, Essay Tew Phaun 
> wrote:
>
> > We used to, but haven't for several months now.
> >
> > On Sat, Jan 5, 2013 at 1:32 PM, ics  wrote:
> >
> > > If you started seeing spikes recently, after the xmas update, there's
> > that
> > > spam in the console that makes my own game lag like hell when it
> happens.
> > > Screen even jams occasionally.
> > >
> > > Before that, i saw mostly players going fast forward with leaping place
> > to
> > > another when issues like this occurs. It's just some players, just as
> > some
> > > packets would be "lost" (or not given to you) at that time and only
> part
> > of
> > > his actual movement is shown (like packet 3, 35 64 and not
> > > 3,12,23,35,43,51,64,76,89 etc). As i recall, this started long ago, at
> > the
> > > time that valve optimized the code and bandwidth usage for servers
> > dropped
> > > at the same time.
> > >
> > > Also one other thing happened at that t ime, which is that now the game
> > > draws only players that are around the next corner and not the ones at
> > next
> > > corner and after the next one. This of course can be coped with some
> > > optimization on maps but this is now default setting. If you want to
> > > experience this as a test, go in map harvest and if you spec a sniper
> > that
> > > is in the roof but is not peaking over the rooftop to middle. You
> cannot
> > > see the enemies that are in area on front of the rooftop. However,  as
> > soon
> > > as he peaks over, the enemies magically appear for your screen, which
> > means
> > > you see the same thing as he does. Only he cannot see what you see from
> > > above his head, sooner than he. So if you see the enemies and he is
> > peeking
> > > over and then goes down crouching, those enemies will disappear.
> > >
> > > Before Valve did the optimization over a year ago, as a 3rd person, you
> > > could see all that is happening on the battlefield while spectating a
> > > person. Now, this effect happens. In some rare and not so rare cases,
> it
> > > can lead to sudden lag as your hardware tries to catch up on whats
> going
> > on
> > > at the screen. Naturally this part has nothing to do with servers
> > > themselves, it's just ingame thing on players. That recent dynamic
> model
> > > loading might have done this even more visible but i think they are
> > loading
> > > the models that should be coming up in advance but i have no way of
> > knowing
> > > how advanced that system is at guessing what comes next.
> > >
> > > But also one question, do you force your servers to run on specific cpu
> > > core? I've also seen that causing similiar lag effect.
> > >
> > > -ics
> > >
> > > 5.1.2013 19:53, Jake Forrester kirjoitti:
> > >
> > >  I have the exact same issue.  When turning the corner, getting team
> > >> changed, or just running into a bunch of other players, I get huge
> > >> spikes in my graph (with gaps).  It's gotten so bad that it can become
> > >> impossible to aim during large enemy encounters, so I've just given up
> > >> on TF2 for the time being.  I guess on to DOTA?  Kind of sucks being
> in
> > >> charge of a server that you can't even play on.
> > >>
> > >> On 1/5/2013 11:49 AM, Essay Tew Phaun wrote:
> > >>
> > >>> I know this isn't exactly scientific but we weren't having these
> > reports
> > >>> of
> > >>> lag before. Of course, you're always going to have a few people
> > >>> complaining
> > >>> about lag and blaming their performance on it, but recently, probably
> > as
> > >>> of
> > >>> the big update (Halloween or Mecha, not sure which) We've seen a
> > >>> humongous
> > >>> rise in the complaints about lag. Whether that's the cause of the
> > server
> > >>> or
> > >>

Re: [hlds_linux] Large Gaps in the net_graph

[Essay Tew Phaun]

We used to, but haven't for several months now.

On Sat, Jan 5, 2013 at 1:32 PM, ics  wrote:

> If you started seeing spikes recently, after the xmas update, there's that
> spam in the console that makes my own game lag like hell when it happens.
> Screen even jams occasionally.
>
> Before that, i saw mostly players going fast forward with leaping place to
> another when issues like this occurs. It's just some players, just as some
> packets would be "lost" (or not given to you) at that time and only part of
> his actual movement is shown (like packet 3, 35 64 and not
> 3,12,23,35,43,51,64,76,89 etc). As i recall, this started long ago, at the
> time that valve optimized the code and bandwidth usage for servers dropped
> at the same time.
>
> Also one other thing happened at that t ime, which is that now the game
> draws only players that are around the next corner and not the ones at next
> corner and after the next one. This of course can be coped with some
> optimization on maps but this is now default setting. If you want to
> experience this as a test, go in map harvest and if you spec a sniper that
> is in the roof but is not peaking over the rooftop to middle. You cannot
> see the enemies that are in area on front of the rooftop. However,  as soon
> as he peaks over, the enemies magically appear for your screen, which means
> you see the same thing as he does. Only he cannot see what you see from
> above his head, sooner than he. So if you see the enemies and he is peeking
> over and then goes down crouching, those enemies will disappear.
>
> Before Valve did the optimization over a year ago, as a 3rd person, you
> could see all that is happening on the battlefield while spectating a
> person. Now, this effect happens. In some rare and not so rare cases, it
> can lead to sudden lag as your hardware tries to catch up on whats going on
> at the screen. Naturally this part has nothing to do with servers
> themselves, it's just ingame thing on players. That recent dynamic model
> loading might have done this even more visible but i think they are loading
> the models that should be coming up in advance but i have no way of knowing
> how advanced that system is at guessing what comes next.
>
> But also one question, do you force your servers to run on specific cpu
> core? I've also seen that causing similiar lag effect.
>
> -ics
>
> 5.1.2013 19:53, Jake Forrester kirjoitti:
>
>  I have the exact same issue.  When turning the corner, getting team
>> changed, or just running into a bunch of other players, I get huge
>> spikes in my graph (with gaps).  It's gotten so bad that it can become
>> impossible to aim during large enemy encounters, so I've just given up
>> on TF2 for the time being.  I guess on to DOTA?  Kind of sucks being in
>> charge of a server that you can't even play on.
>>
>> On 1/5/2013 11:49 AM, Essay Tew Phaun wrote:
>>
>>> I know this isn't exactly scientific but we weren't having these reports
>>> of
>>> lag before. Of course, you're always going to have a few people
>>> complaining
>>> about lag and blaming their performance on it, but recently, probably as
>>> of
>>> the big update (Halloween or Mecha, not sure which) We've seen a
>>> humongous
>>> rise in the complaints about lag. Whether that's the cause of the server
>>> or
>>> client, I guess that remains to be seen, but we're having a lot of
>>> complaints and have done everything we can on our end to try and address
>>> it
>>> including moving down to 24 player servers which we did *NOT *want to do.
>>> The problem is still there. An hour or so ago I loaded up a completely
>>> vanilla server with no MM:SM, the same issue appears.
>>>
>>> We get the gaps and spikes in the net_graph a lot. I get HUGE gaps when
>>> going in to a new area of a map a lot of the time. Here's a screenshot
>>> from
>>> just now when I tested.
>>>
>>> http://i.imgur.com/4V1TZ.jpg
>>>
>>>
>>>
>
> __**_
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> https://list.valvesoftware.**com/cgi-bin/mailman/listinfo/**hlds_linux<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] Large Gaps in the net_graph

[Essay Tew Phaun]

I know this isn't exactly scientific but we weren't having these reports of
lag before. Of course, you're always going to have a few people complaining
about lag and blaming their performance on it, but recently, probably as of
the big update (Halloween or Mecha, not sure which) We've seen a humongous
rise in the complaints about lag. Whether that's the cause of the server or
client, I guess that remains to be seen, but we're having a lot of
complaints and have done everything we can on our end to try and address it
including moving down to 24 player servers which we did *NOT *want to do.
The problem is still there. An hour or so ago I loaded up a completely
vanilla server with no MM:SM, the same issue appears.

We get the gaps and spikes in the net_graph a lot. I get HUGE gaps when
going in to a new area of a map a lot of the time. Here's a screenshot from
just now when I tested.

http://i.imgur.com/4V1TZ.jpg

On Sat, Jan 5, 2013 at 11:22 AM, Michael Johansen  wrote:

>
> We've been having weird issues like this aswell, some times the game just
> freezes for a split second and then continues. The netgraph shows the ping
> rises and so does the in/out values.
>
> > Date: Sat, 5 Jan 2013 09:43:31 -0500
> > From: sc2p...@gmail.com
> > To: hlds_linux@list.valvesoftware.com
> > Subject: Re: [hlds_linux] Large Gaps in the net_graph
> >
> > Yeah I'm not saying the issue is caused by the same thing as those
> videos.
> > It's just causing a similar problem.
> >
> > On Sat, Jan 5, 2013 at 9:17 AM, dan  wrote:
> >
> > > On 04/01/2013 23:00, Essay Tew Phaun wrote:
> > >
> > >> The issue is very similar to the videos posted on youtube here:
> > >>
> > >> http://www.youtube.com/watch?**v=ArWe_ODu2-Y<
> http://www.youtube.com/watch?v=ArWe_ODu2-Y>
> > >> http://www.youtube.com/watch?**v=GgWldsyWNIQ<
> http://www.youtube.com/watch?v=GgWldsyWNIQ>
> > >> http://www.youtube.com/watch?**v=OdZBeOD2eTI<
> http://www.youtube.com/watch?v=OdZBeOD2eTI>
> > >>
> > >
> > > These must be old? The sv: field is saying 256 rather than the 66 it
> does
> > > now.
> > >
> > > The 3rd one really needs lower client settings (he has cmdrate et al
> set
> > > to 66, but doesn't generate 66 fps)
> > >
> > >
> > >  We've investigated the network, the general system performance (CPU,
> > >> Memory, I/O). Everything is checking out fine with these. We've tried
> a
> > >> few
> > >> various things within the server.cfgs other than the defaults and they
> > >> have
> > >> not changed anything. In the network graphs, we have no loss, we have
> no
> > >> choke, or very little, which is about normal with a lot going on. var
> > >> seems
> > >> to stay pretty low, 0.50-2.00.
> > >>
> > >
> > > There used to be this kind of 'rewind' thing on Valve's servers.
> > > The fra ones.
> > >
> > > Lately it's a lot better though with their lux servers.
> > >
> > > Given they're vanilla it's difficult to envisage a general problem,
> unless
> > > it only affects certain maps or game modes?
> > >
> > > --
> > > Dan.
> > >
> > >
> > > __**_
> > > To unsubscribe, edit your list preferences, or view the list archives,
> > > please visit:
> > > https://list.valvesoftware.
> **com/cgi-bin/mailman/listinfo/**hlds_linux<
> 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
>
___
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] Large Gaps in the net_graph

[Essay Tew Phaun]

Yeah I'm not saying the issue is caused by the same thing as those videos.
It's just causing a similar problem.

On Sat, Jan 5, 2013 at 9:17 AM, dan  wrote:

> On 04/01/2013 23:00, Essay Tew Phaun wrote:
>
>> The issue is very similar to the videos posted on youtube here:
>>
>> http://www.youtube.com/watch?**v=ArWe_ODu2-Y<http://www.youtube.com/watch?v=ArWe_ODu2-Y>
>> http://www.youtube.com/watch?**v=GgWldsyWNIQ<http://www.youtube.com/watch?v=GgWldsyWNIQ>
>> http://www.youtube.com/watch?**v=OdZBeOD2eTI<http://www.youtube.com/watch?v=OdZBeOD2eTI>
>>
>
> These must be old? The sv: field is saying 256 rather than the 66 it does
> now.
>
> The 3rd one really needs lower client settings (he has cmdrate et al set
> to 66, but doesn't generate 66 fps)
>
>
>  We've investigated the network, the general system performance (CPU,
>> Memory, I/O). Everything is checking out fine with these. We've tried a
>> few
>> various things within the server.cfgs other than the defaults and they
>> have
>> not changed anything. In the network graphs, we have no loss, we have no
>> choke, or very little, which is about normal with a lot going on. var
>> seems
>> to stay pretty low, 0.50-2.00.
>>
>
> There used to be this kind of 'rewind' thing on Valve's servers.
> The fra ones.
>
> Lately it's a lot better though with their lux servers.
>
> Given they're vanilla it's difficult to envisage a general problem, unless
> it only affects certain maps or game modes?
>
> --
> Dan.
>
>
> __**_
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> https://list.valvesoftware.**com/cgi-bin/mailman/listinfo/**hlds_linux<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] Large Gaps in the net_graph

[Essay Tew Phaun]

Up until recently (As of the Halloween/Mecha update, not entirely sure
which) We've had some performance issues with our servers but it has become
very troublesome to pin down. We've literally tried about everything there
is to try. We've reduced our max player counts down to 24 players. This
solved the No Edict crashes, however we're still having performance issues
on the servers. Mainly what is happening is that as clients are turning the
corner and viewing a new "scene" with enemies, we're getting a very large
gap in the network graph. I will post a couple of these below:

*One player*

http://i.imgur.com/Zk4oA.png
http://i.imgur.com/KjQx6.png

*Another*
*
*
http://i.imgur.com/iGBGi.jpg

The issue is very similar to the videos posted on youtube here:

http://www.youtube.com/watch?v=ArWe_ODu2-Y
http://www.youtube.com/watch?v=GgWldsyWNIQ
http://www.youtube.com/watch?v=OdZBeOD2eTI

We've investigated the network, the general system performance (CPU,
Memory, I/O). Everything is checking out fine with these. We've tried a few
various things within the server.cfgs other than the defaults and they have
not changed anything. In the network graphs, we have no loss, we have no
choke, or very little, which is about normal with a lot going on. var seems
to stay pretty low, 0.50-2.00.

System:
CentOS 6.2 (2.6.32-279.1.1.el6.x86_64)
e3-1230 3.2ghz
8GB RAM
100mbit port

We run 5 servers total, each 24 slots.
___
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] Too many simultaneously active particles

[Essay Tew Phaun]

Same thing we're getting. *When *is it going to be possible to host servers
again without running in to a ton of issues?

Client crashes on map change.
Servers locking up stuck at 100%.
Servers Edict crashes.

Just a small sampler of some of the problems.

On Thu, Jan 3, 2013 at 9:00 PM, Jake Forrester wrote:

> Greetings everyone,
>
> Has anyone else experienced users complaining of lag while there is both
> no ping issues, and no packet loss?  I did some digging and was able to
> find these errors being thrown in consoles of users who have run into this:
>
> /Particles: maximum verts exceeded: 71532 verts, 104382 indexes//
> //Too many simultaneously active particles!//
> //Particles: maximum verts exceeded: 74144 verts, 108414 indexes//
> //
> //Cannot update control point 1 for effect 'muzzle_grenadelauncher'.//
> //
> //Cannot update control point 3 for effect 'cart_flashinglight'.//
> //
> //Cannot update control point 0 for effect 'player_sparkles_blue'.//
> //No such variable "$colortint_tmp" for material
> "models/player/items/engineer/engineer_top_hat_red"//
> //Error: Material "models/player/items/engineer/engineer_top_hat_red" :
> proxy "ItemTintColor" unable to initialize!//
> //No such variable "$colortint_tmp" for material
> "models/player/items/engineer/engineer_top_hat_red"//
> //Error: Material "models/player/items/engineer/engineer_top_hat_red" :
> proxy "SelectFirstIfNonZero" unable to initialize!/
>
> I've also sees references to these errors outside of our servers:
>
> http://i192.photobucket.com/albums/z12/shadowz_bucket/jjj_zpsc6c5dfc2.png
> http://steamcommunity.com/app/440/discussions/0/846940248946859430/
>
> Thanks
>
> --
>
> Jake Forrester
> Freelance Web Developer/Designer &
> Joomla Enthusiast
> e: j...@ranndesigns.com
>
> ___
> 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] Engine error: ED_Alloc: no free edicts

[Essay Tew Phaun]

Another one today, from same server.

L 01/02/2013 - 19:48:47: Warning: free edicts below threshold. 8 free
edicts remaining.
L 01/02/2013 - 19:48:47: Warning: free edicts below threshold. 7 free
edicts remaining.
L 01/02/2013 - 19:48:47: Warning: free edicts below threshold. 6 free
edicts remaining.
L 01/02/2013 - 19:48:47: Warning: free edicts below threshold. 5 free
edicts remaining.
L 01/02/2013 - 19:48:47: Warning: free edicts below threshold. 4 free
edicts remaining.
L 01/02/2013 - 19:48:47: Warning: free edicts below threshold. 3 free
edicts remaining.
L 01/02/2013 - 19:48:47: Warning: free edicts below threshold. 2 free
edicts remaining.
L 01/02/2013 - 19:48:47: Warning: free edicts below threshold. 1 free edict
remaining.
L 01/02/2013 - 19:48:47: Warning: free edicts below threshold. 0 free
edicts remaining.
L 01/02/2013 - 19:48:47: Engine error: ED_Alloc: no free edicts

On Wed, Jan 2, 2013 at 4:17 PM, Essay Tew Phaun  wrote:

> Hit again today and crashed a server..
>
> L 01/02/2013 - 16:04:17: Engine error: ED_Alloc: no free edicts
>
> Not a big deal I guess, keep adding hats/effects.
>
>
> On Mon, Dec 24, 2012 at 7:07 AM, Saul Rennison wrote:
>
>> He meant the edict limit isn't reached gradually, it's usually hit on
>> round
>> reset.
>>
>> On Monday, December 24, 2012, Erik-jan Riemers wrote:
>>
>> > For the time that i used them, they worked fine to change the level
>> > though. You can see in the logs "free eddicts remaining 8, till 1/0"
>> then
>> > it just changes the map. It doesn't come to a round reset it just goes
>> > poof without a warning to the next map.
>> > It was never gradually, it was almost instantly. But result may vary :-)
>> >
>> > -Original Message-
>> > From: hlds_linux-boun...@list.valvesoftware.com 
>> > [mailto:hlds_linux-boun...@list.valvesoftware.com ] On
>> > Behalf Of Kyle
>> > Sanderson
>> > Sent: maandag 24 december 2012 7:05
>> > To: Half-Life dedicated Linux server mailing list
>> > Subject: Re: [hlds_linux] Engine error: ED_Alloc: no free edicts
>> >
>> > Unfortunately those convars aren't helpful, maybe if you're gradually
>> > reaching the limit they may work. Something like a round reset will
>> still
>> > totally crash the server.
>> >
>> > Thanks,
>> > Kyle.
>> >
>> >
>> > On Sun, Dec 23, 2012 at 3:54 PM, Erik-jan Riemers > 
>> > >
>> > wrote:
>> >
>> > > The ones I was talking about..
>> > >
>> > > sv_lowedict_action 0 - no action, 1 - warn to log file, 2 - attempt to
>> > > restart the game, if applicable, 3 - restart the map, 4 - go to the
>> > > next map sv_lowedict_threshold 8 - When only this many edicts are
>> > > free, take the action specified by sv_lowedict_action.
>> > >
>> > > I've even seen idle servers crash on low eddicts (cannot get any more
>> > > tiny map / low eddicts then an idle map)
>> > >
>> > > But for instance, saxton hale servers are my nr 1 troublemaker when it
>> > > comes to the most amounts.. (heavy mods and such)
>> > >
>> > > -Original Message-
>> > > From: hlds_linux-boun...@list.valvesoftware.com 
>> > > [mailto:hlds_linux-boun...@list.valvesoftware.com ] On
>> > Behalf Of Essay
>> > > Tew Phaun
>> > > Sent: zondag 23 december 2012 17:59
>> > > To: Half-Life dedicated Linux server mailing list
>> > > Subject: [hlds_linux] Engine error: ED_Alloc: no free edicts
>> > >
>> > > Just had a crash with this and I don't ever remember having a crash
>> > > because of running out of edicts before. Anyone else experience this
>> > > lately?
>> > > ___
>> > > 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
>> >
>> > ___
>> > To unsubscribe, edit your list preferences, or view the list archives,
>> > please visit:
>> > https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
>> >
>>
>>
>> --
>>
>>
>> Kind regards,
>> Saul Rennison
>> ___
>> 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] Engine error: ED_Alloc: no free edicts

[Essay Tew Phaun]

Hit again today and crashed a server..

L 01/02/2013 - 16:04:17: Engine error: ED_Alloc: no free edicts

Not a big deal I guess, keep adding hats/effects.

On Mon, Dec 24, 2012 at 7:07 AM, Saul Rennison wrote:

> He meant the edict limit isn't reached gradually, it's usually hit on round
> reset.
>
> On Monday, December 24, 2012, Erik-jan Riemers wrote:
>
> > For the time that i used them, they worked fine to change the level
> > though. You can see in the logs "free eddicts remaining 8, till 1/0" then
> > it just changes the map. It doesn't come to a round reset it just goes
> > poof without a warning to the next map.
> > It was never gradually, it was almost instantly. But result may vary :-)
> >
> > -Original Message-
> > From: hlds_linux-boun...@list.valvesoftware.com 
> > [mailto:hlds_linux-boun...@list.valvesoftware.com ] On
> > Behalf Of Kyle
> > Sanderson
> > Sent: maandag 24 december 2012 7:05
> > To: Half-Life dedicated Linux server mailing list
> > Subject: Re: [hlds_linux] Engine error: ED_Alloc: no free edicts
> >
> > Unfortunately those convars aren't helpful, maybe if you're gradually
> > reaching the limit they may work. Something like a round reset will still
> > totally crash the server.
> >
> > Thanks,
> > Kyle.
> >
> >
> > On Sun, Dec 23, 2012 at 3:54 PM, Erik-jan Riemers  
> > >
> > wrote:
> >
> > > The ones I was talking about..
> > >
> > > sv_lowedict_action 0 - no action, 1 - warn to log file, 2 - attempt to
> > > restart the game, if applicable, 3 - restart the map, 4 - go to the
> > > next map sv_lowedict_threshold 8 - When only this many edicts are
> > > free, take the action specified by sv_lowedict_action.
> > >
> > > I've even seen idle servers crash on low eddicts (cannot get any more
> > > tiny map / low eddicts then an idle map)
> > >
> > > But for instance, saxton hale servers are my nr 1 troublemaker when it
> > > comes to the most amounts.. (heavy mods and such)
> > >
> > > -Original Message-
> > > From: hlds_linux-boun...@list.valvesoftware.com 
> > > [mailto:hlds_linux-boun...@list.valvesoftware.com ] On
> > Behalf Of Essay
> > > Tew Phaun
> > > Sent: zondag 23 december 2012 17:59
> > > To: Half-Life dedicated Linux server mailing list
> > > Subject: [hlds_linux] Engine error: ED_Alloc: no free edicts
> > >
> > > Just had a crash with this and I don't ever remember having a crash
> > > because of running out of edicts before. Anyone else experience this
> > > lately?
> > > ___
> > > 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
> >
> > ___
> > To unsubscribe, edit your list preferences, or view the list archives,
> > please visit:
> > https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
> >
>
>
> --
>
>
> Kind regards,
> Saul Rennison
> ___
> 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] Engine error: ED_Alloc: no free edicts

[Essay Tew Phaun]

Those will help, thanks!

On Sun, Dec 23, 2012 at 6:54 PM, Erik-jan Riemers  wrote:

> The ones I was talking about..
>
> sv_lowedict_action 0 - no action, 1 - warn to log file, 2 - attempt to
> restart the game, if applicable, 3 - restart the map, 4 - go to the next
> map
> sv_lowedict_threshold 8 - When only this many edicts are free, take the
> action specified by sv_lowedict_action.
>
> I've even seen idle servers crash on low eddicts (cannot get any more tiny
> map / low eddicts then an idle map)
>
> But for instance, saxton hale servers are my nr 1 troublemaker when it
> comes to the most amounts.. (heavy mods and such)
>
> -Original Message-
> From: hlds_linux-boun...@list.valvesoftware.com
> [mailto:hlds_linux-boun...@list.valvesoftware.com] On Behalf Of Essay Tew
> Phaun
> Sent: zondag 23 december 2012 17:59
> To: Half-Life dedicated Linux server mailing list
> Subject: [hlds_linux] Engine error: ED_Alloc: no free edicts
>
> Just had a crash with this and I don't ever remember having a crash
> because of running out of edicts before. Anyone else experience this
> lately?
> ___
> 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] Engine error: ED_Alloc: no free edicts

[Essay Tew Phaun]

As long as a 32 player server can be set without "hacks" any issues that
arise should still be fixed.

On Sun, Dec 23, 2012 at 4:05 PM, ics  wrote:

> There is no fix. There is limited mount of edicts out there and making the
> game over 24 slot server or using some plugins that create extra entities
> will cause the edicts to fill up and crash the server.
>
> Maps generally have under 1400 dynamic entities (limit is 2047), on top of
> that goes all items, rockets, etc dynamic entities that are generated on
> the fly. The more players there are, the more entities there are. Thats why
> larger servers and plugin heavy ones will crash first. I haven't seen a
> crash for ages on my servers but my own client crashes every 2-4 maps and
> always on mapchange. Though i run only 24 slot servers these days on TF2,
> so i won't go over the limit that easily.
>
> -ics
>
> 23.12.2012 21:27, Erik-jan Riemers kirjoitti:
>
>  I have it from time to time, even on stock maps. It is something I cannot
>> fix , there is no real fix for it either.
>>
>> There is however a setting that you can say that if it occurs, it will
>> restart the server or change maps (to get back to normal) cannot recall
>> the settings 1.2.3. but I usually set it to changelevel so that if it
>> occurs its better than having all the clients enduring a crash.
>>
>> -Original Message-
>> From: 
>> hlds_linux-bounces@list.**valvesoftware.com
>> [mailto:hlds_linux-bounces@**list.valvesoftware.com]
>> On Behalf Of Essay Tew
>> Phaun
>> Sent: zondag 23 december 2012 17:59
>> To: Half-Life dedicated Linux server mailing list
>> Subject: [hlds_linux] Engine error: ED_Alloc: no free edicts
>>
>> Just had a crash with this and I don't ever remember having a crash
>> because of running out of edicts before. Anyone else experience this
>> lately?
>> __**_
>> To unsubscribe, edit your list preferences, or view the list archives,
>> please visit:
>> https://list.valvesoftware.**com/cgi-bin/mailman/listinfo/**hlds_linux<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<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<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] Engine error: ED_Alloc: no free edicts

[Essay Tew Phaun]

Can we get a TF2 Sync?

On Sun, Dec 23, 2012 at 3:25 PM, Kyle Sanderson  wrote:

> It's not a fix, but a workaround. While it works for CS:S and probably
> every other game, on TF2 (Randomizer) users have problems. There's still
> threading bugs that can be fixed, and the hack I did probably provokes
> them. As well to this, there is probably a more elegant way to correct the
> problem, but I get months of uptime now, and maps are playable again.
> Provided I don't miss to many frames, things are cool. The method of
> releasing was probably my bad, at the time I just wanted to help others
> (Anyone running a server) with the same problem I was having daily.
>
> Thanks,
> Kyle.
>
>
> On Sun, Dec 23, 2012 at 12:11 PM, Essay Tew Phaun 
> wrote:
>
> > This is the part where we say "Well, looks like Valve will need to fix it
> > then" and this post gets lost or buried and never addressed.
> > ___
> > 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] Engine error: ED_Alloc: no free edicts

[Essay Tew Phaun]

This is the part where we say "Well, looks like Valve will need to fix it
then" and this post gets lost or buried and never addressed.
___
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] Engine error: ED_Alloc: no free edicts

[Essay Tew Phaun]

Just had a crash with this and I don't ever remember having a crash because
of running out of edicts before. Anyone else experience this lately?
___
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] TF2 empty servers

[Essay Tew Phaun]

Our community has an entire team of players who play together to get the
servers seeding. It's pretty pointless, unless your server is insanely
popular already, to attempt to seed the servers during the weekdays before
about 2PM EST or so. From them on though, if you can get a good 5v5 or 6v6
going, your server will fill up reliably. I have noticed that they're much
harder to fill lately though. I guess that's just the way it will be until
more players begin playing or come back.
___
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] Running a Halloween Server

[Essay Tew Phaun]

I like hammers. I also like wrenches. I shall create a hlds post about my
toolbox. Don't like it? Filter it.

On Thu, Nov 15, 2012 at 8:41 PM, HWDOMD  wrote:

> Better yet, take it off the mailing list because it's not here to give you
> an audience. You want the attention you feel you deserve? Take your
> grandstanding bullshit to the forum, I'm sure they'll even pitch in.
>
> Maybe it's time the Valve folks started laying the hammer down on some of
> you people.
>
> -Original Message-
> From: hlds_linux-boun...@list.valvesoftware.com
> [mailto:hlds_linux-boun...@list.valvesoftware.com] On Behalf Of Cameron
> Munroe
> Sent: Thursday, November 15, 2012 5:33 PM
> To: Half-Life dedicated Linux server mailing list
> Subject: Re: [hlds_linux] Running a Halloween Server
>
>
>
> Then create a filter in your email and stop blaming us for the
> conversation. Hell make another email account just for this email list.
>
>
> On , PolyQuad wrote:
>
> > You are definitely not alone on this
> >
> >
> -Original Message-
> > From:
> hlds_linux-boun...@list.valvesoftware.com
> >
> [mailto:hlds_linux-boun...@list.valvesoftware.com] On Behalf Of HWDOMD
> >
> Sent: Thursday, November 15, 2012 4:48 PM
> > To: 'Half-Life dedicated
> Linux server mailing list'
> > Subject: Re: [hlds_linux] Running a
> Halloween Server
> >
> > Can this discussion be held somewhere else? Like
> the forum, where it's
> > supposed to be?
> >
> > This isn't the place for it
> and I'm getting a little sick of having my inbox
> > filled with your
> petty bullshit back and forth about nothing. I'm pretty
> > sure I'm not
> alone in this.
> >
> > -Original Message-
> > From:
> hlds_linux-boun...@list.valvesoftware.com
> >
> [mailto:hlds_linux-boun...@list.valvesoftware.com] On Behalf Of dan
> >
> Sent: Thursday, November 15, 2012 4:04 PM
> > To: Half-Life dedicated
> Linux server mailing list
> > Subject: Re: [hlds_linux] Running a
> Halloween Server
> >
> > On 15/11/2012 20:21, Rudy Bleeker wrote:
> >
> >> I
> hope I speak for most people when I say that I don't see the problem
> here. If you don't like to play King of the Hill, then don't play on
> servers with KOTH maps in their rotation.
> >
> > I do like to play KOTH
> occasionally. It's not the worse game mode put it
> > that way.
> >
> > But
> on the map they changed that you couldn't really do that. I think the
> >
> first Halloween event did koth - and did it in such a way that running
> >
> around killing people generally worked - in fact, was made part of it
> -
> > hence yes, to me it would have made more sense to pick a different
> game mode
> > this time but it was moot anyway given the, imo bad decision
> to make these
> > bonuses like uber and crits apply to both teams.
> >
> >
> But I've already said that and I'm not repeating everything because
> you
> > didn't read it :-)
> >
> > Again, things were not really free, that's
> a misnomer (perhaps it's worth
> > noting that if Valve's whole modus
> operandi is to take feedback from its
> > customers, and you think you're
> not paying for anything then you should
> > realise that this just means
> you aren't their customer.
> >
> > Hence if you really are "speaking for
> most people" none of what we say
> > counts, does it? :-)
> >
> > They are
> developing and updating their games to cater for the people that do
> >
> pay. Hence one of my points, I'd much prefer - I'd far prefer - a game
> that
> > had something I wanted to buy in it and that was therefore
> targeted at
> > people who want to play it rather than people who clearly
> don't.
> >
> > You can't keep saying "it's free", when all you're really
> saying is "other
> > people are paying for TF2, not us, and Valve change
> the game to get their
> > money rather than ours"
> >
> > I cannot (as I also
> think I pointed out too) really play the game as I
> > always have -
> that's another point I made (although for a while, shortly
> > after F2P,
> as I said on this list at the time, TF2 was actually far, far
> > better
> than it ever was, even at launch in 2007 when it was new and fresh.
> >
> >
> Perhaps simply because of the numbers and the myriad servers to pick
> from
> > and in spite of the general TF2 communities rather asinine and
> ugly reaction
> > to the new players - and their continuing use of the
> term "F2P" to be
> > derogatory.
> >
> > It's even more ironic that you keep
> parroting how the game is "free"
> > given the rather hostile reaction
> >
> a lot of F2P people received because they supposedly hadn't paid.
> >
> >
> Evidently, it's not the most logical community in existence.
> >
> > In a
> lot of ways sheer numbers hid the worst issues with the changes they
> >
> made prior to the game going F2P and I suppose MvM has just made them
> >
> obvious again, whilst being, imo, nowhere near as good as it could have
> been
> > in terms of difficulty and skill required and in terms of the
> number of
> > people needed to play it.
> >
> > For y

Re: [hlds_linux] Server Crashes

[Essay Tew Phaun]

I have some non-MvM servers that get stuck occasionally at 100+% CPU that I
have to forcefully kill. I wonder what causes this..
___
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] Vote scramble without resetting time/round limit

[Essay Tew Phaun]

There needs to be an option to wait until the end of the round :/

On Sat, Nov 10, 2012 at 8:46 AM, Jeff Sugar  wrote:

> Unfortunately, there isn't (or, at least there wasn't as of the last time I
> checked). That's actually the original reason that plugins like gScramble
> were even created
> On Nov 10, 2012 3:42 AM, "Yun Huang Yong"  wrote:
>
> > When players do a scramble vote (the in-built one, not any mod) the timer
> > & rounds reset.
> >
> > Is there a setting to not reset these when a scramble vote is successful?
> >
> > TIA,
> > Yun
> >
> > __**_
> > To unsubscribe, edit your list preferences, or view the list archives,
> > please visit:
> > https://list.valvesoftware.**com/cgi-bin/mailman/listinfo/**hlds_linux<
> 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] Lag?

[Essay Tew Phaun]

Let me also say that this doesn't just appear to be network lag only.
Something else seems to be going on.
___
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] Lag?

[Essay Tew Phaun]

Yes, quite a lot. I know there are others on the list reporting it and
there have been a few other posts on it too. They said they're looking in
to it.
___
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] Anyone still getting clients with STEAM_ID_PENDING?

[Essay Tew Phaun]

I'm having several mods on our server fail to function properly because
clients are coming on to the server with their steamids in this state.
Looks like this was an issue about a week back but I'm still having clients
with this. It's not a firewall issue either.
___
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] Game timer completely vanished.

[Essay Tew Phaun]

Okay, more details. It happened in the middle of setup on the first stage
of Dustbowl.
___
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] Game timer completely vanished.

[Essay Tew Phaun]

This happened again today, no one else has this?
___
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] Optional Team Fortress 2 update released

[Essay Tew Phaun]

Our Dustbowl server is experiencing some spikes and lag that we never
experienced before this update. It seems all of them are, but I mostly play
on that server. Our KOTH server is also doing it. I'm not even sure it's
map specific. I just think something about the update has borked something.
___
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] Is there any information we can provide to Valve to help resolve the recent server performance issues?

[Essay Tew Phaun]

We've noticed our servers acting very poorly after the Halloween update.
Our servers were pretty smooth prior, now players are reporting a lot of
random freezing issues and I'm noticing a lot of gaps in my own net_graph
report. I did not observe any of this prior to the Halloween update. Both
of our systems run CentOS. One is 6.2 64bit and the other 6.3 32bit.

Are there any details we can further provide to help rectify this issue?

http://i.imgur.com/f7UnP.png
___
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] Optional Team Fortress 2 update released

[Essay Tew Phaun]

Well, we're getting it on Linux so we can at least rule out (Maybe?) an OS
specific issue.
___
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] Optional Team Fortress 2 update released

[Essay Tew Phaun]

I'm having lag on PvP servers, I don't think it's just an MvM thing.
___
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] Optional Team Fortress 2 update released

[Essay Tew Phaun]

Same here, getting random stuttering problems. Seems to run okay, but has
random hiccups.

On Sat, Oct 27, 2012 at 6:41 PM, Pieter-bas Ronner wrote:

> Eric,
>
> We have also some lag problems since the last patch. is this also a bug in
> tf2?
>
> 2012/10/28 Eric Smith 
>
> > We've released an optional (for dedicated servers) update for Team
> > Fortress 2. The notes for the update are below.
> >
> > -Eric
> >
> > --
> >
> > Source Engine Changes (TF2, DoD:S, HL2:DM)
> > - Fixed a regression in the Mac's minimum system check
> >
> > Team Fortress 2
> > - Added new audio lines for Merasmus to use when he attacks
> > - Fixed a Linux dedicated server crash related to Mann vs. Machine mode
> >
> >
> > ___
> > 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] MVM Crash

[Essay Tew Phaun]

Hard to remember but I'm pretty sure of it. It may of been the unlimited
sentry exploit that got patched on a Saturday and returned Sunday with
another method.

On Sat, Oct 27, 2012 at 11:53 AM, Cameron Munroe
wrote:

> When?
>
>
> On 10/27/2012 8:53 AM, Essay Tew Phaun wrote:
>
>> Not true, they have.
>>
>> On Sat, Oct 27, 2012 at 11:32 AM, Cameron Munroe
>> **wrote:
>>
>>  No.
>>>
>>>
>>> On 10/27/2012 8:31 AM, Ourprop wrote:
>>>
>>>  Has valve ever released a patch on Saturday? Ive been running my group
>>>> about a year and a half and cant really remember if they ever have? For
>>>> some reason, its always a friday night content release and no word until
>>>> Monday and a fix on Wednesday.
>>>>
>>>> ___
>>>>
>>>> To unsubscribe, edit your list preferences, or view the list archives,
>>>> please visit:
>>>> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/***
>>>> *hlds_linux<https://list.**valvesoftware.com/cgi-bin/**
>>>> mailman/listinfo/hlds_linux<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<https://list.**valvesoftware.com/cgi-bin/**
>>> mailman/listinfo/hlds_linux<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<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<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] MVM Crash

[Essay Tew Phaun]

Not true, they have.

On Sat, Oct 27, 2012 at 11:32 AM, Cameron Munroe
wrote:

> No.
>
>
> On 10/27/2012 8:31 AM, Ourprop wrote:
>
>> Has valve ever released a patch on Saturday? Ive been running my group
>> about a year and a half and cant really remember if they ever have? For
>> some reason, its always a friday night content release and no word until
>> Monday and a fix on Wednesday.
>>
>> __**_
>> 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

[hlds_linux] Game timer completely vanished.

[Essay Tew Phaun]

I've never had this happen before but our Dustbowl server's timer just
completely disappeared. The setup gates wouldn't open and nothing ever
happened. The only solution was to use mp_restartgame.

Anyone else seeing this?
___
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] Sourcemod?

[Essay Tew Phaun]

https://forums.alliedmods.net/attachment.php?attachmentid=111404&d=1351298994

On Sat, Oct 27, 2012 at 12:24 AM, Cameron Munroe
wrote:

> Alright I can confirm that the two Dev builds for Sourcemod and Metamod
> work, as well as tf2items.
>
>
> However where is sdkhooks? I have looked around and cant find it.
>
>
> On 10/26/2012 8:30 PM, Steven Sumichrast wrote:
>
>> I have this running on over a dozen Debian boxes right now:
>>
>> meta version
>> Metamod:Source version 1.10.0-dev
>> Build ID: 809:6375d8da3383-dev
>> Loaded As: Valve Server Plugin
>> Compiled on: Oct 26 2012
>> Plugin interface version: 15:14
>> SourceHook version: 5:5
>> http://www.metamodsource.net/
>> sm version
>>   SourceMod Version Information:
>>  SourceMod Version: 1.5.0-dev+3672
>>  SourcePawn Engine: SourcePawn 1.1, jit-x86 (build 1.5.0-dev+3672)
>>  SourcePawn API: v1 = 4, v2 = 4
>>  Compiled on: Oct 26 2012 17:12:55
>>  Build ID: 3672:90afa8e17110
>>  http://www.sourcemod.net/
>> My gamedata was auto-updated to resolve some crashing.
>>
>> On Fri, Oct 26, 2012 at 10:28 PM, Nicholas Hastings <
>> psycho...@alliedmods.net> wrote:
>>
>>  MM:S  1.10.0-hg809  and  SM  1.5.0-hg3675 are working just fine.
>>>
>>> If you have issues with plugins loaded, it's from a third-party plugin or
>>> extension.
>>>
>>>
>>> On 10/26/2012 11:26 PM, Cameron Munroe wrote:
>>>
>>>  Which version?

 On 10/26/2012 8:26 PM, Benedict Glover wrote:

  Not for me on linux they don't. Fresh install, freezes like I said on
> that mapchange thing.
>
>
>
>  ___
 To unsubscribe, edit your list preferences, or view the list archives,
 please visit:
 https://list.valvesoftware.com/cgi-bin/mailman/listinfo/***
 *hlds_linux
 >

  --
>>> Nicholas Hastings
>>> AlliedMods.net 
>>> ___
>>> To unsubscribe, edit your list preferences, or view the list archives,
>>> please visit:
>>> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/***
>>> *hlds_linux>> 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
>
___
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] Mandatory TF2, DoD:S, and HL2:DM updates released

[Essay Tew Phaun]

- Added mat_viewportupscale and mat_viewportscale to enable rendering the
world at a reduced resolution. ("mat_viewportupscale 1" and
"mat_viewportscale 0.5" will downscale world rendering by 50%.)

Is this something similar to the old mat_picmip cvars whereby you can make
your game textures look flat?
___
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] TF beta has been updated

[Essay Tew Phaun]

Not to be a derp, but by soon I assume you mean soon tonight?
___
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] Weird graphical glitches, happens randomly.

[Essay Tew Phaun]

Anyone have any idea what could cause this?

http://i.imgur.com/OeDcc.jpg
http://i.imgur.com/NOFCe.jpg

It happens from time to time on 2 separate systems. Both are Linux CentOS,
one is 32bit and the other is 64.

Happens to everyone in the game.
___
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] SourceTV crashing clients?

[Essay Tew Phaun]

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

Re: [hlds_linux] [hlds_announce] Mandatory Team Fortress 2 update released

[Essay Tew Phaun]

Speaking of weird visual things. Does anyone notice teleporters sometimes
appearing to go down, like the exit was destroyed but it actually just goes
in to the disabled animation for a moment and when you step on it the
animation changes to active and warps you through?
___
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] Quickplay not activating?

[Essay Tew Phaun]

Yeah I've noticed it has been slower lately but I figured it may just be
slower and not a problem with Quickplay. I thought about making a post here
on it but I know that Quickplay discussions offend certain people here.
___
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] Servers not able to log in to specified steam accounts.

[Essay Tew Phaun]

Been having this the past hour or so anyone else?
___
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] account : not logged in (Cannot locate owner's steam account)

[Essay Tew Phaun]

I'm Eastern USA.

On Tue, Sep 25, 2012 at 5:33 PM, Cameron Munroe
wrote:

> Where are you?
>
>
> On 9/25/2012 2:30 PM, Calvin Judy wrote:
>
>> Not in europe, same issue.
>>
>> __**
>> Level 3 Technician
>> Griffin Networks LLC - Gaming Solutions
>>
>>
>
> __**_
> 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] account : not logged in (Cannot locate owner's steam account)

[Essay Tew Phaun]

Same here, ours can sit forever without reconnecting. It only fixes itself
when we restart it.

On Tue, Sep 25, 2012 at 4:43 PM, ics  wrote:

> Same for me (europe, Finland). Might be that they reconnect fast (well,
> some of them) and might just be that 3/4 are sitting with "cannot locate
> owners Steam account" for many many maps.
>
> -ics
>
> 25.9.2012 23:22, Saint K. kirjoitti:
>
>  That's definitely not what we're seeing here. Ours can sit unconnected
>> for hours in a row.
>> __**__
>> From: 
>> hlds_linux-bounces@list.**valvesoftware.com[
>> hlds_linux-bounces@list.**valvesoftware.com]
>> On Behalf Of Cameron Munroe [cmun...@cameronmunroe.com]
>> Sent: 25 September 2012 22:18
>> To: Half-Life dedicated Linux server mailing list
>> Subject: Re: [hlds_linux] account : not logged in (Cannot locate owner's
>> steam account)
>>
>> Mine usually retry within 15 minutes or less.
>>
>>
>> On 9/25/2012 1:17 PM, ics wrote:
>>
>>> My servers do reconnect (at some point) but sometimes only rebooting
>>> will give an instant fix. Most of the time it can be couple of maps
>>> before they even think about reconnecting.
>>>
>>> -ics
>>>
>>>
>>> 25.9.2012 23:10, Cameron Munroe kirjoitti:
>>>
 I have a lingering opinion that there might be something different
 about the European servers, though I'm still not sure. I have argued
 before that I have little to no issues with my servers and the steam
 servers, but yet people keep stating I'm wrong.So I think it
 might be location instead.

 On 9/25/2012 1:05 PM, Saint K. wrote:

> Wait,
>
> Perhaps I should pay more attention when reading an e-mail
>
> We're located in Europe, lol.
>
> Saint K.
> __**__
> From: 
> hlds_linux-bounces@list.**valvesoftware.com
> [hlds_linux-bounces@list.**valvesoftware.com]
> On Behalf Of Saint K.
> [sai...@specialattack.net]
> Sent: 25 September 2012 22:04
> To: Half-Life dedicated Linux server mailing list
> Subject: Re: [hlds_linux] account : not logged in (Cannot locate
> owner's steam account)
>
> Well, last time I checked I wasn't floating, so I'm not in space if
> you mean that? ;)
> __**__
> From: 
> hlds_linux-bounces@list.**valvesoftware.com
> [hlds_linux-bounces@list.**valvesoftware.com]
> On Behalf Of Cameron
> Munroe [cmun...@cameronmunroe.com]
> Sent: 25 September 2012 21:48
> To: Half-Life dedicated Linux server mailing list
> Subject: Re: [hlds_linux] account : not logged in (Cannot locate
> owner's steam account)
>
> My servers seem to reconnect no problem, where are you guys in the
> world?
>
>
> On 9/25/2012 12:33 PM, ics wrote:
>
>> It's basically the same as with clients. Steam reboot is required to
>> get connection to Steam renewed (and items working again). For
>> servers, reboot or wait for some random challenge from Steam to get it
>> back logged in. Could be usefull if some command to reconnect would be
>> introduced. There's potential risks of spamming such thing but making
>> it work only for registered servers would be a plus.
>>
>> -ics
>>
>> 25.9.2012 22:12, Saint K. kirjoitti:
>>
>>> Our servers are starting to drop off the quickplay more and more
>>> these days.
>>>
>>> @VALVe
>>>
>>> Would it be possible to add a re-connect sequence to srcds in case
>>> this behaviour occurs? Only a reboot seems to reconnect the servers
>>> right now.
>>>
>>> Saint K.
>>> __**_
>>> 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
>
> __**_
> To unsubscribe, edit your list preferences, or view the list
> archives, please visit:
> https://list.valvesoftware.**com/cgi-bin/mailman/listinfo/**hlds_linux
>
> __**_