[hlds] Quickplay & Community Servers - 6 Months in.
Dear TF2 Team, We are approaching the 6 month mark to what we had been told would be a temporary situation (i.e. the removal of community servers from Quickplay by default). To my knowledge - unless I missed something somewhere - there has not been any communication in those six months from the TF2 development team as to if/when we can expect to return to a level playing field in terms of how community servers are treated. At this point, it appears the change is permanent. If so, all I ask is that you communicate with us and let us know if that is indeed the case, and community servers will no longer receive equal treatment in the long term. In our case, we are hanging onto - and paying for - dedicated (ad-free) servers that have been online for over four years in the hopes that we might be able to see them repopulated again down the road...but again, if that will no longer be possible, it would simply be courteous to let us know so that we can let our community know we have to shut them down for good. Thank You.___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds
[hlds] Can we have a Quickplay Status report, please?
Dear TF2 team, Would it be possible for you to communicate a status as to if/when the quickplay changes you made four months ago will be reverted to allow all community servers to be included in quickplay again by default? Fletcher Dunn had stated when this change was made that it would be temporary, yet four months later as community server after community server dies out, we've had zero communication on the subject from the TF2 team. Why are you no longer talking to server operators? Please, guys - communicate to the server community that has supported the game for so many years. If this is going to be the "default" quickplay configuration from now on, at least let us know so we can start shutting off servers as opposed to continuing to pay for hardware in the hopes that we'll be treated fairly again. We're hanging on here and financially supporting servers in the hopes that we'll be able to fill them again someday soon, but if there's no more hope left for us, at least let us know. Thank you. - JT P.S. If I could express to you the extreme sense of hopelessness you are imposing on the good communities that have built themselves around TF2, I would. We love this game, and we see the "culture" that so attracted us to it for all these years slipping away. Please consider the harm you're doing to the "good" communities out there but effectively diverting half of the player traffic away from even finding us. Spending years building a community only to have the rug pulled out from under us has depressed some of our members so much that they've walked away from the game all together. These are long-term TF2 players who - if they can't play on the community servers they helped build - are not going to play anymore at all. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds
[hlds] When will quickplay return to a level playing field?
As we approach the 2-month mark since Valve's servers were made the "default" servers for all quickplay players, can the TF2 team give us a time frame when they will return the system to a "level playing field" for all servers? As it stands, the players who want to avoid all community servers now have the ability to do so simply by clicking the "Official Server Only" button, so is it really necessary to keep driving nearly all quickplay traffic away from community servers? In fact, a better question would probably be - is it in TF2's best (long-term) interest to do so? Helping players find a "home" server where they become a "regular" creates long-term players, and since so much emphasis (in the design of the UI) has been placed on guiding players to use quickplay, the longer that community servers are effectively excluded from that traffic, the more long-term players the game will likely lose. The players that only want random games with random people on Valve servers now have the option to make sure that's all they get, but preventing the rest of the player base from experiencing all the diversity that the TF2 community can provide is both unnecessary and unfair to those of us who have never broken any rules, or violated any policies. With that in mind, please consider leveling the playing field again asap by including all community servers by default, and let the players decide for themselves if they don't want to be a part of that community. Thanks, guys. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds
[hlds] When will it be safe to start migrating servers to new IPs?
Hello, I know the TF2 team had said we needed to wait a bit before we started migrating servers under the new favorites system, but since I've had my servers registered and working under the new system now for a little over a week, I was wondering how much more time we need to give it before it's safe to start moving server to new IP addresses? Thanks. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds
[hlds] Windows 2008R2 server hangs?
Hello, Has anyone seen an increased amount of TF2 servers "hanging" since the last couple of patches on Windows 2008R2 servers? I've been having 2 or 3 of these a day now (mostly payload & dustbowl maps), when I had gone for quite a long time without having that problem. Server specs: Windows 2008R2Intel Xeon 123016GB ram CPU is at less than 25% when all server are full (only 4 servers running on each box at the moment) ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds
Re: [hlds] Mediated Discussion about Quick play change
SO - we're a little over a week into this, and here's what we've noticed: Our 32-player and custom servers are doing relatively fine (although they certainly take longer to fill up in the morning, and empty out much earlier at night), but it is our 24-slot vanilla servers that are really suffering. They still fill up, but only stay full for about 1/3 of the time they normally did (all had/have high scores according to the system as well). At this point, if the traffic to the Vanilla servers continue to decline, I can see us turning them off all together in 6-8 weeks or so. The tragedy with that is that players who want to play Vanilla, but don't wish to deal the non-Administered Valve servers filled with low-skilled, screaming, 12 year-olds (not to mention all the rampant hackers) are going to start running out of places to play, and I can't see that being good for the game in the long run. I suppose my biggest issue with this drastic action that Valve has taken is the fact that not only could it have been prevented, but that they took no steps to do so in the first place. For example, in Fletcher's quoted response above, he states that "But the player experience was really bad and we felt it called for some immediate action." That's all well and good, but here's the problem - they never clearly defined what they considered a "bad experience". Now, I'm sure we can all guess what they mean (the truly terrible video/audio ads, the "pay to win" premium crap, etc.), but since they never clearly stated "these are things we don't want in Quickplay" , they've taken this heavy-handed approach to enforce a code of conduct that they were NEVER clear about in the first place. Don't get me wrong - I think Pinion Ads (and their ilk) and all the "pay to win" servers have absolutely NO PLACE in quickplay, and never should have been allowed to flourish in the first place - but againwhen Valve sits back for over a year while this is all happening, allows it to not only continue, but grow - all without ever coming out with a well-defined, documented policy that says "none of this, this or this on qucikplay enabled servers", only to then apply a blanket "punishment" that lumnps all the "good" server operators who have NEVER run any of that crap in with all the "bad", then they are not only enforcing a set of rules that DID NOT AND STILL DO NOT EXIST, but they are doing so in such a blunt, ham fisted way as to hurt the very game they are trying to "save". Why not, instead, simply do the right thing? Why not come out with a revised Quickplay policy that is stricter and more clear as to what they DO want in quickplay, and simply tell server operators that they have X amount of days to comply, or be thrown out of quickplay permanently? As it stands - this drastic action is tantamount to penalizing people for law(s) that are not even on the books, and grouping all "non-offenders" in with the "offenders" simply because they do not wish to take the time and effort to do the right thing. When it comes to gaming, I've always thought of Valve as the "smartest guys in the room", and this is, quite frankly, not worthy of them. It is choosing an easy wrong over a hard right, and it needs to be fixed in days, not months. Do the right thing, Valve - you're better than this. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds
Re: [hlds] An open letter to Valve about MOTDs
Your cite Skial as an example, but what you fail to realize is that those large server groups only have those large number of servers because they are/were trying to use the quickplay system as a source of profit over and above their "expenses", NOT as a response to the natural growth in their "communities." In other words - those kinds of communities did not grow "organically", starting with just enough servers to support their current membership, and adding servers as their community grew. They threw up those huge numbers of servers as nothing more than "quickplay ad farms", turning the playerbase into little more than disposable ad impressions. Do you honestly think any of those groups have the massive community membership necessary to require 80+ servers? Of course not. Do you see the distinction? There are server operators who have slowly and consistently grown their server "regulars", adding to their server fleets as both their membership and funding permitted, and there are those that simply threw up high-volume "quickplay honey pot" fleets of ad-farms/servers with the intent of turning the players into an easy source of profit. Now, I'm not looking down my nose at Skial (I don't really know anything about them), or any other of these large server fleets, BUT - the fact is that most new players first few experiences with the game will be through quickplay, and the vast number of these ad-farms (many of which were hosted by the hundreds on cheap, under-powered VPS servers) are/were giving these players a very negative first impression of the game. While I don't necessarily agree with HOW Valve has fixed the problem (as I think it stinks that ALL server operators have to be made to suffer due to the actions of those abusing the system), I'm certainly glad Valve is taking steps to at least insure new players don't think that these ad-infested servers are the way ALL servers are run. Date: Thu, 7 Nov 2013 21:24:00 +0100 From: sai...@specialattack.net To: hlds@list.valvesoftware.com Subject: Re: [hlds] An open letter to Valve about MOTDs Forced in-game ads are evil. You’ve already paid for the game, why watch ads? There never was such a problem until quickplay and motd allowing video. Build a good community and likable servers, and you shall have your money through donations. We haven’t done it any differently in the past 15 years and we’re still doing so today. People are willing to donate bits for a fun community to play at who has their own servers up and running. The whole problem here is quickplay, you have tons of people roaming around random servers without an real good opportunity to bind them to your community. Before people would search for likable servers and add them to their favorites. These people would then return and start to get familiar with other people at the servers. This allowed for great community building. Unfortunately I don’t expect VALVe ever to turn off quickplay. That’s why I think communities will slowly start to die out. I can remember days where 90% of the players in a server had a clan/community tag In front of their name, nowadays you barely ever see them. Saint K.From: hlds-boun...@list.valvesoftware.com [mailto:hlds-boun...@list.valvesoftware.com] On Behalf Of Supreet Sent: Thursday, November 07, 2013 7:58 PM To: hlds@list.valvesoftware.com Subject: [hlds] An open letter to Valve about MOTDs Valve, Listen. People make good money off of running their TF2 servers. Moreover, it helps them pay for the servers. Why don't you just take all our liberty away, pull an EA and cut dedicated servers and host them all yourself? Quickplay has only been beneficial to free to play players or what I like to call "Window Gamers". They try a game because its free then after a while they leave the game because they're bored of hopping on random servers through quick play and finding ads everywhere. The liberty and freedom of browsing through a server list was an amazing idea so you should keep to it. Your quick play scoring system is pretty stupid and flawed. Why? Because its HEAVILY BIASED. Over time, there's just been servers that get a behemoth influx of players and and the quick play system starts favoring them. Therefore, ignoring the possibility of any potentially better servers people might like if they ended up on them. You should really consider stopping your shenanigans. You can't make up your own mind Valve. You released an update months ago with vague release notes about the removal of HTML motds then you modified it and now you just released another update. If you really cared about the game server operators, you would remove this bs "tweak" and give server operators the liberty to use methods to recovery money to cover costs and pocket money for their efforts. OR Build a better dedicated server that doesn't eat up so many resources so server operators don't have to pay $30 a month for a single server to a hosting c
Re: [hlds] Coming soon: changes to TF HTML MOTD support
This is kind of a double-edged sword. On one hand, while I certainly hope this deals all the "quickplay ad farms" a death blow (although it wouldn't surprise me to see the more nefarious folks create some hack(s) to once again circumvent these measures), it's a shame that so many long-standing features of the game that legitimate server operators use to convey valuable information (and assist in community building) are being stripped out bit by bit because of the folks whose only concern is/was easy ad impressions. I still firmly believe the right way to approach the problem is by disabling javascript/flash/html5 in the in-game browser itself, and allowing the good old basic html MOTD to continue to function as it has for over 5 years. I'm not sure if Valve even cares anymore that this approach - while it certainly hurts the pinion farms - also makes it that much harder for legitimate server operators to build a community around the game. Our 5+ year old community is, and always has been, fueled by member support (donations) that pay the server bills, and this just makes it that much harder to get new TF2 players to take a good look at the value we've built into the community. TF2 team - please take the time and take a step back and think about what is in the best long-term interest of TF2. This game NEEDS communities built around it - they promote and build the game's audience, drive commerce within the game, and create and police the best servers so that they don't degenerate into free-for-all zones of racsim, bigotry, and a haven for hackers & cheats. Just about every major change you've made to the game recently, both in introducing quickplay in its current form, AND in stripping out MOTD functionality to prevent the kind of ad farms that quickplay made possible in the first place, make it actually seem like you are trying to not only marginalize the importance of those communities, but to remove all diversity from the game as a whole. Please think about it, Valve. From: mc...@doctormckay.com Date: Thu, 7 Nov 2013 09:59:19 -0500 To: hlds@list.valvesoftware.com Subject: Re: [hlds] Coming soon: changes to TF HTML MOTD support Nobody forces you to go on servers that have ads. I fail to understand how the fact that some servers might use advertisements affects you personally when you can easily ignore them. Dr. McKaywww.doctormckay.com On Thu, Nov 7, 2013 at 9:51 AM, Saint K. wrote: Anything they do to battle them ad’s gets my vote. For all I care they disable the HTML functionality all together. Back to oldskool community building where one can only survive on donations. Donations means your servers are appreciated. Saint K. From: hlds-boun...@list.valvesoftware.com [mailto:hlds-boun...@list.valvesoftware.com] On Behalf Of 1nsane Sent: Thursday, November 07, 2013 3:38 PM To: Paul Lewis; Half-Life dedicated Win32 server mailing list Subject: Re: [hlds] Coming soon: changes to TF HTML MOTD support There wasn't much point to running MvM servers before. Even less so now it seems. Not like you can make a community around stock MvM. On Thu, Nov 7, 2013 at 6:12 AM, Paul wrote: I imagine many communities will close up on using TF2 Quickplay, whether they will successfully move to a different game or game mode is another question though. I'm switching from having 23 Mann vs Machine servers to trying Slender Fortress. If servers switch to being non-reliant on Quickplay then in my view that's partly good, as Quickplay from day one was a bad idea in my opinion. It doesn't promote or offer options to join servers which are run in an unofficial way (e.g. custom gamemodes or custom maps). In the days of Team Fortress Classic players had to use the server browser, and those days were better in my view. Custom run servers saw more players back then than they typically do in TF2 these days. It's impossible to use the MOTD for even simple images and links, so is practically impossible for a community to make links to things such as donation pages to help them cover costs of their servers. I'm expecting to see the number of Quickplay servers drop by a reasonable amount, and possibly more non-Quickplay servers to open (custom gamemodes and/or custom maps). On 7 November 2013 11:00, Element wrote: I run a group of servers which are funded from MOTD impressions resulting in my small community of players being able to play on servers setup the way they like, for FREE. My servers are in the quickplay pool to help fill the empty spaces for my community members, generating mostly full servers consisting of around a 50-50 mix of members and quickplay traffic. With my community impressions alone, server costs weren't quite being met each month. But when i added them to the quickplay pool, i was then able to use the advertising revenue to fully pay for my servers. But now this is not the case, thanks to valves latest and greatest idea I will
Re: [hlds] Coming soon: changes to TF HTML MOTD support
I assume this is in response to all the server operators who are using those MOTD ads and abusing the system? If so - why can't you simply disable javascript/flash from working instead? This action punishes legit server operators (yet again) who don't use any of those kinds of advertisements on our servers from showing a standard HTML motd - something we were able to do for years until those pinion ad-farms came along. From: fletch...@valvesoftware.com To: hlds_li...@list.valvesoftware.com; hlds@list.valvesoftware.com Date: Wed, 6 Nov 2013 23:03:30 + Subject: [hlds] Coming soon: changes to TF HTML MOTD support We’re making two changes to TF HTML MOTD support that server operators should be aware of: 1.) HTML MOTD’s will no longer be shown by clients that connect via quickplay. Those clients will show the plaintext message instead. (The file identified by the convar motdfile_text, which defaults to motd_text.txt.) 2.) When sending a URL to the “info” panel by name, the URL must begin with ‘http://’ or ‘https://’. Note that this change does not affect putting a URL in motd.txt directly, which has always required a protocol prefix in order for the file contents to be interpreted as a URL. ___ 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
Re: [hlds] Hide server from certain IP's?
Yeah, we added him to our firewall(s), but the point I was making was that it would make a server less of a target if we could simply make them not appear in the server browser of designated IP's/Steam IDs at all (even though his IP is banned, our servers will still appear in the browser, making them a target even though he can no longer connect). After all - if a user can blacklist a server (which makes it not appear in the browser when they search), wouldn't it make sense to allow the server to blacklist a user? From: mc...@doctormckay.com Date: Tue, 22 Oct 2013 15:00:42 -0400 To: hlds@list.valvesoftware.com Subject: Re: [hlds] Hide server from certain IP's? Use iptables or a similar firewall to drop all traffic from his IP. Dr. McKaywww.doctormckay.com On Tue, Oct 22, 2013 at 6:12 AM, Jason Tango wrote: Hello, We've had several DDOS attacks in the past several weeks. We now know the IP address of the person who is initiating the attacks (he has admitted as much). Unfortunately, he is using some kind of reflection attack that comes from hundreds of different IP addresses, so just blocking his IP won't do us much good. My question is - is there some way to prevent our server from even appearing in the server browser for his IP address? It sure would be wonderful for server operators to be able to blacklist certain IPs from even being able to see our servers in the server browser ;-) ___ 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
[hlds] Hide server from certain IP's?
Hello, We've had several DDOS attacks in the past several weeks. We now know the IP address of the person who is initiating the attacks (he has admitted as much). Unfortunately, he is using some kind of reflection attack that comes from hundreds of different IP addresses, so just blocking his IP won't do us much good. My question is - is there some way to prevent our server from even appearing in the server browser for his IP address? It sure would be wonderful for server operators to be able to blacklist certain IPs from even being able to see our servers in the server browser ;-) ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds
Re: [hlds] Problems caused by connecting server favorites to IP address
Correct - and here's something else to consider. DOS attacks have been on the rise this year, and it only seems they are getting worse. Having the server's favorites NOT tied to an IP address would also help mitigate these attacks. Consider this: If server favorites were tied to the "server_identity_account_id" instead of IP, if/when a server was on the receiving end of a DOS or DDOS attack, it would be possible tosimply launch that server on a different machine/IP address if necessary. Sure, it would add an expense of keeping a machine in reserve, but it would cost far less to do that than some of the DDOS mitigation hosts charge for hosting. Anyway - I sure would like to hear someone from Valve weigh in on this - is there any reason why this change CAN'T be implemented? > From: peter-h...@jerde.net > Date: Sat, 28 Sep 2013 16:01:55 -0500 > To: hlds@list.valvesoftware.com > Subject: Re: [hlds] Problems caused by connecting server favorites to IP > address > > It doesn't matter whether some datacenters are helpful about IP addresses or > not... it's still the case that changing providers *always* results in loss > of former IP addresses. > > The whole point of this thread is that it would be nice if Steam Server > Favorites weren't tied to IPs, but instead to something more permanent, like > server_identity_account_id. > ___ > 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
Re: [hlds] Problems caused by connecting server favorites to IP address
I would agree, however there are circumstances that can prevent that. We've also been with a good host for over 5 years - but unfortunately, they were sold to a larger corporation last year, and their number of server options/packages have gone down, while their prices have gone up - which is why we started looking elsewhere in the first place. All we're really asking for is some flexibility that changing the "favorites" system to something more server-operator friendly would provide. The current system locks you into a single host/datacenter in perpetuity unless you are willing to start over again if/when you move. Frankly, it seems like it would be a relatively easy fix on Valve's part, and since there's a huge upside to allowing operators the flexibility to improve their hardware, I'm not sure why it hasn't already been addressed. Cmon, Valve. Help us out! > CC: hlds@list.valvesoftware.com > From: ad...@topnotchclan.com > Date: Fri, 27 Sep 2013 11:53:55 -0700 > To: hlds@list.valvesoftware.com > Subject: Re: [hlds] Problems caused by connecting server favorites to IP > address > > Find a good host and stick with them. Iv leased 20 or so IPs for 5 years now > and have had 3 different hardware configurations. > > However it does suck to move when you are a smaller community. > > Sent from my iPhone 5 > > > On Sep 26, 2013, at 10:33 PM, ics wrote: > > > > upgrading hardware doesn't always mean IP change. We have retained our IP's > > for years. But i'm all in for keeping my servers in users favorite lists in > > other methods too. > > > > -ics > > > > Jason Tango kirjoitti: > >> > >> I would definitely be curious to know how many server operators have > >> decided against upgrading their hardware (which would be better for the > >> overall game's userbase in the long run) for this very reason. > >> > >> Is it simply the difficulty of implementation? Or is Valve so close to > >> releasing Source 2 (that may already have this implemented) that they > >> think it's a waste of time? > >> > >> All I DO know is that I would have to recommend against changing IP's to > >> anyone that doesn't absolutely have to. It's a disaster to your traffic. > >> > >> > >> > >> Date: Thu, 26 Sep 2013 14:33:59 -0700 > >> From: thepauls...@gmail.com > >> To: mreeu...@yahoo.com; hlds@list.valvesoftware.com > >> Subject: Re: [hlds] Problems caused by connecting server favorites to IP > >> address > >> > >> I said this a month ago and I explained why it would be much easier and > >> better for Valve to implement DNS instead of tying it to the server > >> registration system. > >> > >> When people upgrade you usually change hosts because the old ones have > >> gone bad so you cannot keep IPs. My experience with most hosts is that > >> they may let you upgrade your server, but they will not fix their network > >> providers, add ddos protection, or reduce your costs so you stop paying > >> $200/month because that was the standard price 4 years ago. > >> > >> I think what we need to do in order to get this implemented is to > >> understand why Valve has ignored this request for so long. > >> > >> This isn't rocket science or as difficult as implementing Source3, so the > >> problem must be because Valve doesn't think this will improve anything. > >> > >> > >> On Thu, Sep 26, 2013 at 2:23 PM, Mart-Jan Reeuwijk >> <mailto:mreeu...@yahoo.com>> wrote: > >> > >>The only way to truly "move" is keeping the old servers for a > >>while, and point those to the new servers so they can connect and > >>favorite them. having a turnover time without paralel, would give > >> no incentive to the players to add those IP's. > >> > >>I do agree a solution would really be nice to keep your playerbase > >>of a server. I even proposed various workings for that (via steam > >>group memberships to have a specific tab / option to show them in > >>favs). But its been on deaf ears for years now. > >> > >>Also, I never hear anybody about having a chat with the hoster / > >>datacenter to move the IP's to the new machines. > >> > >> > >> --
Re: [hlds] Problems caused by connecting server favorites to IP address
The issue in our case was the necessity to change providers/datacenters, which (of course) negated any chance of transferring IP's. I just wish we could get an official answer as to why this can or can't be done from Valve. There are a ton of great deals out therefor new hardware we would love to try, but we don't dare due to the traffic hit. > Date: Fri, 27 Sep 2013 18:30:05 +0300 > From: i...@ics-base.net > To: hlds@list.valvesoftware.com > Subject: Re: [hlds] Problems caused by connecting server favorites to IP > address > > It depends a lot from the hoster. Usually they don't bother to go to the > server room. They just move things over network to a server in another > ip address and be done with it and wont bother change ip. Too much work > and would mess up their network. > > Our hoster keeps our machine and IP that is assigned to it. Even if we > change hardware, we get to keep the ip. I can see no reason to change it > and our hoster does not either. I can see more reasons to keep it though. > > -ics > > Kyle Sanderson kirjoitti: > > We used to have to fight our provider pretty hard to retain our IP > > addresses. Management would say it's alright, then the rest of the > > company would deny it ever occurred and would just close the ticket > > feigning ignorance. The whole process would take about two days to get > > the addresses transferred to the new, in limbo server. Now they just > > charge everyone $20 per /29 block to move. I'm sure there are other > > horrible providers, that still do the former. > > > > Thanks, > > Kyle. > > > > > > On Thu, Sep 26, 2013 at 11:33 PM, ics > <mailto:i...@ics-base.net>> wrote: > > > > upgrading hardware doesn't always mean IP change. We have retained > > our IP's for years. But i'm all in for keeping my servers in users > > favorite lists in other methods too. > > > > -ics > > > > Jason Tango kirjoitti: > > > > > > I would definitely be curious to know how many server > > operators have decided against upgrading their hardware (which > > would be better for the overall game's userbase in the long > > run) for this very reason. > > > > Is it simply the difficulty of implementation? Or is Valve so > > close to releasing Source 2 (that may already have this > > implemented) that they think it's a waste of time? > > > > All I DO know is that I would have to recommend against > > changing IP's to anyone that doesn't absolutely have to. It's > > a disaster to your traffic. > > > > > > > > > > > > > > Date: Thu, 26 Sep 2013 14:33:59 -0700 > > From: thepauls...@gmail.com <mailto:thepauls...@gmail.com> > > To: mreeu...@yahoo.com <mailto:mreeu...@yahoo.com>; > > hlds@list.valvesoftware.com <mailto:hlds@list.valvesoftware.com> > > Subject: Re: [hlds] Problems caused by connecting server > > favorites to IP address > > > > I said this a month ago and I explained why it would be much > > easier and better for Valve to implement DNS instead of tying > > it to the server registration system. > > > > When people upgrade you usually change hosts because the old > > ones have gone bad so you cannot keep IPs. My experience with > > most hosts is that they may let you upgrade your server, but > > they will not fix their network providers, add ddos > > protection, or reduce your costs so you stop paying $200/month > > because that was the standard price 4 years ago. > > > > I think what we need to do in order to get this implemented is > > to understand why Valve has ignored this request for so long. > > > > This isn't rocket science or as difficult as implementing > > Source3, so the problem must be because Valve doesn't think > > this will improve anything. > > > > > > On Thu, Sep 26, 2013 at 2:23 PM, Mart-Jan Reeuwijk > > mailto:mreeu...@yahoo.com> > > <mailto:mreeu...@yahoo.com <mailto:mreeu...@yahoo.com>>> wrote: > > > > The only way to truly "move" is keeping the old servers for a > > while, and point those to the new servers so they
Re: [hlds] Problems caused by connecting server favorites to IP address
The change asked for in that thread would be good, but using the server registration would (IMHO) be much simpler. Heck, they could simply make an announcement that server registration will now be required for ALL servers (we don't bother with our custom map servers at the moment), implement a change that stores client favorites in the steam cloud, then run a database query/change that links the server in the favorites to the registration info instead of IP addess. Date: Thu, 26 Sep 2013 17:58:31 -0400 From: joewatshis...@gmail.com To: hlds@list.valvesoftware.com Subject: Re: [hlds] Problems caused by connecting server favorites to IP address http://forums.steampowered.com/forums/showthread.php?t=2756854 On Thu, Sep 26, 2013 at 5:41 PM, Jason Tango wrote: I would definitely be curious to know how many server operators have decided against upgrading their hardware (which would be better for the overall game's userbase in the long run) for this very reason. Is it simply the difficulty of implementation? Or is Valve so close to releasing Source 2 (that may already have this implemented) that they think it's a waste of time? All I DO know is that I would have to recommend against changing IP's to anyone that doesn't absolutely have to. It's a disaster to your traffic. Date: Thu, 26 Sep 2013 14:33:59 -0700 From: thepauls...@gmail.com To: mreeu...@yahoo.com; hlds@list.valvesoftware.com Subject: Re: [hlds] Problems caused by connecting server favorites to IP address I said this a month ago and I explained why it would be much easier and better for Valve to implement DNS instead of tying it to the server registration system. When people upgrade you usually change hosts because the old ones have gone bad so you cannot keep IPs. My experience with most hosts is that they may let you upgrade your server, but they will not fix their network providers, add ddos protection, or reduce your costs so you stop paying $200/month because that was the standard price 4 years ago. I think what we need to do in order to get this implemented is to understand why Valve has ignored this request for so long. This isn't rocket science or as difficult as implementing Source3, so the problem must be because Valve doesn't think this will improve anything. On Thu, Sep 26, 2013 at 2:23 PM, Mart-Jan Reeuwijk wrote: The only way to truly "move" is keeping the old servers for a while, and point those to the new servers so they can connect and favorite them. having a turnover time without paralel, would give no incentive to the players to add those IP's. I do agree a solution would really be nice to keep your playerbase of a server. I even proposed various workings for that (via steam group memberships to have a specific tab / option to show them in favs). But its been on deaf ears for years now. Also, I never hear anybody about having a chat with the hoster / datacenter to move the IP's to the new machines. From: Jason Tango To: "hlds@list.valvesoftware.com" Sent: Thursday, 26 September 2013, 22:11 Subject: [hlds] Problems caused by connecting server favorites to IP address Hello, I know this has been brought up many, many timesbut it would seem that with the maturity of the server registration system that Valve is now in a perfect position to fix this issue which both negatively impacts long-established servers, AND prevents server operators from moving to better/improved hardware. I'm talking about the way server favorites work in the server browser. Specifically, the fact that if - for any reason - a server operator needs to change their server's IP address, it disappears from all the users clients who have added it to their favorites over the years. That may not seem like a big deal, but it absolutely IS. It takes months and years to build up a strong base of server regulars, and that base is virtually destroyed if you change that server's IP address. For examplewe recently had the opportunity to acquire hardware at a significant discount at another server provider that was a significant upgrade from our current hardware (from a Q9400 to a E3-1270v3 with a samsung Pro SSD) for the same price we were currently paying per month. Wanting to give our players the best possible experience, so we decided to make the move. To prepare, we ran a message for 30 days on the current servers informing the players the servers were moving (and the new address). After that 30 day period, we flipped the switch, and shutdown the old server, bringing the new ones online (the 1270v3 is ridiculously powerful, BTW). Now, these are servers which had previously stayed full for 18+ hours per day on a regular basis, with a 24-hour average population (according to HlStats) of 21 players. After the first 30 days, the 24-hour average is now down
Re: [hlds] Problems caused by connecting server favorites to IP address
I would definitely be curious to know how many server operators have decided against upgrading their hardware (which would be better for the overall game's userbase in the long run) for this very reason. Is it simply the difficulty of implementation? Or is Valve so close to releasing Source 2 (that may already have this implemented) that they think it's a waste of time? All I DO know is that I would have to recommend against changing IP's to anyone that doesn't absolutely have to. It's a disaster to your traffic. Date: Thu, 26 Sep 2013 14:33:59 -0700 From: thepauls...@gmail.com To: mreeu...@yahoo.com; hlds@list.valvesoftware.com Subject: Re: [hlds] Problems caused by connecting server favorites to IP address I said this a month ago and I explained why it would be much easier and better for Valve to implement DNS instead of tying it to the server registration system. When people upgrade you usually change hosts because the old ones have gone bad so you cannot keep IPs. My experience with most hosts is that they may let you upgrade your server, but they will not fix their network providers, add ddos protection, or reduce your costs so you stop paying $200/month because that was the standard price 4 years ago. I think what we need to do in order to get this implemented is to understand why Valve has ignored this request for so long. This isn't rocket science or as difficult as implementing Source3, so the problem must be because Valve doesn't think this will improve anything. On Thu, Sep 26, 2013 at 2:23 PM, Mart-Jan Reeuwijk wrote: The only way to truly "move" is keeping the old servers for a while, and point those to the new servers so they can connect and favorite them. having a turnover time without paralel, would give no incentive to the players to add those IP's. I do agree a solution would really be nice to keep your playerbase of a server. I even proposed various workings for that (via steam group memberships to have a specific tab / option to show them in favs). But its been on deaf ears for years now. Also, I never hear anybody about having a chat with the hoster / datacenter to move the IP's to the new machines. From: Jason Tango To: "hlds@list.valvesoftware.com" Sent: Thursday, 26 September 2013, 22:11 Subject: [hlds] Problems caused by connecting server favorites to IP address Hello, I know this has been brought up many, many timesbut it would seem that with the maturity of the server registration system that Valve is now in a perfect position to fix this issue which both negatively impacts long-established servers, AND prevents server operators from moving to better/improved hardware. I'm talking about the way server favorites work in the server browser. Specifically, the fact that if - for any reason - a server operator needs to change their server's IP address, it disappears from all the users clients who have added it to their favorites over the years. That may not seem like a big deal, but it absolutely IS. It takes months and years to build up a strong base of server regulars, and that base is virtually destroyed if you change that server's IP address. For examplewe recently had the opportunity to acquire hardware at a significant discount at another server provider that was a significant upgrade from our current hardware (from a Q9400 to a E3-1270v3 with a samsung Pro SSD) for the same price we were currently paying per month. Wanting to give our players the best possible experience, so we decided to make the move. To prepare, we ran a message for 30 days on the current servers informing the players the servers were moving (and the new address). After that 30 day period, we flipped the switch, and shutdown the old server, bringing the new ones online (the 1270v3 is ridiculously powerful, BTW). Now, these are servers which had previously stayed full for 18+ hours per day on a regular basis, with a 24-hour average population (according to HlStats) of 21 players. After the first 30 days, the 24-hour average is now down to 6 players, and they only fill up roughly 4-6 hours per day. And therein lies the problem. We did (we believe) what was absolutely the right thing in that we chose to upgrade our hardware solely for the purpose of giving our players a better, smoother, more state of the art gaming experience. The server runs wonderfully (3 full servers uses less than 7% CPU!), and the players who ARE playing on them regularly comment on the improvement to frame rate, stability, and map load times. The only thing on our end that changed as far as server configuration was the IP - and it has essentially KILLED the traffic to those servers, forcing us to basically start over from scratch trying to build our server traffic back up (and no, we don't run any of those atrocious MOTD ads or anythi
Re: [hlds] Problems caused by connecting server favorites to IP address
Sorry about that - I'm not sure why outlook did that. From: asher...@gmail.com Date: Thu, 26 Sep 2013 22:18:57 +0100 To: hlds@list.valvesoftware.com Subject: Re: [hlds] Problems caused by connecting server favorites to IP address Is your email in enough different font sizes? ~ "Their heads are green, and their hands are blue, And they went to sea in a Sieve." - Edward Lear On Thu, Sep 26, 2013 at 10:11 PM, Jason Tango wrote: Hello, I know this has been brought up many, many timesbut it would seem that with the maturity of the server registration system that Valve is now in a perfect position to fix this issue which both negatively impacts long-established servers, AND prevents server operators from moving to better/improved hardware. I'm talking about the way server favorites work in the server browser. Specifically, the fact that if - for any reason - a server operator needs to change their server's IP address, it disappears from all the users clients who have added it to their favorites over the years. That may not seem like a big deal, but it absolutely IS. It takes months and years to build up a strong base of server regulars, and that base is virtually destroyed if you change that server's IP address. For examplewe recently had the opportunity to acquire hardware at a significant discount at another server provider that was a significant upgrade from our current hardware (from a Q9400 to a E3-1270v3 with a samsung Pro SSD) for the same price we were currently paying per month. Wanting to give our players the best possible experience, so we decided to make the move. To prepare, we ran a message for 30 days on the current servers informing the players the servers were moving (and the new address). After that 30 day period, we flipped the switch, and shutdown the old server, bringing the new ones online (the 1270v3 is ridiculously powerful, BTW). Now, these are servers which had previously stayed full for 18+ hours per day on a regular basis, with a 24-hour average population (according to HlStats) of 21 players. After the first 30 days, the 24-hour average is now down to 6 players, and they only fill up roughly 4-6 hours per day. And therein lies the problem. We did (we believe) what was absolutely the right thing in that we chose to upgrade our hardware solely for the purpose of giving our players a better, smoother, more state of the art gaming experience. The server runs wonderfully (3 full servers uses less than 7% CPU!), and the players who ARE playing on them regularly comment on the improvement to frame rate, stability, and map load times. The only thing on our end that changed as far as server configuration was the IP - and it has essentially KILLED the traffic to those servers, forcing us to basically start over from scratch trying to build our server traffic back up (and no, we don't run any of those atrocious MOTD ads or anything - our servers are supported by donations only). The fix, it would seem, would be relatively easy. Why not tie the server favorites to the server registration information instead? Connecting the favorites to IP address does nothing but prevent server operators from upgrading/moving to better equipment and/or datacenters, and severely limits the options we have to improve the gaming environments for our players. I, for one, won't be upgrading/moving anything else if it means I have to change IP addresses. It's simply not worth the traffic loss you incur as a result. Please make this a priority, Valve. The time has come. Thanks. ___ 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
[hlds] Problems caused by connecting server favorites to IP address
Hello, I know this has been brought up many, many timesbut it would seem that with the maturity of the server registration system that Valve is now in a perfect position to fix this issue which both negatively impacts long-established servers, AND prevents server operators from moving to better/improved hardware. I'm talking about the way server favorites work in the server browser. Specifically, the fact that if - for any reason - a server operator needs to change their server's IP address, it disappears from all the users clients who have added it to their favorites over the years. That may not seem like a big deal, but it absolutely IS. It takes months and years to build up a strong base of server regulars, and that base is virtually destroyed if you change that server's IP address. For examplewe recently had the opportunity to acquire hardware at a significant discount at another server provider that was a significant upgrade from our current hardware (from a Q9400 to a E3-1270v3 with a samsung Pro SSD) for the same price we were currently paying per month. Wanting to give our players the best possible experience, so we decided to make the move. To prepare, we ran a message for 30 days on the current servers informing the players the servers were moving (and the new address). After that 30 day period, we flipped the switch, and shutdown the old server, bringing the new ones online (the 1270v3 is ridiculously powerful, BTW). Now, these are servers which had previously stayed full for 18+ hours per day on a regular basis, with a 24-hour average population (according to HlStats) of 21 players. After the first 30 days, the 24-hour average is now down to 6 players, and they only fill up roughly 4-6 hours per day. And therein lies the problem. We did (we believe) what was absolutely the right thing in that we chose to upgrade our hardware solely for the purpose of giving our players a better, smoother, more state of the art gaming experience. The server runs wonderfully (3 full servers uses less than 7% CPU!), and the players who ARE playing on them regularly comment on the improvement to frame rate, stability, and map load times. The only thing on our end that changed as far as server configuration was the IP - and it has essentially KILLED the traffic to those servers, forcing us to basically start over from scratch trying to build our server traffic back up (and no, we don't run any of those atrocious MOTD ads or anything - our servers are supported by donations only). The fix, it would seem, would be relatively easy. Why not tie the server favorites to the server registration information instead? Connecting the favorites to IP address does nothing but prevent server operators from upgrading/moving to better equipment and/or datacenters, and severely limits the options we have to improve the gaming environments for our players. I, for one, won't be upgrading/moving anything else if it means I have to change IP addresses. It's simply not worth the traffic loss you incur as a result. Please make this a priority, Valve. The time has come. Thanks. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds
[hlds] Steam Content srvers down (east coast)
Hello, I've been trying to install a new TF2 server all morning, and I keep getting the following message: Connecting anonymously to Steam Public...Success.ERROR! Timed out waiting for AppInfo update. Are the content servers down for some reason? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds
Re: [hlds] Floating Intel glitch
As a matter of fact, yes. From: mc...@doctormckay.com Date: Thu, 29 Aug 2013 13:31:11 -0400 To: hlds@list.valvesoftware.com Subject: Re: [hlds] Floating Intel glitch Do you use the SourceMod plugin "AFK Manager"? Dr. McKaywww.doctormckay.com On Tue, Aug 27, 2013 at 8:47 PM, Jason Tango wrote: Has anyone else seen this old glitch resurface? We've had a half dozen players using the "floating Intel Glitch" on 2Fort over the last few days. Does anyone know how to block it? ___ 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
[hlds] Floating Intel glitch
Has anyone else seen this old glitch resurface? We've had a half dozen players using the "floating Intel Glitch" on 2Fort over the last few days. Does anyone know how to block it? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds
[hlds] Small issues since the last patch
Hello, I've noticed a couple of small bugs since the last patch. First is probably client-side (I think - but I'm not sure so I'll post it here as well). A number of users have complained about the "Gib Messages" appearing on their screens (the "your liver", "your torso", etc.) and not going away. I was able to duplicate that last night myself (played a few rounds of a CP map with those 8 of those messages "stuck" on my screen). The other is a strange issue I can't identify the cause of yet - all of my 24-slot "vanilla-settings", quickplay-enabled servers have "hung" at least once today, some twice. The hung server needed a manual restart to get going again. This is on a windows 2008R2 server. I say this issue is strange because it has not happened on any of my 32-slot non-quickplay servers. Anyone else seeing these issues? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds
Re: [hlds] mp_stalemate_enable/mp_stalemate_meleeonly Causing Crashes
Probably a stupid question - but have you been trying it on a full server? The crashes we've been seeing have been happening on servers with 32 players. I wish I had saved some of the crash dumps - I can try to get some tonight. The symptoms are simply this: - server settings are mp_stalemate_enable "1" , mp_stalemate_meleeonly "1" and mp_stalemate_timelimit "180" - server clock runs out, and server attempts to go into sudden death - server crashes immediately *I've tried this with and without Sourcemod/Metamod enabled, and the crash persists, so I think we can eliminate Sourcemod as a cause. From: er...@valvesoftware.com To: hlds@list.valvesoftware.com; hlds_li...@list.valvesoftware.com Date: Tue, 23 Jul 2013 21:41:48 + Subject: Re: [hlds] mp_stalemate_enable/mp_stalemate_meleeonly Causing Crashes We’ve been trying to reproduce this crash and haven’t been able to. We’ve tried TF2 dedicated servers for Linux and Windows (even 2008R2) and can’t get the server to crash with these settings in the server.cfg: mp_stalemate_enable 1 mp_stalemate_at_timelimit 0 mp_stalemate_meleeonly 1 mp_match_end_at_timelimit 0 We’ve been testing on TC_Hydro by letting the round timer run out. Please email me if you the steps to reproduce the crash or if you have any crash dump files. Thanks. -Eric From: hlds-boun...@list.valvesoftware.com [mailto:hlds-boun...@list.valvesoftware.com] On Behalf Of Jason Tango Sent: Monday, July 22, 2013 3:06 PM To: hlds@list.valvesoftware.com Subject: [hlds] mp_stalemate_enable/mp_stalemate_meleeonly Causing Crashes Hello, Ever since the July 10 "balancing" update, setting mp_stalemate_enable "1" & mp_stalemate_meleeonly "1" causes our windows 2008R2 TF2 servers to crash every time. Our players really miss melee-only sudden death - is a fix for this in the works? ___ 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
[hlds] mp_stalemate_enable/mp_stalemate_meleeonly Causing Crashes
Hello, Ever since the July 10 "balancing" update, setting mp_stalemate_enable "1" & mp_stalemate_meleeonly "1" causes our windows 2008R2 TF2 servers to crash every time. Our players really miss melee-only sudden death - is a fix for this in the works? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds
Re: [hlds] (no subject)
Make that four accounts. From: serverg...@hotmail.com To: hlds@list.valvesoftware.com Date: Sun, 16 Jun 2013 20:19:06 -0400 Subject: [hlds] (no subject) Way to attack people contributing to the list!! What makes you think they are the same person? because they disagree with your wrong opinion? Which one of those people said anything about "quickplay" at all? do you actually read what people write or do you just make things up in your head and respond in kind? A few loud mouths do not reflect the opinions of all. - Original Message - From: Evourr [evo...@gmail.com] To: Half-Life dedicated Win32 server mailing list Sent: Sunday, June 16, 2013 8:05 PM Subject: Re: [hlds] TF2 MOTD and Quickplay The problem is this thread got derailed by one user with 3 subscribed accounts. (Liquid Source, Steam Commander, and Valve Monkey.) Additional information added to the return of the "status" command would suit your needs. The problem with your original statement is that you wanted Valve to implement a restriction on the quickplay clients so the motd was completely disabled, but you only wanted it so you could detect quickplay clients. (That's just bad practice.) ___ 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
Re: [hlds] NO to in game advertising
Wow, that's brutal, even if unintended. I can see what they're trying to do - but this will probably alienate players even more. I think the solution to all the player complaints would be to simply disallow quickplay traffic to Pinion servers. That way, server operators can still use it if they wish, but they will need to attract & build traffic the old-fashioned way (via the server browser). I honestly think that's the litmus test for a good server environment - will it stay full without quickplay? For pinion/3rd party ad supported servers (that interrupt the natural operation/flow of the game to force an ad on players), I doubt they would survive without being constantly fed easy traffic. Date: Wed, 5 Jun 2013 21:00:36 -0400 From: 1nsane...@gmail.com To: hlds@list.valvesoftware.com Subject: Re: [hlds] NO to in game advertising It's not on purpose. Just a side effect of their implementation. What they did was add a dynamic timer. So if there's no ad you can skip right away, if there is an ad it prevents you from closing it while the ad is playing. And all of this is queried in real time. So a 13 second ad will only prevent you for 13 seconds. Where as before their system would just force everyone to wait 30 or whatever seconds. Even when there was no ad. Now if you have Pinion blocked in one way or another, it will assume your video is taking a long time to load and will wait as long as the plugin allows (which was decreased to 40 seconds in the new plugin or something). I haven't looked at the code in a while either, but that's what it was like before. On Wed, Jun 5, 2013 at 8:33 PM, Doctor McKay wrote: Evidently, Pinion has implemented procedures to delay the game for players who block their ad server in their hosts file. I haven't looked at the code though, I'm only going from what SPUF has spewed forth. Honestly, just blacklisting the servers is your best bet. If you believe that a server that forces advertisements on its players is of poor quality, why would you consciously choose to play on it? Regardless, this is a discussion for SPUF/SPUD, and it's already been beaten into the ground several times over there. Doctor McKay http://www.doctormckay.com mc...@doctormckay.com On Wed, Jun 5, 2013 at 9:58 AM, Mart-Jan Reeuwijk wrote: Nah, thats a blacklist for in TF2, so you don't see those servers. technically its not a ad-blocker. creating the hosts file to block the advert server of pinion would be considered such. From: Christopher Andrews To: Half-Life dedicated Win32 server mailing list Sent: Wednesday, 5 June 2013, 15:35 Subject: Re: [hlds] NO to in game advertising Didn't Dr. McKay already make one? On Wed, Jun 5, 2013 at 9:33 AM, Patrick Delle Grazie wrote: Here’s an idea. Why don’t one of you stalwarts create an in game ad blocker. J But then of course you’d have to advertise it to get people to use it. ;) P. From: hlds-boun...@list.valvesoftware.com [mailto:hlds-boun...@list.valvesoftware.com] On Behalf Of Saint K. Sent: Wednesday, June 5, 2013 9:26 AM To: Half-Life dedicated Win32 server mailing list Subject: Re: [hlds] NO to in game advertising It's a server discussion mailing list, we, the server operators make the call on advertisements. No need for SPUF, perfectly valid here. Saint K. From: hlds-boun...@list.valvesoftware.com [hlds-boun...@list.valvesoftware.com] on behalf of Sebastian Iskra [seabas...@gmail.com] Sent: 05 June 2013 14:18 To: Half-Life dedicated Win32 server mailing list Subject: Re: [hlds] NO to in game advertising Once upon a time there was SPUF. /thread. On Wed, Jun 5, 2013 at 8:04 AM, Saint K. wrote: Once upon a time there was an era where community's survived on donations. Receiving donations was an indication of the community doing a good job, after all, if they weren't, they wouldn't receive donations and the community wouldn't last. With crap like Pinion nowadays all that counts is luring people in to connect and then earn money per player being forced to watch the pinion crap in their MOTD (MVM matchmaking and quickplay makes for an easy task to do this). You can host the most shittiest servers now and still earn money to survive. I for one would like to see VALVe picks up their old policies again, where advertising in their games was completely prohibited. Want to have better quality servers again VALVe? Then make sure you get rid of crap like Pinion. My 2 cents. Saint K. From: hlds-boun...@list.valvesoftware.com [hlds-boun...@list.valvesoftware.com] on behalf of Devin [hollan...@gmail.com] Sent: 04 June 2013 17:50 To: 'Half-Life dedicated Win32 server mailing list' Subject: Re: [hlds] NO to in game advertising Valve and Pinion are independent companies. Pinion is designed to help offset the overhead required to host servers, web sites, etc. Valve isn’t going to force you to start using pinion. My
Re: [hlds] Fake Client Fool
If people want to spend their time as the "quickplay police force", that's fine by me - but I believe Valve has said on numerous occasions that this mailing list is not the place to "name and shame" other server operators. There are proper venues for reporting perceived violations, and this list isn't one o f them. Do I think people who aren't setting the proper tags should be dropped from quickplay? Absolutely.but pointing fingers in a public forum just leads to the more nefarious readers of this list into doing things (like attacking the servers/community in question) against operators that may or may not be doing anything wrong. It's easy to accuse people (and equally easy to falsify "evidence") - but the only people here whose responsibility to dole out punishment should be the Valve team. So - how about we have enough respect for each other to use the proper channels for these reports, as opposed to starting virtual witch hunts. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds
Re: [hlds] Dynamic Slots & the Policy of Truth
I actually agree, in theory. In fact, the system we had been working on would have given the existing players on the server a 90-second "warning" that the server was going to change conditions (i.e. increase player slots), so they would be given fair warning if they wished to leave first. The system also performed checks to insure that the proper sv_tags were always set (to prevent any accidental omissions/glitches) when the slots were increased. I also agree that as long as the sv-tags are correct and describe the current/active server conditions, then a server operator is staying within the letter of the "law". However, I still think it's important that we get an "official" ruling on this issue from Fletcher & co. - if for no other reason than to prevent any misunderstandings with the TF2 team. From: saul.renni...@gmail.com Date: Sun, 5 May 2013 13:57:35 +0100 To: hlds@list.valvesoftware.com Subject: Re: [hlds] Dynamic Slots & the Policy of Truth As long as you report increased_maxplayers when you increase your maxplayers, you aren't lying whatsoever, and so complying with the Policy of Truth. Kind regards,Saul Rennison On 5 May 2013 13:46, Jason Tango wrote: Fletcher Dunn and/or TF2 Team: Can we get a ruling on the use of "Dynamic Slots" with TF2/CS:S servers and their compliance with the Policy of Truth? Specifically, there are server operators using them to keep their servers at 24 slots (to gain the maximum benefit from quickplay, I assume) until they fill, and then switching them to a higher slot count, etc. I know that there are much fewer server operators using these anymore (and one of the major TF2 gaming communities stopped using them about 6 months ago simply because they didn't want to run afoul of the "Policy of Truth"), but there are still quite a few operators using them, and it gives them an advantage (when filling their servers) as a result. I asked Fletcher this question many months ago, but never received a reply. We were considering using a similar system to keep our servers at a slot count of 24 until one of our donators needed to join a full server, at which time we would have the system change to a 32 slot server (and report all appropriate tags, etc.). We had no intention to "game the system", but we wanted to maximize server population while preventing as many players as possible from getting kicked due to reserved slots. In the end, since we never received an answer back, we decided to err on the side of caution and not use a such a system. I know this is kind of a "grey" area, because on one hand Fletcher has said the "Policy of Truth" says that all servers must report the correct sv_tags that are actively in use, so technically, as long as the server reports "increased_maxplayers" when they change to 25+ slots, then I suppose they are in compliance, but as I've never heard a definitive yes or no as to whether this type of system would cross the line, I just wanted to pose the question here so we can know if using the kind of system I described above (to prevent too many reserved-slot kicks) would be ok. To be clear - this is not meant to "call anyone out" who are using dynamic slots, I'm merely trying to finally get a ruling on their use and compliance with the "Policy of Truth" Thanks. ___ 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
[hlds] Dynamic Slots & the Policy of Truth
Fletcher Dunn and/or TF2 Team: Can we get a ruling on the use of "Dynamic Slots" with TF2/CS:S servers and their compliance with the Policy of Truth? Specifically, there are server operators using them to keep their servers at 24 slots (to gain the maximum benefit from quickplay, I assume) until they fill, and then switching them to a higher slot count, etc. I know that there are much fewer server operators using these anymore (and one of the major TF2 gaming communities stopped using them about 6 months ago simply because they didn't want to run afoul of the "Policy of Truth"), but there are still quite a few operators using them, and it gives them an advantage (when filling their servers) as a result. I asked Fletcher this question many months ago, but never received a reply. We were considering using a similar system to keep our servers at a slot count of 24 until one of our donators needed to join a full server, at which time we would have the system change to a 32 slot server (and report all appropriate tags, etc.). We had no intention to "game the system", but we wanted to maximize server population while preventing as many players as possible from getting kicked due to reserved slots. In the end, since we never received an answer back, we decided to err on the side of caution and not use a such a system. I know this is kind of a "grey" area, because on one hand Fletcher has said the "Policy of Truth" says that all servers must report the correct sv_tags that are actively in use, so technically, as long as the server reports "increased_maxplayers" when they change to 25+ slots, then I suppose they are in compliance, but as I've never heard a definitive yes or no as to whether this type of system would cross the line, I just wanted to pose the question here so we can know if using the kind of system I described above (to prevent too many reserved-slot kicks) would be ok. To be clear - this is not meant to "call anyone out" who are using dynamic slots, I'm merely trying to finally get a ruling on their use and compliance with the "Policy of Truth" Thanks. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds