Then the simple solution would be to check playercount by system each time sv_maxvisibleplayers is being changed.

-ics

Valentin G. kirjoitti:
I know servers that do this, and I wanted to know if this is punished or
not.

They just start 32 player servers and have sv_visiblemaxplayers at 24. Then
it's full and it's set to 26, then 28, 30, and finally to 32. That way they
have the lowest quickplay penalty (or none until 24) as long as possible,
circumventing the system.


On Wed, Feb 13, 2013 at 10:05 AM, ics <[email protected]> wrote:

I don't think anyone dynamically does this and even if they do, that
penalty will apply and rise with each extra slot above 24. I think some
server owners run a 24 slot server, and start the server with 6-8 extra
slots (maxplayers 30-32), using sv_visiblemaxplayers 24. This way servers
can have reserve slots or vip slots so that no one will be kicked off the
server if someone connects with such slot, unless the server is full.
Basically there can be 27/24 situations but i don't think quickplay will
drive in traffic if server is full (has 24 slots of 24 in use).

Only thing is that if slot count is 28/24 or even 25/24, Valve's system
will only detect this on mapchange or in some random time when check is
made. At that time, increased_maxplayers will be added and some other
message appears. It's the same if you lose connection to Steam servers and
then server regains it. Basically it's not cheating the system, it's just
convinient to have a few slots incase the server needs temporarely more
room.

Valve's recommendation is 24, so simple solution would be that if server
cvar sv_visiblemaxplayers is changed, Valve will check if it's over 24
slots or below and adds increased_maxplayers immediately, thus alerting
quickplay system and everyone should be happy, except the people who try to
avoid that tag.This also works two ways, if you have 27/24 players,
increased_maxplayers is added during mapchange, making the server 27/27 and
then the server loses 8 players, you will be left with 19/27 (or possibly
19/24) with increased_maxplayers tag, thus giving quickplay penalty.

-ics

Valentin G. kirjoitti:

  What happens to servers that dynamically change their
sv_visiblemaxplayers?
There are a bunch of servers that only advertise being a 24 slot server
and
then slowly grow to 32 to exploit quickplay as long as possible.


On Wed, Feb 13, 2013 at 7:47 AM, Kyle Sanderson <[email protected]>
wrote:

  Not in the least bit DWN, the data is gone. You can search the first
couple
tags, but once you blow the character limit (you know, from plugins, or
the
game itself), the last tags (depending on length here), usually just
contain garbage from the previously set tags. The request, unfortunately,
is still just noise unless if they do intend on fixing the problem.

Thanks,
Kyle.


On Tue, Feb 12, 2013 at 10:35 PM, DontWannaName! <[email protected]

wrote:
Cut off from view or cut off from quickplay? Are truncated tags

searchable?

Sent from my iPhone 5

On Feb 12, 2013, at 10:32 PM, "Doctor McKay" <[email protected]>
wrote:

I second this. I just had an issue applying tags in a plugin due to the
truncation issue. At the present moment, it's not feasable for plugins
to
force tags (such as respawntimes, friendlyfire, etc) since the tag might
end up getting cut off.

Dr. McKay
http://www.doctormckay.com


----- Original Message -----
*From:* Kyle Sanderson <[email protected]>
*To:* Half-Life dedicated Win32 server mailing list<

[email protected]>; Half-Life

dedicated Linux server mailing list <hlds_linux@list.**
valvesoftware.com <[email protected]>>
*Sent:* Wednesday, February 13, 2013 12:29 AM
*Subject:* Re: [hlds] Reminder about server tags

   Unfortunately, I don't believe anything has changed since you
requested
this last year Fletcher. I could be totally wrong, but the truncation

issue

still exists (today, I checked). This is still, absolutely impossible to
achieve if you're a server owner. Valve has to either raise the
character
limit, or move to another method of applying tags. I'd love to have all

my

server tags show, but they're still getting cut off. I'm not really that
concerned with prioritizing tags to the front.

Thanks,
Kyle.

---------- Forwarded message ----------
From: Kyle Sanderson <[email protected]>
Date: Thu, Jan 5, 2012 at 4:42 PM
Subject: Re: [hlds] Plugins that modify game ruels should also set the

tags

To: Half-Life dedicated Win32 server mailing list <
[email protected]>, Half-Life dedicated Linux server mailing
list <hlds_linux@list.**valvesoftware.com<[email protected]>

Sorry for the previous email, I wasn't at home. The overflow seems to

have

been worked around by hard limiting to 127 characters. Can this actually
get fixed instead of the current inplace hack? At the moment, it's

whomever

loads first gets their tags set, and the rest are left out to dry. I

should

probably also mention that tags are overwriting other tags at the moment

if

there's no room, which is of course gross.


No one can actually comply with this,
Kyle.


On Tue, Feb 12, 2013 at 7:42 PM, Fletcher Dunn <
[email protected]> wrote:

    Hello all,
This is a reminder to make sure that your properly advertises the
appropriate tags (e.g. respawntimes, norespawntime, friendly,

nodmgspread ,
nocrits, and increased_maxplayers), when the associated gameplay changes
are in effect.****

****

If you are using a plugin to achieve these changes, the plugin should

set
the tag.****
****

Your humble servant,****

Fletch****

______________________________**_________________
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.**com/cgi-bin/mailman/listinfo/**hlds<https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds>


    ------------------------------
______________________________**_________________
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.**com/cgi-bin/mailman/listinfo/**hlds<https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds>

______________________________**_________________
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.**com/cgi-bin/mailman/listinfo/**hlds<https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds>


______________________________**_________________
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.**com/cgi-bin/mailman/listinfo/**hlds<https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds>


  ______________________________**_________________
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


_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux

Reply via email to