Re: [hlds_linux] [hlds] New SteamID format for TF2
> > Haha, I can't believe how I've seemingly managed to start off a Quickplay > discussion, or perhaps debate, just by mentioning it earlier on as an > example of the one of many failings that Valve doesn't officially keep > people up to date on. I found it funny too, but it's not surprising. This mailing list is (mostly) for people who host their own servers, so any changes that make our lives harder tend to put us all on the same side. The quickplay changes hurt pretty much all of us, big and small, and I'm sure caused the death of a few smaller communities. However, the changes also hurt the "communities" that didn't care for the users at all but instead focused on making money. That last part is probably the most important, since Valve's intention was to eliminate pay-to-win and ad-spamming servers. If we want to inspire change, we need to have a compelling argument that the majority of us can get behind--not just "psht, you ruined my servers, revert the changes or I'll shout at you." You said it though "Default Quickplay Settings" - Valve needs to take the > default settings off of Valve servers as targets and apply them to the > Community servers or just mix them up so they are all showing up not just > Valve servers. So far this is the only idea I've actually seen recently, and it's a solid start. I think that leaving them how they are is fine for the first ~50 hours of gameplay. Show new users what vanilla TF2 is like and teach them how to play on Valve servers, but after they have played a bit have a dialog pop-up on launch asking if they want to include community servers in their Quickplay searches. Add a sentence or two about what this would mean to their experience and give them a choice to turn off the valve-only option. Users who have some experience in TF2 will know that they don't have to deal with spammy advertisements, and know when a server is doing something that is game-breaking. On Wed, Aug 27, 2014 at 9:17 AM, Paul wrote: > Haha, I can't believe how I've seemingly managed to start off a Quickplay > discussion, or perhaps debate, just by mentioning it earlier on as an > example of the one of many failings that Valve doesn't officially keep > people up to date on. > > > On 27 August 2014 16:37, Ilya Larin wrote: > > > Valve said that there will not be server quickplay scores in the future > > > > > > 2014-08-27 19:31 GMT+04:00 Alexander Corn : > > > > > Setting the server host to "don't care" by default wouldn't even help > at > > > this point unless it came with a complete reset of all Valve servers' > > > scores. Being the default servers for so long has artificially inflated > > > their scores. > > > > > > > > > Dr. McKay > > > www.doctormckay.com > > > > > > > > > On Wed, Aug 27, 2014 at 11:28 AM, Frank wrote: > > > > > > > You can't argue with him..I have no idea why I even replied. > > > > > > > > You said it though "Default Quickplay Settings" - Valve needs to take > > the > > > > default settings off of Valve servers as targets and apply them to > the > > > > Community servers or just mix them up so they are all showing up not > > just > > > > Valve servers. > > > > > > > > > > > > -Original Message- > > > > From: hlds_linux-boun...@list.valvesoftware.com > > > > [mailto:hlds_linux-boun...@list.valvesoftware.com] On Behalf Of Ilya > > > Larin > > > > Sent: Wednesday, August 27, 2014 11:21 AM > > > > To: Half-Life dedicated Linux server mailing list > > > > Subject: Re: [hlds_linux] [hlds] New SteamID format for TF2 > > > > > > > > dan, you don`t get the point of this discussion. While old bad > servers > > > are > > > > full of players, new good servers can`t get players not because they > > are > > > > bad, but because players don`t want to open server browser and look > > for a > > > > good server. (Im not saying that all old servers are bad and all new > > > > servers > > > > are good) New players don`t even know how to search a nice server, > they > > > are > > > > not familiar with that. They are just using default quickplay > settings. > > > Old > > > > players also don`t use serverbrowser, as they have already found a > > > servers > > > > community to regular on. > > > > > > > > > > > > 2014-08-27 19:06 GMT+04:00 dan : > > > > > > > > > On 27/08/2014 15:59, Alexander Corn wrote: > > > > > > > > > >> How, exactly, do you expect people to get players on their servers > > > > >> when about 45% of people probably don't even know that the server > > > > >> browser exists? > > > > >> > > > > > > > > > > Right, because only a guy who pretends to be a Doctor can be > > > > > intelligent enough to use the server browser. > > > > > > > > > > Sheesh, people were playing TF2 for years when the only way to get > on > > > > > a server was with the browser. > > > > > How do you suppose they did that? They were all gifted and > talented? > > > > > > > > > > As I've said before, if you cannot join a server, ask and I'm sure > > > > > others will help you but
Re: [hlds_linux] Important changes to TF2 coming soon
McKay basically covered the issue I was referring to. In our case (since we don't use a GSP): > Servers can spontaneously combust in my experience when set to a maxplayers > value over 32. I know 32 player servers aren't "officially" supported, so that may play a big part of it. Our experiences with this is a bit outdated since we haven't run 32 player servers in this manner for at least 8 months, if not a full year. I'm not sure if it will affect 24 player servers in the same way, but it is a concern. I guess it might be best to just wait and see if the problem still exists. I certainly feel for those using GSPs with this new rule, but I can see why kicking players for reserved slots is considered unacceptable for those servers in the quickplay pool. It was never an ideal solution to begin with. On 2/5/2014 4:28 PM, Fletcher Dunn wrote: > What's the problem with overfull servers? Can you not set visiblemaxplayers > to 24 and allow players with reserved slots to join past 24? > > -Original Message- > From: hlds_linux-boun...@list.valvesoftware.com > [mailto:hlds_linux-boun...@list.valvesoftware.com] On Behalf Of Jake Forrester > Sent: Wednesday, February 05, 2014 4:23 PM > To: hlds_linux@list.valvesoftware.com > Subject: Re: [hlds_linux] Important changes to TF2 coming soon > > Oh happy day! > > Thank you for taking all our concerns to heart and actually fixing quite a > few of the problems that have been around for years. I'm actually giddy with > the changes. > > The only thing I can see being an issue now is this: >> * Kicking players to make room for reserved slots >> > I agree that it's lame to kick players for reserved slots, but there > isn't a great method to support reserved slots right now. A long time > ago we used to allow reserved slot players to connect when the server was > full without kicking anyone (ex: 25/24 players), but srcds seemed to have > issues with greater than 24 players. Are there any plans to support > over-full servers like this? I think the donor-based communities are > probably the ones with the most contributions to the TF2 community as a > whole, and they're the ones that tend to give out reserved slots as incentive > to donate. Some legitimate way to allow reserved slots without hurting > quickplay eligibility would be /very/ nice. > > All in all, amazing update Fletcher. I'm glad to see the QP issues being > addressed, and the gameserver accounts becoming a reality. > -- Jake Forrester Owner / Web Developer FirePowered LLC w: https://firepoweredgaming.com e: j...@ranndesigns.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
Re: [hlds_linux] Important changes to TF2 coming soon
Oh happy day! Thank you for taking all our concerns to heart and actually fixing quite a few of the problems that have been around for years. I'm actually giddy with the changes. The only thing I can see being an issue now is this: > > * Kicking players to make room for reserved slots > I agree that it's lame to kick players for reserved slots, but there isn't a great method to support reserved slots right now. A long time ago we used to allow reserved slot players to connect when the server was full without kicking anyone (ex: 25/24 players), but srcds seemed to have issues with greater than 24 players. Are there any plans to support over-full servers like this? I think the donor-based communities are probably the ones with the most contributions to the TF2 community as a whole, and they're the ones that tend to give out reserved slots as incentive to donate. Some legitimate way to allow reserved slots without hurting quickplay eligibility would be /very/ nice. All in all, amazing update Fletcher. I'm glad to see the QP issues being addressed, and the gameserver accounts becoming a reality. -- Jake Forrester Owner / Web Developer FirePowered LLC w: https://firepoweredgaming.com e: j...@ranndesigns.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
Re: [hlds_linux] Prevent game servers from redirecting players to alternate servers when players connect through quickplay
What if one of us made a site specifically for rating TF2 communities and servers? We could quite literally provide a list of crappy servers by name + IP to them once a month. I imagine Valve does want the servers gone as much as we do, but if it's going to waste too much of an employee's time, it's not worth it to them. If we could hand them something that's manageable and could be dealt with in part of a day, maybe they'd be more willing to shut down (or even just penalize) those communities who aren't living up to the standards either of us want. On 1/24/2014 9:35 AM, ics wrote: > There are only 2 solutuins where one is good and one is tolerable. > > The good one would be removing all the crap servers from quickplay but > thats too much work for them. The tolerable option, since there is no > going back is to take that tick off from the box that makes people > search servers among official valve servers only by default. > > -ics > > Jake Forrester kirjoitti: >> I don't generally post to this list, but I would like to add some >> statistics from my community. McKay already posted some of them, but >> here are some more numbers. >> >> We run 3 dedicated boxes, and about 20 total TF2 servers. Of those, 14 >> are quickplay. The quickplay servers are mostly vanilla, with some >> various donor perks that don't affect gameplay whatsoever. In the last >> month we have seen about***140,000 unique players* and *475,000 >> individual sessions*. We're not a gigantic community, but we're >> definitely not small either. At least 2500 players have > 24 hours of >> play time on our servers, and I don't really see those players >> disappearing--at least not right off. >> >> Our community relies 100% on donations, so a temporary decrease in >> quickplay traffic wont affect us at all in regards to keeping our >> servers up (no ad revenue). But looking at our server list this >> morning, I noticed that our Chicago system which usually has 7 servers >> full around this time of day instead has 3. If we're unable to keep our >> servers full, I'm sure the donors will eventually start to dwindle as >> well. >> >> Now there's no real way for community owners to fight back. Really our >> only defense is to post to the mailing list and hope our message is read >> by a Valve employee, but that alone doesn't create change. If we can >> all band together behind a single solution though, it certainly wouldn't >> hurt our cause. >> >> That said, let's get the ball rolling on some ways we can help Valve >> combat players getting matched into terrible quickplay servers, without >> ripping apart the communities which make this game so great. >> >> Here are a couple of my ideas: >> >> *1) Quickplay ID Grouping* >> Have the ability to register a community/group ID to associate different >> quickplay IDs. This way if one server breaks the terms of service, they >> can all be shut down fairly easily. Of course, this incentivises good >> communities to use this option, and the troll/spam/greedy ones not to >> use it. I think that's fine. Prioritize traffic of those communities >> who have > 2 servers on the same group ID, and make it a little bit >> harder to start out without a community ID (sorry new folks, but I don't >> see an elegant solution here for you). >> >> *2) User-based voting* >> For all users matched through quickplay, have them actually rate the >> server they were connected to once they leave. A simple 1-5 star system >> and a "flag as abusive" button to start a ticket would be great. If a >> user has already rated that server, show their previous vote and allow >> them to change it. By not allowing the same user to repeatedly vote on >> the same server would help cut back on people down-voting other >> communities just to get more traffic sent to their own. This can work >> with the first idea to rank communities as a whole. So if you run a >> solid community and launch a new server, it wont be so hard to fill it >> up. You've proven your worth, and you shouldn't need to do it with >> every server launch. But if you run a poor community, it will affect >> all your servers. >> >> *3) Un-check the box >> *Everyone else said it. Don't pick valve servers for people by >> default. I think it's totally fine to have that option available, but >> pulling all the players away who don't really understand what that means >> doesn't seem fair. I believe new players are alr
Re: [hlds_linux] Prevent game servers from redirecting players to alternate servers when players connect through quickplay
I also wanted to quickly point out that according to McKay's graph (http://i.imgur.com/91xNnU1.png), quickplayers are mostly free-to-play folks. This means that Valve has made absolutely no money on them in regards to TF2. The people who are using the community market and buying things in the Mann Co Store are the ones who generally play on community servers. The whole "I want to look cool in-game" business model doesn't really work on people who are constantly playing with randoms. Users need to get matched to community servers in order for them to regularly play with the same people, make in-game friends, and ultimately buy items. I'm sure Valve has more statistics on that that we do, but from what where I sit, this decision seems somewhat silly. Maybe their hopes are that less people will use the quickplay system, which could totally happen, but not before a bunch of good communities die out due to lack of traffic. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
Re: [hlds_linux] Prevent game servers from redirecting players to alternate servers when players connect through quickplay
I don't generally post to this list, but I would like to add some statistics from my community. McKay already posted some of them, but here are some more numbers. We run 3 dedicated boxes, and about 20 total TF2 servers. Of those, 14 are quickplay. The quickplay servers are mostly vanilla, with some various donor perks that don't affect gameplay whatsoever. In the last month we have seen about***140,000 unique players* and *475,000 individual sessions*. We're not a gigantic community, but we're definitely not small either. At least 2500 players have > 24 hours of play time on our servers, and I don't really see those players disappearing--at least not right off. Our community relies 100% on donations, so a temporary decrease in quickplay traffic wont affect us at all in regards to keeping our servers up (no ad revenue). But looking at our server list this morning, I noticed that our Chicago system which usually has 7 servers full around this time of day instead has 3. If we're unable to keep our servers full, I'm sure the donors will eventually start to dwindle as well. Now there's no real way for community owners to fight back. Really our only defense is to post to the mailing list and hope our message is read by a Valve employee, but that alone doesn't create change. If we can all band together behind a single solution though, it certainly wouldn't hurt our cause. That said, let's get the ball rolling on some ways we can help Valve combat players getting matched into terrible quickplay servers, without ripping apart the communities which make this game so great. Here are a couple of my ideas: *1) Quickplay ID Grouping* Have the ability to register a community/group ID to associate different quickplay IDs. This way if one server breaks the terms of service, they can all be shut down fairly easily. Of course, this incentivises good communities to use this option, and the troll/spam/greedy ones not to use it. I think that's fine. Prioritize traffic of those communities who have > 2 servers on the same group ID, and make it a little bit harder to start out without a community ID (sorry new folks, but I don't see an elegant solution here for you). *2) User-based voting* For all users matched through quickplay, have them actually rate the server they were connected to once they leave. A simple 1-5 star system and a "flag as abusive" button to start a ticket would be great. If a user has already rated that server, show their previous vote and allow them to change it. By not allowing the same user to repeatedly vote on the same server would help cut back on people down-voting other communities just to get more traffic sent to their own. This can work with the first idea to rank communities as a whole. So if you run a solid community and launch a new server, it wont be so hard to fill it up. You've proven your worth, and you shouldn't need to do it with every server launch. But if you run a poor community, it will affect all your servers. *3) Un-check the box *Everyone else said it. Don't pick valve servers for people by default. I think it's totally fine to have that option available, but pulling all the players away who don't really understand what that means doesn't seem fair. I believe new players are already being matched to Valve servers with super high priority, until they spend a few hours in the game and get a feel for what a 100% vanilla, un-moderated server is like. Good! Keep doing that. Just don't grab the players who aren't new to the game, but haven't learned how to connect anywhere without quickplay button. ~ rann ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
Re: [hlds_linux] Add something to the game so that server ops can ban HWID too.
I could honestly care less how it's done, so the easiest method seems to be the best. It really doesn't seem like it would be hard to implement, but none of us can see the inner workings of how things are setup at Valve. Either way, it would seem a worthwhile endeavor. On 9/5/2013 6:32 AM, Doctor McKay wrote: > The idea of assigning a server a Steam ID is an interesting one, but we > actually already have a system for this, at least in TF2. If a server is > logged in to Steam, then when you favorite it you could actually favorite > the server's account ID. Then the favorites list would retrieve the > server's current address from Steam based on the account ID. > > This could also be an additional benefit to registering your server beyond > just Quickplay participation (which is only relevant if you're not running > custom maps/mods) and event participation (which is only relevant about two > weeks out of the year). > > > Dr. McKay > www.doctormckay.com > > > On Thu, Sep 5, 2013 at 9:14 AM, Mart-Jan Reeuwijk wrote: > >> yeah, problem is, brick wall in front of that guy. >> >> If I have a bunch of favorited servers, and a server drops off due a IP >> change, that server wont see me back. For: >> A: I'm not even aware the server is gone, unless its a special mod that I >> like. >> B: As I have enough other favorites, I wont be searching for servers in >> the internet tab. >> Majority of servers out there run mandatory Pinion nowadays, so searching >> for new servers is a pain anyways. >> >> And NO, I'm NOT looking for EMPTY servers. So I sort on # of players on >> it, and look for a map I like. >> >> But the most important question is: Would I like to keep the server in my >> Fav's, regardless of their IP? >> >> And the answer is yes, for once they made it to my favs, the server proved >> to me to not be a bad one (pinion R**e, lag, crap plugins, etc) >> That is the purpose of my Favorites to me: get back to servers that didn't >> make me a bad experience. If one such changed, for example add Pinion, and >> I didn't like it anymore, I leave and remove it from favs... >> >> That is the "special" part of having a Favorite server list, those servers >> earned to be there. >> >> >> ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
Re: [hlds_linux] Add something to the game so that server ops can ban HWID too.
This, or SRV support are both acceptable solutions. Then we can finally drop our current host... as it stands now the IPs are worth more than re-seeding all our servers when our provider goes down every other day. 100% support on this issue. On 8/27/2013 9:52 AM, Andrew Simpson wrote: > It seems to me that the more logical thing to do would be to give servers a > permanent SteamID, and then give the client the ability to connect to a > SteamID (as well as directly to an IP, you want to still support offline > LANs), save the SteamID of a server in the favourites, etc. The client > could then retrieve the actual IP/port of a server by querying Steam. > > Then you can easily change the server IP and port of a server without any > messing around with DNS records or anything like that, automatically at the > same time you report to the master server. > > Steam already does something similar for peer-to-peer games, Steam provides > an API for networking by sending messages to a SteamID, and it sends UDP > packets under the covers. > ___ > To unsubscribe, edit your list preferences, or view the list archives, please > visit: > https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux -- Jake Forrester Freelance Web Developer/Designer & Joomla Enthusiast e: j...@ranndesigns.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
Re: [hlds_linux] Source engine games Steampipe conversion schedule
I don't know of many betas where you can keep the items you earn. This could be negated by removing drops entirely from beta, and giving everyone access to one of every weapon and a handful of hats, but I imagine they want to mirror production as close as possible. The reward is knowing how things are going to change so you can develop/configure things before a feature goes live. Also, if you have to add "no offense" to a statement, it makes you sound like a jerk (no offense to jerks) for even completing the sentence. On 4/4/2013 9:42 AM, CG wrote: > I understand why they're doing it and for the most part is for the better. > Doesn't mean I have to like it. I don't know how many times I've seen > people ask where their items were from regular TF2 or wish they had their > regular items. > > Fletcher's claim that time you spent in TF2 Beta counts towards time in > regular TF2 never worked for me at least how I think it's supposed to > work. Let's say you spent 10 hours playing in TF2 Beta and get the normal > variety of drops. I thought as soon as I fired up regular TF2 I would have > items waiting in TF2. This gives no incentive for players in Beta to > continue. > > Let's face it TF2 Beta was always treated like the red headed stepchild (no > offense to gingers). It was poorly maintained by Valve prior to SteamPipe > and shunned by SourceMod with support (understandably). And from the sound > of things they will do it again once when they flip the switch to the new > TF2 Beta. I hope they do a more sensible thing and reward those that have > continued to play the game and allow them to keep their weapons, > hats, misc and just convert them into regular items as I understand it > would affect Mannconomy. Plus it wouldn't hurt to give them extra backpack > space to accomodate said items. I could just be blowing smoke out of my > ass since they haven't announced what will happen exactly. > On Wed, Apr 3, 2013 at 11:27 PM, ics wrote: > >> When beta was restarted while back (as in, put back into play), there was >> a note that any of the items may disappear at any time. So those items are >> void and you cannot bring something valuable from beta to main game. >> -ics >> > ___ > To unsubscribe, edit your list preferences, or view the list archives, please > visit: > https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux -- Jake Forrester Freelance Web Developer/Designer & Joomla Enthusiast e: j...@ranndesigns.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
Re: [hlds_linux] Mandatory Team Fortress 2 update released
Why not just require servers that run advertisements to add an "ads" tag, then add two checkboxes to quickplay: 1) Disable servers with ads 2) Change maxplayers to 32 Much like those who were running fake clients, penalize those who are attempting to hide their ad-based server tags by removing them from quickplay. This method would also allow for 32 player servers to effectively compete in the quickplay market (another argument, I know). This change hardly affected our servers due to most the benefits users play with via the MOTD are for donors only, which quickplayers wont have access to anyway. However, this does mean that I will personally never click the quickplay button again, due to potential lost user experience with various mods (radio is a big one). Not that one user means anything to Valve though. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
Re: [hlds_linux] [hlds] Reminder about server tags
s 10 snipers. If I can't play a > class, it isn't a vanilla experience. > - Alltalk: I really need to strategize with quickplay noobs, and alltalk > ruins my vanilla experience. > - Ability to change maps: As a player, I am entitled to an accurate > indication that the servers I am sent to only has quickplay maps or that > the map doesn't switch right after I join. > > F*ck these server owners right? Who the do they think they are ruining the > way I want to play TF2? This is satire if you couldn't tell. All I see here > is a constant erosion of the rights of server owners. Valve penalizing > larger servers while letting pay-to-win servers off the hook is a sad > perversion of priorities. > > On Wed, Mar 6, 2013 at 2:01 PM, Rudy Bleeker wrote: > >> I kinda hoped this thread was over, but apparently it's not. In that >> case let me chip in as well. I also kind of agree with Dan. It's all >> about the difference between the exact wording of the rules and their >> intention. Some people on here would do well to read up on that, so >> for your convenience: >> http://en.wikipedia.org/wiki/Letter_and_spirit_of_the_law >> >> In this case I think it's clear that with the quickplay system Valve >> intended to give Team Fortress 2 players a predictable and constant >> game experience. So farming the quickplay system for traffic to your >> server and then changing that server to something that's not eligible >> for quickplay is wrong, no matter how the rules were written. I >> sincerely hope this practice will stop and that the servers in >> question will be banned (again). >> >> On Wed, Mar 6, 2013 at 9:55 PM, Game-Over >> wrote: >>> I have to say I'm with Dan on this one, and he often seems to stand >> alone, >>> so I felt I had to say something. >>> >>> Having monitored this group for nearly 2 years, I have come to the >>> conclusion that it is mostly populated >>> by youngsters, who have no life experience to speak of. The excuses used >>> here by some that "Valve never >>> said we couldn't do this" or "there's nothing in the rules that say we >> can't >>> do this", leads me to believe that >>> they rely on parents to tell them when they are doing wrong and they >> simply >>> can't work it out for themselves. >>> >>> This latest trend of using a plugin to switch on Quickplay up to 24 >> players, >>> and then when at 24/24 switch off Quickplay >>> and convert the server to 32 players, instaspawn, with the argument that >>> "tell us where we are breaking the Policy of >>> Truth rules", is quite frankly mind boggling. Lets just forget about >> those >>> players who thought they were joining a >>> stock TF2 server and who end up with 24/7 32 man 2fort spammage, because >>> it's fine as Valve never said that >>> using this particular plugin this was wrong. No Heroes (cough). >>> >>> I blame Pinion as it has opened the gates for children to run servers. >> Good >>> old fashioned honesty, decency and integrity, >>> not to mention thinking of the players and not your pockets. You learn >> these >>> things as adults. >>> >>> Why Valve backtracked on their latest purge of bans is beyond me. They >> have >>> lost their backbone and I'm extremely >>> disappointed. I hope they find their backbone again soon. >>> >>> >>> On 06/03/2013 20:11, dan wrote: >>>> On 06/03/2013 18:18, Gordon Reynolds wrote: >>>>> I'm glad we decided to take the high road here and didn't resort to >>>>> calling >>>>> each other scumbags based on how they want to run their video game >> server >>>>> :) >>>> >>>> Yeah his was such an erudite and polite message. >>>> Sheesh. >>>> >>> >>> ___ >>> To unsubscribe, edit your list preferences, or view the list archives, >>> please visit: >>> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux >> >> >> -- >> Idleness is not doing nothing. Idleness is being free to do anything. >> - Floyd Dell >> >> ___ >> To unsubscribe, edit your list preferences, or view the list archives, >> please visit: >> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux >> > ___ > To unsubscribe, edit your list preferences, or view the list archives, please > visit: > https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux -- Jake Forrester Freelance Web Developer/Designer & Joomla Enthusiast e: j...@ranndesigns.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
[hlds_linux] Crashes since last update
On average, srcds tends to crash about once a week (per server). Since this last update, there has been ~2 crashes per day per server. Not sure if it's just our servers or if everyone is affected. I'm not an srcds person, so I can't provide much information, but I didn't see anything noticeable in the log files. The servers just seem to die without a trace. This is on an under-utilized Centos 6.3 (32-bit) machine. Anyone else experiencing this? Thanks in advance -- Jake Forrester Freelance Web Developer/Designer & Joomla Enthusiast e: j...@ranndesigns.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
Re: [hlds_linux] Random server oddities.
Seconded. On 1/25/2013 5:05 PM, Essay Tew Phaun wrote: > I feel like I've been posting a lot here lately. Either that's a testament > to my stupidity or there are a lot of issues with SRCDS. Here's another one > I posted about months ago but got no real answers on. We've recent switched > providers and have a brand new TF installation and this problem still > occurs as it did with our previous provider (We didn't change providers due > to this, just saying). Any of the following will happen at random: > > Doorways will turn to flat colors that allow you to see through walls. > Everyone experiences this and it's not clientside. > Payload carts will get stuck on the track or when the round begins will > show on the progress indicator as being near the end. > Doors will be open during setup when they shouldn't be, allowing the BLU > team to exit. > Doors will not open after setup ends. > Randomly you won't be able to pick up the Intel on 2Fort. This may happen > elsewhere, this is the only CTF map we run. > > All of these happen at random but happen with enough frequency where it's a > real problem for us. We usually have to reload the map to fix it. Doomsday > had a similar problem where the rocket would completely disappear. Is this > sort of thing specific to a SRCDS installation on Linux? We've already > tried deleting the contents of maps/graphs and that doesn't seem to prevent > the issue. > > 2.6.32-279.19.1.el6.i686 #1 > CentOS 6.3 32bit > > Thank you. > ___ > To unsubscribe, edit your list preferences, or view the list archives, please > visit: > https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux -- Jake Forrester Freelance Web Developer/Designer & Joomla Enthusiast e: j...@ranndesigns.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
Re: [hlds_linux] Servers get attacked via DDoS
ing the admins of the broken DNS >>>>>> servers (short of just bluntly increasing the bandwidth capacity of >>>>>> the affected server(s) and 'sitting it out'). >>>>>> >>>>>> See also: http://blog.cloudflare.com/65gbps-ddos-no-problem >>>>>> >>>>>> €0,02 >>>>>> >>>>>> On 11-1-2013 10:52, Sachin Sud wrote: >>>>>>> My intensions are not to spam this mail list. >>>>>>> But if you guys are comfortable , you need to answer few >>>>>>> questions >>>>> by >>>>>>> which >>>>>>> i can help you better to get saved from ddos attacks. >>>>>>> >>>>>>> Which country are you from? >>>>>>> How many game servers you host? >>>>>>> How often the attack happens? >>>>>>> Is it specific to any particular game? >>>>>>> Which OS you have on server? >>>>>>> What kind of firewall you use , in case if you use any >>>>>>> And last question How much money you spend monthly on servers ( >>>>> Based on >>>>>>> your location, i can recommend some ddos protection if required ) >>>>>>> >>>>>>> Thanks, >>>>>>> Sachin >>>>>> ___ >>>>>> To unsubscribe, edit your list preferences, or view the list >>>>> archives, >>>>>> please visit: >>>>>> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux >>>>> ___ >>>>> To unsubscribe, edit your list preferences, or view the list >>>>> archives, please visit: >>>>> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux >>>> >>>> ___ >>>> To unsubscribe, edit your list preferences, or view the list archives, >>>> please visit: >>>> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux >>>> >>> ___ >>> To unsubscribe, edit your list preferences, or view the list archives, >>> please visit: >>> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux >>> >>> ___ >>> To unsubscribe, edit your list preferences, or view the list archives, >>> please visit: >>> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux >> ___ >> To unsubscribe, edit your list preferences, or view the list >> archives, please visit: >> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux > > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux -- Jake Forrester Freelance Web Developer/Designer & Joomla Enthusiast e: j...@ranndesigns.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
Re: [hlds_linux] Large Gaps in the net_graph
These rates helped significantly, but there's still gaps + spikes when switching between players--they're just a little smaller now. When I was testing the new rates, TF2 crashed with no errors, and just seemed to disappear right from under my mouse. But I suppose that's another issue for another time. My rates were: rate 4 cl_cmdrate 33 cl_updaterate 33 cl_interp 0.1 Using 66 instead of 33 is the closest thing to a proper fix I've seen yet! Is this something that can be implemented on weaker client systems without worry? Our servers don't have replay enabled for the same performance reasons. Not ideal, but nothing ever is. I don't recall many people really complaining about it. Thanks for the help, Jake On 1/6/2013 10:55 AM, dan wrote: > On 05/01/2013 19:43, Jake Forrester wrote: >> Thanks for the info. I did some testing with r_lod 0 and it seems to >> have helped significantly, but there are still some spikes. For the >> most part, the gaps are gone or so small that they're not a big deal, >> except for cases where it isn't really an issue, such as during a new >> round team spawn. Here are some screenshots of gameplay, respawn, and >> new round: http://imgur.com/a/gHAKO > > I wouldn't have changed r_lod. You don't seem to have a rendering > problem your fps is sky high. > > Looking at your net_graph you have defaults? > > What's the rate set to? > > I usually have > > rate 6 > cl_cmdrate 60 > cl_updaterate 60 > cl_interp 0 <-- it will use the lowest here, usually 30 ms > > rate any lower than 3 (if forced by the server especially) fails > badly ime so watch out for that. > > I've seen some servers force it to higher values like 9, these > servers generally don't work well either (but that might not be > related to the rate setting, they tend to have hundreds of servers so > no doubt aren't interested in quality) > > I've played all afternoon on Valve's lux servers, mostly ctf maps and > it's been great - much better since they added the lux servers than > they have ever been and no great lags or anything. So perhaps Fletcher > will spill their secret :) I note the biggest difference (with their > old servers pre mvm) is the current ones don't have replays enabled) > -- Jake Forrester Freelance Web Developer/Designer & Joomla Enthusiast e: j...@ranndesigns.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
Re: [hlds_linux] Large Gaps in the net_graph
Thanks for the info. I did some testing with r_lod 0 and it seems to have helped significantly, but there are still some spikes. For the most part, the gaps are gone or so small that they're not a big deal, except for cases where it isn't really an issue, such as during a new round team spawn. Here are some screenshots of gameplay, respawn, and new round: http://imgur.com/a/gHAKO For anyone who has a good enough video card, my recommendation is to try running with r_lod 0 to see if it helps. If you do, report back with your findings so I know I'm not just crazy. For those with weaker video cards: play on maps where there aren't large groups of players around corners, or learn to deal with being unable to aim and unable to see enemies until this is patched! To answer your question regarding processor affinity, no, they are not limited to a single core. The CPU load never goes above 25% even when all the servers on the box are full, there's plenty of RAM left over, and we're at about 10% of maximum bandwidth. No issues with IOwait either. From the server standpoint, everything appears to be working great with the exception of the occasional crash due to no free edicts. On 1/5/2013 1:32 PM, ics wrote: > If you started seeing spikes recently, after the xmas update, there's > that spam in the console that makes my own game lag like hell when it > happens. Screen even jams occasionally. > > Before that, i saw mostly players going fast forward with leaping > place to another when issues like this occurs. It's just some players, > just as some packets would be "lost" (or not given to you) at that > time and only part of his actual movement is shown (like packet 3, 35 > 64 and not 3,12,23,35,43,51,64,76,89 etc). As i recall, this started > long ago, at the time that valve optimized the code and bandwidth > usage for servers dropped at the same time. > > Also one other thing happened at that t ime, which is that now the > game draws only players that are around the next corner and not the > ones at next corner and after the next one. This of course can be > coped with some optimization on maps but this is now default setting. > If you want to experience this as a test, go in map harvest and if you > spec a sniper that is in the roof but is not peaking over the rooftop > to middle. You cannot see the enemies that are in area on front of the > rooftop. However, as soon as he peaks over, the enemies magically > appear for your screen, which means you see the same thing as he does. > Only he cannot see what you see from above his head, sooner than he. > So if you see the enemies and he is peeking over and then goes down > crouching, those enemies will disappear. > > Before Valve did the optimization over a year ago, as a 3rd person, > you could see all that is happening on the battlefield while > spectating a person. Now, this effect happens. In some rare and not so > rare cases, it can lead to sudden lag as your hardware tries to catch > up on whats going on at the screen. Naturally this part has nothing to > do with servers themselves, it's just ingame thing on players. That > recent dynamic model loading might have done this even more visible > but i think they are loading the models that should be coming up in > advance but i have no way of knowing how advanced that system is at > guessing what comes next. > > But also one question, do you force your servers to run on specific > cpu core? I've also seen that causing similiar lag effect. > > -ics > > 5.1.2013 19:53, Jake Forrester kirjoitti: >> I have the exact same issue. When turning the corner, getting team >> changed, or just running into a bunch of other players, I get huge >> spikes in my graph (with gaps). It's gotten so bad that it can become >> impossible to aim during large enemy encounters, so I've just given up >> on TF2 for the time being. I guess on to DOTA? Kind of sucks being in >> charge of a server that you can't even play on. >> >> On 1/5/2013 11:49 AM, Essay Tew Phaun wrote: >>> I know this isn't exactly scientific but we weren't having these >>> reports of >>> lag before. Of course, you're always going to have a few people >>> complaining >>> about lag and blaming their performance on it, but recently, >>> probably as of >>> the big update (Halloween or Mecha, not sure which) We've seen a >>> humongous >>> rise in the complaints about lag. Whether that's the cause of the >>> server or >>> client, I guess that remains to be seen, but we're having a lot of >>> complaints and have done everything we can on our end to try and >>> address it &g
Re: [hlds_linux] Large Gaps in the net_graph
I have the exact same issue. When turning the corner, getting team changed, or just running into a bunch of other players, I get huge spikes in my graph (with gaps). It's gotten so bad that it can become impossible to aim during large enemy encounters, so I've just given up on TF2 for the time being. I guess on to DOTA? Kind of sucks being in charge of a server that you can't even play on. On 1/5/2013 11:49 AM, Essay Tew Phaun wrote: > I know this isn't exactly scientific but we weren't having these reports of > lag before. Of course, you're always going to have a few people complaining > about lag and blaming their performance on it, but recently, probably as of > the big update (Halloween or Mecha, not sure which) We've seen a humongous > rise in the complaints about lag. Whether that's the cause of the server or > client, I guess that remains to be seen, but we're having a lot of > complaints and have done everything we can on our end to try and address it > including moving down to 24 player servers which we did *NOT *want to do. > The problem is still there. An hour or so ago I loaded up a completely > vanilla server with no MM:SM, the same issue appears. > > We get the gaps and spikes in the net_graph a lot. I get HUGE gaps when > going in to a new area of a map a lot of the time. Here's a screenshot from > just now when I tested. > > http://i.imgur.com/4V1TZ.jpg > > -- Jake Forrester Freelance Web Developer/Designer & Joomla Enthusiast e: j...@ranndesigns.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
[hlds_linux] Too many simultaneously active particles
Greetings everyone, Has anyone else experienced users complaining of lag while there is both no ping issues, and no packet loss? I did some digging and was able to find these errors being thrown in consoles of users who have run into this: /Particles: maximum verts exceeded: 71532 verts, 104382 indexes// //Too many simultaneously active particles!// //Particles: maximum verts exceeded: 74144 verts, 108414 indexes// // //Cannot update control point 1 for effect 'muzzle_grenadelauncher'.// // //Cannot update control point 3 for effect 'cart_flashinglight'.// // //Cannot update control point 0 for effect 'player_sparkles_blue'.// //No such variable "$colortint_tmp" for material "models/player/items/engineer/engineer_top_hat_red"// //Error: Material "models/player/items/engineer/engineer_top_hat_red" : proxy "ItemTintColor" unable to initialize!// //No such variable "$colortint_tmp" for material "models/player/items/engineer/engineer_top_hat_red"// //Error: Material "models/player/items/engineer/engineer_top_hat_red" : proxy "SelectFirstIfNonZero" unable to initialize!/ I've also sees references to these errors outside of our servers: http://i192.photobucket.com/albums/z12/shadowz_bucket/jjj_zpsc6c5dfc2.png http://steamcommunity.com/app/440/discussions/0/846940248946859430/ Thanks -- Jake Forrester Freelance Web Developer/Designer & Joomla Enthusiast e: j...@ranndesigns.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
Re: [hlds_linux] Servers still getting stuck, freezing, 100% CPU.
Same here. Had to restart one just this morning. On 11/17/2012 9:47 AM, Sampson Rogers wrote: > Seems this issue remains. I'm having to restart roughly 2 or 3 servers a > week due to this. > > http://i.imgur.com/9qWYK.jpg?1 > ___ > To unsubscribe, edit your list preferences, or view the list archives, please > visit: > https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux -- Jake Forrester Freelance Web Developer/Designer & Joomla Enthusiast e: j...@ranndesigns.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
