I believe this is the same issue I reported here a few times many months ago on the list as "Ghost Players" that keep appearing in a couple of my TF2 servers. These two TF2 servers report anywhere from 1 to 4 empty player slots every day during a 24-hour period and the servers appear full even though there are only 20-24 real players in them. Neither of the servers have bots in them when the problem occurs.
The issue only occurs on my servers that I run stock Valve maps on and have registered with Quick-play. The other servers I run with custom maps and are not registered never the problem. It's almost like players are attempting to connect to the server via Quick-play and if the connection fails to complete leaving their assigned slot un-usable by anyone else but them.. I suppose this could be either because of a problem with the player's TF2 client or they simply cancel their connection while they are getting the server info and the map is loading. The slot is taken and never released when they fail to connect completely. I did however learn that if the same player successful connects after retrying, they grab the empty slot that was originally created for them and the slot is cleared upon a graceful exit from the server. Currently, the only way to resolve it is by restarting the server and kicking all the players ever morning in order to clear the empty slots. Sure hope someone finally looks into this. Happy New Year. From: Doctor McKay [mailto:mc...@doctormckay.com] Sent: Thursday, December 26, 2013 5:47 PM To: Half-Life dedicated Win32 server mailing list Subject: Re: [hlds] [hlds_linux] [Regression] Horribly inaccurate player counts from Steam. Just for the record, I have not noticed any player count discrepancies in my TF servers, nor have any players reported any discrepancies to me. Dr. McKay www.doctormckay.com On Thu, Dec 26, 2013 at 8:33 PM, Fletcher Dunn <fletch...@valvesoftware.com> wrote: I'd start my investigation by confirming that the raw ping from your server is correct and what you want it to be (using hlsw or something similar). -------- Original message -------- From: Kyle Sanderson Date:2013/12/26 5:25 PM (GMT-08:00) 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. >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
_______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds
