[Dr. McKay]

Originally Posted by PresidentEvil thats what I dont get, when I upped my slots from 32 to 40 my sv_tags line in server.cfg remained unchanged, the game never added any new tags, how could people remove the tags? edit: this is my JB tags in server.cfg: sv_tags jail, break, jailbreak, jb, hosties, custom, lr, custom, prison, rebel, 40 slots, 40 players, increased_maxplayers dont remember is it was me who added increased_maxplayers or the game but my newly made zombie server is also 40 slots and it doesnt have the increased_maxplayers tag zombie: sv_tags zombie, mod, reloaded, zr, zmarket, 40 slots, 40 players, escape, survival, custom, models

increased_maxplayers may be a TF2-specific thing. I don't know enough about CS:S.

[DarthNinja]

Originally Posted by PresidentEvil thats what I dont get, when I upped my slots from 32 to 40 my sv_tags line in server.cfg remained unchanged, the game never added any new tags, how could people remove the tags?

The game will never edit your config. Server-set tags are set directly.

[ddhoward]

Originally Posted by PresidentEvil how could people remove the tags?

By using plugins/extensions that are designed to force the removal of said tags. This is the point; you have to go OUT OF YOUR WAY to remove these tags. You can't do it by mistake. That being said, pretty much any server that has required tags removed is doing it intentionally.

[WebNoob]

Originally Posted by Powerlord While Asherkin gave the long explanation, here's the short one: It's lying to players.

Oh, I don't think changing a server's settings dynamically (such as slots or respawn times) is even remotely as cut and dried as that, nor do I think you are "lying to players" if you change a server's conditions from the one that they joined.

For example - let say that I run a set of TF2 servers that are 32-slot servers. As we all know, while having increased max slots does not disqualify you from quickplay traffic, altering respawn times does.

Now let's say to help fill that server I use a plugin that encourages players to invite their friends to the server, and encourages them towards that goal by telling them that fast respawn will be turned on once the server reaches "X" number of players. In both cases (when the server is at "stock" settings, and when fast respawn is turned on) I insure that ALL the correct sv_tags are set in the server browser to make sure I stay 100% compliant in setting the sv_tags that represent my server's current settings.

In that case, did I lie to the player's in any way? Just because a player joined my server when its settings were "stock", should I not be able to alter those settings?

What if, in the above scenario, fast respawn was enabled by player vote? As long as the proper tags are set, how is that in any way "lying" to anyone?

How about if I run 24-slot servers during the "off-peak" hours, but change them to 32-slot servers during the 4-5 hours of "peak" play to accommodate the increased player traffic (again, always insuring the correct tags are set)? Is that in any way dishonest? Hell no.

Taking that train of thought even further - what about servers that are a mix of stock & custom maps? Stock maps includes you in quickplay, while custom maps are prohibited from receiving quickplay traffic. If a quickplay player joined my CTF server on a stock map, and at the end of the round, a custom map came up in the rotation, did I "lie" to that player?

Of course not.

See my point? This is where I think people push the whole "policing of the community" a bit too far. Should operators that spoof players/use fake clients (or do anything else truly nefarious) get banned?

Of course they should - they are trying to cheat/game the system.

BUT - should legitimate server operators who alter their server's settings to accommodate what their players want get banned simply because their server's settings might get altered from what they were when quickplay dropped that player in there?

If you can actually say "yes" to that question, then I have to ask why you would even be reading this on a forum dedicated to the imaginative & creative customization of Source servers.

This is why changing a server's conditions "dynamically" (either through a plugin, by vote, or through any other means), shouldn't be a "grey area" at all - unless the end goal here is to simply marginalize and eliminate anything that isn't plain, stock, vanilla TF2.

As long as I'm setting ALL of the proper tags for whatever settings my server is currently running at the time, and not using anything nefarious to "fake" anything (fake clients/bots, etc.), then I should never "fear" changing a setting on my server simply because that is not what was set when those players first joined.

If Valve is going to go that far, they might as well say that running metamod/sourcemod eliminates you from quickplay eligibility all together and be done with it.

[Powerlord]

Originally Posted by WebNoob Oh, I don't think changing a server's settings dynamically (such as slots or respawn times) is even remotely as cut and dried as that, nor do I think you are "lying to players" if you change a server's conditions from the one that they joined. For example - let say that I run a set of TF2 servers that are 32-slot servers. As we all know, while having increased max slots does not disqualify you from quickplay traffic, altering respawn times does. Now let's say to help fill that server I use a plugin that encourages players to invite their friends to the server, and encourages them towards that goal by telling them that fast respawn will be turned on once the server reaches "X" number of players. In both cases (when the server is at "stock" settings, and when fast respawn is turned on) I insure that ALL the correct sv_tags are set in the server browser to make sure I stay 100% compliant in setting the sv_tags that represent my server's current settings. In that case, did I lie to the player's in any way? Just because a player joined my server when its settings were "stock", should I not be able to alter those settings? What if, in the above scenario, fast respawn was enabled by player vote? As long as the proper tags are set, how is that in any way "lying" to anyone? How about if I run 24-slot servers during the "off-peak" hours, but change them to 32-slot servers during the 4-5 hours of "peak" play to accommodate the increased player traffic (again, always insuring the correct tags are set)? Is that in any way dishonest? Hell no. Taking that train of thought even further - what about servers that are a mix of stock & custom maps? Stock maps includes you in quickplay, while custom maps are prohibited from receiving quickplay traffic. If a quickplay player joined my CTF server on a stock map, and at the end of the round, a custom map came up in the rotation, did I "lie" to that player? Of course not. See my point? This is where I think people push the whole "policing of the community" a bit too far. Should operators that spoof players/use fake clients (or do anything else truly nefarious) get banned? Of course they should - they are trying to cheat/game the system. BUT - should legitimate server operators who alter their server's settings to accommodate what their players want get banned simply because their server's settings might get altered from what they were when quickplay dropped that player in there? If you can actually say "yes" to that question, then I have to ask why you would even be reading this on a forum dedicated to the imaginative & creative customization of Source servers. This is why changing a server's conditions "dynamically" (either through a plugin, by vote, or through any other means), shouldn't be a "grey area" at all - unless the end goal here is to simply marginalize and eliminate anything that isn't plain, stock, vanilla TF2. As long as I'm setting ALL of the proper tags for whatever settings my server is currently running at the time, and not using anything nefarious to "fake" anything (fake clients/bots, etc.), then I should never "fear" changing a setting on my server simply because that is not what was set when those players first joined. If Valve is going to go that far, they might as well say that running metamod/sourcemod eliminates you from quickplay eligibility all together and be done with it.

The problem with changing things like fast respawn and maxplayers during the game is that it shifts the game's balance. It goes against the very spirit of what Quick Play is.

Not surprisingly, Valve's said this:

If we determine that there is abuse, we will penalize your server and may eventually remove it from the Quickplay pool.

It's up to them as to what's considered abuse, but don't be shocked if they consider adjusting settings that change QuickPlay scoring to be one such thing.

As for my participation in this community, changing maxplayers and fastrespawn is literally stuff that everyone and their mother can do. I work on things much more complicated than that.

[WebNoob]

Originally Posted by Powerlord The problem with changing things like fast respawn and maxplayers during the game is that it shifts the game's balance. It goes against the very spirit of what Quick Play is.

Funny, I always thought the "spirit" of qucikplay was to match the player with the best server that matches "a variety of factors such as: ping to the player, the player’s number of hours played, map, current number of players, maximum number of players, and a score we keep for the server." (taken from valve's own description).

Of course changing the server's setting changes the game's balance - so your argument is the only servers that should be allowed quickplay traffic are those that stay stock 100% of the time, and never dare to alter their settings? What if that is what the players wanted - and voted for? Should servers that allow their players to alter the settings by vote then by penalized for it?

How nuts would it be to get removed from the system for giving player's what they voted for?

This is why quickplay, as a whole, has (IMHO) been so harmful to TF2 in it's current implementation.

Think about it - Valve has all but said that any further content for TF2 will be generated by the community, yet by definition that very content (i.e. custom maps) is eliminated from what is rapidly approaching 50% of TF2's traffic (if not more) - insuring it never sees any real play testing unless it happens to get picked up on Valve's radar.

How many great maps are getting overlooked because they simply can't get any kind of sustained player traffic to help the author's refine and develop them? Back when pl_frontier was in early development, we ran it for a month straight on its own server to give the author a chance to tweak and refine it. due to quickplay, if we tried that today, we'd never be able to fill it for more than an hour or two.

Even worse - without quickplay there wouldn't be this scourge of pseudo-communities who exist purely to milk ad impressions from the system.

Quickplay could be such a valuable tool to the future of TF2 if it was done right. In my opinion, it should simply work like this:

- For your first 10-12 hours playing Tf2 as a new player, quickplay only connects you to "official/stock" TF2 servers.

- After that point, qucikplay's only job should be to connect you to the server with the very best ping (that does not appear on your personal blacklist). From there, the server scoring system would take over.

A couple of years ago Valve introduced what I thought was the absolutely most elegant and player-driven way to allow the "best" servers to rise to the top - the server scoring system. Valve was absolutely right in thinking that it's the players that should be determining the "value" of a server. By eliminating custom maps/settings from quickplay, they are actively stifling the very innovation that is keeping the game alive.

Anyhoo - I apologize for the rant - I don't mean to marginalize your opinion - I simply think that it's a mistake for valve to slowly but surely push all servers towards being "vanilla" or being left out all together - as it's killing the very thing that has given TF2 it's legs in the first place - the ability for players to find variety in the game.

/ end rant

[Smarmy]

You make a lot of great points WebNoob and I agree with almost all of them.

We had one of our servers delisted months ago because it went beyond 24 players and increased_maxplayers was not automatically set.

I think you've hit the nail on the head really. The problem is Valve will sometimes come out with these great ideas and seemingly abandon them. Quickplay scores also seem to be far too quick to go up and far too quick to go down. I'd like it if servers that have remained up and had a good score for a long time received additional bonuses.

Are servers even removed from the master list due to low reputations? I think I've read that they are not. What in the world was the point of that system again?

[11530]

@WebNoob It wouldn't be very quick if quickplay was to allow downloads. By very definition, it is there so people can join a server knowing that there are no extraneous files that are required. However I do agree it is harming the very paradigm of community-created content. I'd hope to one day find a setting called communityplay, or similar, which would be the polar opposite of quickplay and would connect you to any server on a custom map regardless of downloads though still weighted by factors like ping and current players.

[Dr. McKay]

Originally Posted by 11530 @WebNoob It wouldn't be very quick if quickplay was to allow downloads. By very definition, it is there so people can join a server knowing that there are no extraneous files that are required. However I do agree it is harming the very paradigm of community-created content. I'd hope to one day find a setting called communityplay, or similar, which would be the polar opposite of quickplay and would connect you to any server on a custom map regardless of downloads though still weighted by factors like ping and current players.

Or we could nuke it entirely and let people make informed decisions via the server browser.

Hell, the server browser even defaults to simple mode, which picks the lowest-ping server for each map it comes across.

[11530]

Originally Posted by Dr. McKay Or we could nuke it entirely and let people make informed decisions via the server browser. Hell, the server browser even defaults to simple mode, which picks the lowest-ping server for each map it comes across.

That's not quite the same as quickplay or "communityplay" though. You'd be explicitly picking a map which, as you said, is an informed decision. The purpose of the modes above are to forego informed decisions and let the program make an educated guess on a random stock or custom server, respectively, based on the factors previously mentioned.