An update has been released. - Removed the ability for servers to kick arbitrary players
Dr. McKay www.doctormckay.com On Thu, Feb 6, 2014 at 3:01 AM, 1nsane <[email protected]> wrote: > Personally I have plenty of hidden slots so no one ever needs to get > kicked. > > But what's to prevent someone from kicking players who joined through the > server browser instead and leave quickplay players alone? > > Does this satisfy the requirements? And if not, who would even know how > this works? How can valve possibly figure this out? How is this different > from what we had with the previous quickplay implementation? > > It would be really unfortunate if the people who followed these rules > ended up with a disadvantage because valve doesn't enforce it. Worse yet > I'd hate it for valve to take more nuclear action to deal with it and > punish all those who follow the rules. > > I hope there's more to this than we are seeing at the moment. But who > knows... All I know is that there's a 100% chance someone will abuse this > system regardless of what valve says. Will we end up being punished again > because of what those people do? > > > On Thu, Feb 6, 2014 at 2:48 AM, Yun Huang Yong <[email protected]>wrote: > >> Not specifically but I'd suggest the main reason for wanting to qualify >> for Quickplay is to keep servers filled. From that POV those Quickplay >> players *are* valuable to your community. You shouldn't turn around and >> punt them because their job is now done. >> >> For newer players -- the typical Quickplay user -- it's a pretty >> confusing and negative experience. I get kicked for... playing the game >> like everyone else? >> >> Personally I've never liked reserved slots, and it was one of the reasons >> I started my servers. Either I am a valued member of your community and you >> treat me with the same basic respect as everyone else (assuming I behave >> appropriately), or I'm not. Don't use me to populate your servers then >> throw me away. >> >> >> On 6/02/2014 6:25 PM, Doctor McKay wrote: >> >>> It's not like people discriminate against Quickplay users when >>> determining someone to kick for a reserved slot. It's not unreasonable >>> for donors to be given priority access to the server that they are >>> financially supporting (same with admins as they're supporting it with >>> their volunteer efforts). >>> >>> >>> Dr. McKay >>> www.doctormckay.com <http://www.doctormckay.com> >>> >>> >>> >>> On Thu, Feb 6, 2014 at 2:06 AM, Yun Huang Yong <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> I think the spirit of the "Kicking players to make room for reserved >>> slots" item is really about treating Quickplay players with respect. >>> >>> i.e. don't treat Quickplay players simply as seat warmers until your >>> regulars/donors/admins feel like joining into a full server >>> populated because of Quickplay. >>> >>> >From an enforcement POV there are obviously ways around many of >>> the Quickplay disqualification modifications. For this one it would >>> be pretty easy to tell by simply looking at the relevant groups' >>> donor perks. >>> >>> Of course some groups may attempt to subvert the system by secretly >>> have such a feature but not advertise it but that's a reasonable >>> outcome - if it makes it harder for server owners to do undesirable >>> things (such as selling reserved slots) that's still a win. >>> >>> >>> On 6/02/2014 5:20 PM, Andreas Grimm wrote: >>> >>> ..." Kicking players to make room for reserved slots" >>> >>> How does this check work? >>> >>> What happens, when an admin kicks a player for flaming and that >>> player >>> reports the server with "they kicked me to make room for >>> reserved slots"? >>> >>> Same with plugins like anti cheat - Our anti cheat system stores >>> dectected cheaters in a database and it kicks the players when >>> they >>> connect to a server of our network or when they use cheats while >>> playing. Usually we also send a kick message like "you are >>> banned for >>> using cheats bla bla", but a kicked player could easily say >>> "they make >>> room for reserved slots" >>> >>> - Andreas >>> >>> *From:*hlds-bounces@list.__valvesoftware.com >>> <mailto:[email protected]> >>> [mailto:hlds-bounces@list.__valvesoftware.com >>> >>> <mailto:[email protected]>] *On Behalf Of >>> *Fletcher Dunn >>> *Sent:* Thursday, February 06, 2014 12:52 AM >>> *To:* Half-Life dedicated Win32 server mailing list >>> >>> ([email protected] >>> <mailto:[email protected]>); Half-Life dedicated Linux >>> server mailing >>> list (hlds_linux@list.__valvesoftware.com >>> <mailto:[email protected]>); >>> hlds_announce@list.__valvesoftware.com >>> <mailto:[email protected]> >>> >>> *Subject:* [hlds] Important changes to TF2 coming soon >>> >>> >>> There are some changes coming that TF2 server operators should >>> know about. >>> >>> CHANGES TO QUICKPLAY >>> >>> ------------------------------__- >>> >>> >>> The next TF2 update will make two changes to quickplay: >>> >>> * "Show servers" button. This runs the ordinary quickplay >>> search, but >>> instead of joining the server with the highest score, it >>> presents the >>> user with an ordered list of about 20 servers and lets them >>> pick. This >>> gives players much of the convenience of quickplay by finding >>> servers >>> with a good ping and players on them, but also an easy way to >>> express a >>> preference over the map, server community, etc. >>> >>> * We've added an advanced options page that allows players to >>> opt into >>> the most commonly-requested non-vanilla rules changes: nocrits, >>> maxplayers, and instant respawn. >>> >>> There are no more scoring penalties for maxplayers or rule >>> changes; your >>> server either matches their search criteria or it doesn't. >>> >>> At this time, we are keeping the default quickplay option to >>> Valve >>> servers. However, note that if a player wants to find a server >>> with any >>> of the supported modifications, then they must land on a >>> community >>> server, since Valve servers do not run with these settings. >>> >>> We've updated the quickplay policy to more clearly specify what >>> sorts of >>> server modifications are allowed in quickplay: >>> >>> https://support.steampowered.__com/kb_article.php?ref=2825-_ >>> _AFGJ-3513 >>> >>> <https://support.steampowered.com/kb_article.php?ref=2825- >>> AFGJ-3513> >>> >>> STEAM GAMESERVER ACCOUNTS >>> >>> ------------------------------__----------- >>> >>> >>> Gameserver accounts are now a Steam feature. The feature is >>> currently >>> in beta. >>> >>> Using a steam gameserver account provides one important >>> advantage right >>> now: client favorite lists are keyed by the Steam account if >>> present. >>> This means that you can move your server to another IP address, >>> and >>> clients who have your server in their favorites or history will >>> follow >>> you to your new location. >>> >>> CREATING AN ACCOUNT: >>> >>> Creating an account is currently only possible via WebAPI. >>> (Remember, >>> this feature is currently in beta. We'll add a nicer interface >>> for this >>> soon.) Make a HTTPS POST request to the following URL: >>> >>> https://api.steampowered.com/__IGameServersService/__ >>> CreateAccount/v0001/ >>> >>> <https://api.steampowered.com/IGameServersService/ >>> CreateAccount/v0001/> >>> >>> The POST arguments should be: >>> >>> appid=440 (for Team Fortress) >>> >>> key=<your WebAPIKey> >>> >>> <your WebAPIKey> is the WebAPI key associated with the user >>> account that >>> will own the server accounts. See http://steamcommunity.com/dev >>> for how >>> to get one of these. (WARNING: Make sure and keep this key >>> secret. >>> This key is an authentication token in some respects and makes it >>> possible to do certain actions on your behalf. Don't feed the >>> key into >>> anybody's nice convenient web page that automates this. With >>> your >>> WebAPI key they could impersonate you for some actions. If you >>> don't >>> want to go through the pain of making a WebAPI call, just wait >>> until we >>> have a nicer interface implemented.) >>> >>> The output of the WebAPI will be the (permanent) SteamID of your >>> gameserver, and a login token. The login token is a random >>> string of >>> text that allows you to actually login to your account. >>> >>> You can view a list of the servers owned by a user account by >>> making a >>> HTTPS GET call to: >>> >>> https://api.steampowered.com/__IGameServersService/__ >>> GetAccountList/v0001/?key= >>> <https://api.steampowered.com/IGameServersService/ >>> GetAccountList/v0001/?key=><__yourkey >>> <https://api.steampowered.com/__IGameServersService/__ >>> GetAccountList/v0001/?key=%__3cyourkey >>> >>> <https://api.steampowered.com/IGameServersService/ >>> GetAccountList/v0001/?key=%3cyourkey>>> >>> >>> >>> LOGGING IN TO YOUR ACCOUNT (TF only for now): >>> >>> Once you have a gameserver login token, you can specify your >>> login >>> credentials on a Source engine server by executing this console >>> command >>> sometime before it loads the first map: >>> >>> sv_setsteamaccount <login token> >>> >>> The server output should make it clear when you are using a Steam >>> gameserver account and when you are logging in anonymously. (The >>> ordinary gameserver login that has always been used.) >>> >>> Remember, for now you will need to login to both your Steam >>> gameserver >>> account and also your TF account. The two accounts are not >>> related. >>> The TF account is the one that determines quickplay eligibility, >>> and the >>> Steam one does favorites migration. Eventually we will remove >>> the TF >>> accounts and only use Steam gameserver accounts. >>> >>> HOW FAVORITES MIGRATION WORKS: >>> >>> In the next few days we will release an updated Steam Client >>> beta that >>> knows how to migrate favorites. On the client, each favorite >>> has an >>> IP:port and a gameserver account. The account might be empty >>> --- that >>> will of course be the case for all previously existing favorites. >>> Periodically, a client will try to sync up the favorites list >>> IP:port >>> addresses and accounts. If there is an IP:port without an >>> associated >>> account, it will ask the master server for information about that >>> address. If a server is running on that address and logged into >>> an >>> account, the client will record the account. Once the client has >>> an >>> account associated with the favorite, the account becomes the >>> primary >>> key and will not change. Instead, we will periodically try to >>> refresh >>> the address from the account. (Again, this is done by querying >>> the >>> master server, and it depends on your server bring logged into >>> the >>> account and running on the address.) The client always caches >>> the last >>> known IP:port of a favorite, even though the account ID is the >>> main >>> "key". That way, if Steam is down, or the gameserver is down, >>> it will >>> used the cached IP:port. All of the above applies to history as >>> well as >>> favorites. >>> >>> In the future, when a client adds a favorite or history item, the >>> account will be recorded immediately. >>> >>> If you know you have many clients that have your server in their >>> favorites or history, then you should not move your server yet. >>> You >>> need to give clients time to logon with new Steam client >>> binaries and >>> get their favorite entry linked up with your account. We'll let >>> you >>> know when you can try out migrating favorites, as well as when >>> the >>> feature is active in the public client and all users have it. >>> >>> QUESTIONS? >>> >>> Since Steam gameservers are a Steam feature, all of the above >>> will apply >>> to all Steam games. (Provided that the game exposes a method >>> for the >>> gameserver to log in to an account.) Eventually, the TF2 >>> gameserver >>> accounts will be going away and replaced with these accounts. >>> For now, >>> they are separate. >>> >>> Any further questions about the quickplay changes or gameserver >>> accounts? Please direct them to this list so that all answers >>> will be >>> public. >>> >>> >>> >>> _________________________________________________ >>> >>> 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 >>> >>> >> >> _______________________________________________ >> To unsubscribe, edit your list preferences, or view the list archives, >> please visit: >> 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 > >
_______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds
