>and your server contains bots. No bots (not even STV). > totally based on the visible max. Ah, so I'm presuming that's the case too with the GMS (the actual field is ignored)?
I'll try gaming our queries to Steam and see if that declines in user reports. Thanks, Kyle. On Thu, Dec 26, 2013 at 5:20 PM, Fletcher Dunn <fletch...@valvesoftware.com> wrote: > The server browser doesn't know anything about the actual max, it is totally > based on the visible max. > > -----Original Message----- > From: Kyle Sanderson [mailto:kyle.l...@gmail.com] > Sent: Thursday, December 26, 2013 5:19 PM > To: Fletcher Dunn; Half-Life dedicated Linux server mailing list; Half-Life > dedicated Win32 server mailing list > Cc: Eric Smith > Subject: Re: [hlds] [hlds_linux] [Regression] Horribly inaccurate player > counts from Steam. > > Is that the visible max, or the actual max? We only recently removed > sv_visiblemaxplayers as a result from this about a week and a half ago; no > improvement. > > Kyle. > > On Thu, Dec 26, 2013 at 5:15 PM, Fletcher Dunn <fletch...@valvesoftware.com> > wrote: >> "full" should mean that the player count in the ping >= the max player count >> in the ping. >> >> -----Original Message----- >> From: Kyle Sanderson [mailto:kyle.l...@gmail.com] >> Sent: Thursday, December 26, 2013 5:14 PM >> To: Half-Life dedicated Win32 server mailing list; Half-Life dedicated >> Linux server mailing list; Fletcher Dunn >> Cc: Eric Smith >> Subject: Re: [hlds] [hlds_linux] [Regression] Horribly inaccurate player >> counts from Steam. >> >> There may be logic missing from cstrike if being full is the case (or >> missing from the GMS, if it's implemented there). My C++ classes, >> CheckValve, and the collection of PHP querying classes from xPaw all show >> the server as being full from the old masters. >> >> It may also not be staying full (just under, from our AFK Manager), and >> players are thinking they shouldn't encounter it as the GMS is returning 10+ >> free slots. The human element may be wrecking the full implementation. Maybe >> we'd be better off faking being full if we've passed a threshold? Client's >> that return true from IsClientFullyAuthenticated should be part of the list; >> right? >> >> Kyle. >> >> On Thu, Dec 26, 2013 at 4:56 PM, Fletcher Dunn <fletch...@valvesoftware.com> >> wrote: >>> The server browser queries the server and then checks the numbers >>> from the ping against authenticated player counts from Steam. If >>> there is a difference, then it performs a reconciliation according to >>> some logic that is not totally brain-dead. For example, one of the >>> heuristics it uses is that if the server reports that it is full, >>> then it will trust the server, no matter what Steam says. (Because >>> of the exact problem you describe.) >>> >>> So I'm not sure that the problem is that Steam service is intermittent. I >>> think the problem is that the server is not reporting itself as full? When >>> you use a tool such as HLSW, which doesn't talk to Steam at all, does the >>> data in the ping show the server as full? >>> >>> -----Original Message----- >>> From: hlds_linux-boun...@list.valvesoftware.com >>> [mailto:hlds_linux-boun...@list.valvesoftware.com] On Behalf Of Kyle >>> Sanderson >>> Sent: Thursday, December 26, 2013 3:33 PM >>> To: Half-Life dedicated Linux server mailing list; Half-Life >>> dedicated >>> Win32 server mailing list >>> Cc: Eric Smith >>> Subject: [hlds_linux] [Regression] Horribly inaccurate player counts from >>> Steam. >>> >>> So a few weeks (probably months now, actually) ago all of the in-game >>> client tabs were moved to rely on data from Steam, instead of querying the >>> actual server. Which is fine, this most likely hurt fake players users >>> quite significantly. >>> >>> However, from what started off as a few players incorrect (4~) has greatly >>> increased. We're up to 14~ phantom slots, as the players clients are >>> broken, or Steam is having trouble keeping up. This results in an actually >>> full server (64/64) showing as 50/64. Client's are now unable to externally >>> queue to join the server, it's actually pretty horrible. If servers are >>> given an unverified leeway of 15% of their verified players, it might be >>> enough to span the gap for those broken steam clients. >>> >>> We run some pretty large servers, so this doesn't impact us as much. >>> Well, besides an endless amount of player reports, which is starting to >>> take it's toll. However, if you're running a TF server with 24 slots, and >>> 10 of them are empty... that's quite the thing. >>> Alternatively, if the max-player defines are increased, that would work as >>> an interim solution. >>> >>> A revert, or fix would be much appreciated. I don't believe this is easily >>> fixable, as Steam's actual up time is around 80%. >>> >>> Kyle. >>> >>> _______________________________________________ >>> 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 _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds
