I'm not sure if you guys realize this, because I keep seeing sv_unlag being referenced as "giving this bug to everyone", which would lead people to believe that it is bugged. Should have thought about it more thoroughly because that seems to be correct, as setting it to 0 turns netcode off for everyone (like it should) but setting it to 1 only turns it off for everyone but 1 (like Kalias said)?
So I guess the real question now is, when is VALVe going to fix this <!--emo&:0--><img src='http://www.unknownworlds.com/forums/html//emoticons/wow.gif' border='0' style='vertical-align:middle' alt='wow.gif' /><!--endemo-->
Added: Bleh, I'm such a tard.. didn't even give thanks where it is due. Awesome job, really appreciate all the work put into finding out all this info <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo-->
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> actually this "bug" you've found is a common glitch in cs. A while back there was an article on gotfrag which fixed this. Explained some of the serverside commands/client commands that could make hitboxes more accurate threw rates, cl_cmdrate, cl_updaterate, ex_interp ect ect..
R a v e N` <!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd--> While a link would be lovely, I don't accept that changing your rates and network settings will make a difference when ONLY 1 player's model is rendered wrong. Screwing with those settings (and especially if you have no idea what works with your internet connection) will affect how you see everyone.
The post doesn't state sv_unlag as a bug... it's more like... having the effect of sv_unlag 0 on a single player while everyone else in the server has sv_unlag 1 (when the server is set to sv_unlag 1).
As for the comment by nsaRaveN re: 'common glitch in cs', I believe that is a completely different issue, having nothing to do with what this topic involves.
edit- cripes... what a daft way to spend the milestone of 200 posts...
I don't think anyone is saying that sv_unlag is a bug, we know it's a "feature". But if PSHB is related to sv_unlag, then it's quite possible that the "feature" itself is bugged. If you understand what I mean.
Just a little extra technical information to help people understand this a tad better.
When you start an <i><b>n</i></b>-player server, entity IDs 1-<i><b>n</i></b> are reserved to represent connected players. It is for this reason that you cannot change the max players after the server has been started.
When you type status in your console, you see a list of the players' names, along with other info such as their SteamID, time connected, ping, loss, etc. The first bit of information shown, before the player's name, is the player's entity index (The reserved entity number which is referring to that player.) See attached screenshot.
Regardless of how many slots a server claims to have, there is a "true" number of slots which will never be exceeded because ONLY <i><b>n</i></b> entities are reserved for players. It is impossible to have <i><b>n</i></b>+1 players connected.
What I am uncertain of, however, is with a server that displays a certain number of slots, are ALL PLAYERS >= that number "bugged", or only the player with the entindex <i><b>n</i></b>?
The community would be useful in helping us discover this bit of information. Normally, the way I reproduce the PSHB is to create a 2-player HLDS and have two players connect that are NOT on a local area network with the server. Have the bugged player (verify with status) become a Fade with Celerity, Carapace, and 3 hives. (This makes him move faster, and gives him sufficient health to take many hits without stopping to be healed.) Have the fade strafe back and forth in front of a long wall while the other player, as a marine, aims an HMG directly at the fade's model and fires at it as he moves. The fade should take very little or no damage! For control purposes, repeat the process with the non-bugged player as the fade. He should take normal damage.
Let us know what you find out! Is it only player #<i><b>n</i></b> that is bugged, or are all players between <i><b>x</i></b> (max visible slots) and <i><b>n</i></b> bugged?
Thanks in advance.
*edit: The current prevailing speculation among we exterminators is that the lag compensation code parses players in the entindex with a for loop which terminates one player too soon, as posted earlier in the thread, with a < maxplayers instead of the necessary <= maxplayers. As a result, only the last player is failed in the loop. This may be clientside code, and if it is, servers which tell the player that they have <i><b>x</i></b> slots might cause players between <i><b>x</i></b> and <i><b>n</i></b> to be bugged as well. I await your test info, people. <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo-->*
<!--QuoteBegin-Soylent green+Jul 25 2004, 06:28 AM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Soylent green @ Jul 25 2004, 06:28 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Maybe it could even be done as a plugin without touching the MOD code, a bot of somekind that allways sits in spectator and does whatever it takes to become the bugged last player in the list? <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd--> Well. Lets say you want to have a 16 player public server. You'd need a server with 17 slots, have one be hidden to the server browser and have a bot installed on the server that would wait until the 16th player connected and then the bot would "connect" and never disconnect. But, it would have to be able to do the same thing on every map change.
I believe there are some plugins already that take an alternate approach that basically do not allow the last slot to be filled by a player, it remains empty. I have no idea if these work though, just because I dont have more information than that.
This has been around for a while <a href='http://www.modns.org/forums/index.php?showtopic=661' target='_blank'>PSHB Fix</a>
As has been said a few times it was Sarisel who found the bug in this post <a href='http://www.unknownworlds.com/forums/index.php?showtopic=70356&st=0' target='_blank'>here</a>
anyway the top link is a fix for the bug on anything less than a 32man server
Sarisel has been very helpful in tracking this bug, and Elven and I have both mentioned him in our posts. To be fair, though, the first report I got which truly gave us something to work with, hard data on reproducing the bug, came from Head Crab and Alpha.
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->What I am uncertain of, however, is with a server that displays a certain number of slots, are ALL PLAYERS >= that number "bugged", or only the player with the entindex n?<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd--> On the server I referenced earlier that had the "extra slot" for the reserve plugin *waves to curly and hitman*, slot 16 is not bugged. Only slot 17 is, being the last slot on the server.
For example, a 14-player server with this reserved-slot plugin would have a bugged slot15, NOT 14. An 18-player server with this plugin would have a bugged slot19, NOT 18.
This is saying that the bug goes to the true final entindex, not what the server claims is the final slot on the server browser.
Wow wow wow! You all have gone far beyond the call of duty, and deserve a big pat on the back. Seriously, all of you have given the HL community a strong reminder why the NS Community is #1!
I wish to give my most sincere thanks to everyone involved in tracking down this bug!
Very nice find guys, I know this has been researched for a couple months now so hats off to those and their work they put into finding this and bringing it public.
5 gigz? Those pictures are only 600kbs! I'll try to get them on my website... I'll see what I can do.
I tried using my yahoo groups file base, doesn't work sorry <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html//emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif' /><!--endemo-->
douchebagatronCustom member titleJoin Date: 2003-12-20Member: 24581Members, Constellation, Reinforced - Shadow
you could make them smaller and attach images. or attach them in another thread and edit your first post to link them to the images in the other thread.
Try this site: <a href='http://pics.xs.to/' target='_blank'>http://pics.xs.to/</a>. They are free and very easy to use, with a max image size of 750Kb.
[EDIT] On a side note we've hit +10,000 views. Publicity here we come...
<!--QuoteBegin-E-Th33ph+Jul 25 2004, 07:49 PM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (E-Th33ph @ Jul 25 2004, 07:49 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Need quick help. I just raped about 5 gigs of bandwidth on my buddy's webhosting because he was kind enough to host those pics of the bug. If anyone can mirror and take a hit, I'll be forever indebted. <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd--> I uploaded the images to my host. You can access them here: <a href='http://www.holymight.com/ns/' target='_blank'>http://www.holymight.com/ns/</a>
I am not sure if this has been covered but this reminded me of something. Me and my friends would mess around on a server I created (listen server) on regular halflife. I remember that if I charged up that lazer gun and ran in a straight line, jumped did a 180 and fire it would hit me. Could that be the same situation? The server is thinking I am still 1 foot back and I am shooting from 1 foot forward?
The OptusNet NS Admins have a fix called the: [PSHB] Bot
Its a bot that sits in the server permantly to take up the last slot. they incrased all the servers one higher eg 17 for a 16 player and slot 17 is the bot.
A couple fo servers i you want to see him in action:
Sarisel.::' ( O ) ';:-. .-.:;' ( O ) '::.Join Date: 2003-07-30Member: 18557Members, Constellation
It was quite interesting how this bug's tracking evolved. Obviously, in mods where speeds are slower and damage is higher (CS, for example, where the lethality of shots is greater - in addition to randomness of spread), the bug would not be so obvious to spot. However, it was spotted and documented in TFC before. Personally, I've seen it in action in CS, DOD, TFC, S&I, VS, HL:DM, and NS. NS is a very good place to spot it though, due to the accuracy of guns and faster moving players. If you want to prove that this bug exists in HL and all its mods, simply reduce the damage dealt to players and put players on a moving platform of 300+ units of speed.
I guess the only sour part of this story is that it took so long for this bug to be taken seriously by the devs/pts/exterms. Back when I first documented the bug during closed beta testing, most of the feedback that I got were dismissive. I remember a lot of people who were non-believers and who remained that way until I recorded demos of the bug in action. Who ended up actually reviewing the documentation, studying the bug themselves for two weeks, and finding a reliable way to reproduce it? Members of the NS community - Head Crab and Alpha. And meanwhile my documentation went through first stickying in the bug forums, then unstickying, and then got burried here in the general forums. Luckily Alpha read it before it got burried.
I just hope that in the future, if similar strange bugs pop up, the devs and pts actually take it seriously and put in considerable effort to isolate it. Pretty much all that was needed to be done was to fill up a server and to note that one player had a misalligned model. Perhaps it is easy to say this now with hindsight, but the fact still stands: more could have been done to bring this bug to attention earlier instead of just sitting back and giving up/writing it off. In the end, it was due to HL code, not NS code. Regardless, it was still a big problem that was affecting gameplay.
In the end, congratulations to Head Crab for the crucial goal and to Alpha for the assist. Congratulations to the exterminators for then taking it further and finding exactly what happens. It only took 7 months for significant work to get started. Now all that remains to be seen is how long it will take for the work to be completed.
I've been browsing the SDK source code, and as far as I can tell, the functions that set up client-side prediction are based on the event api, which is implemented within the engine. The client.dll calls these functions from function pointers that point to the code within the engine.
Throughout the source code, I looked at various for loops that cycle through the list of players.
For some reason, MAX_PLAYERS is defined as a constant value of 64 in hud.h. Here is an example of code that cycles through the players in vgui_TeamFortressViewport.cpp: <!--c1--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>CODE</b> </td></tr><tr><td id='CODE'><!--ec1--> for ( int i = 1; i < MAX_PLAYERS; i++ ) { GetPlayerInfo( i, &g_PlayerInfoList[i] );
if ( g_PlayerInfoList[i].thisplayer ) m_pScoreBoard->m_iPlayerNum = i; // !!!HACK: this should be initialized elsewhere... maybe gotten from the engine }<!--c2--></td></tr></table><div class='postcolor'><!--ec2-->
Compare it to this code in hud_spectator.cpp: <!--c1--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>CODE</b> </td></tr><tr><td id='CODE'><!--ec1--> for (i=0; i < MAX_PLAYERS; i++ ) m_vPlayerPos[i][2] = -1; // mark as invisible <!--c2--></td></tr></table><div class='postcolor'><!--ec2-->
As far as I can tell, the client.dll player loops cycle through up to 64 players. I am somewhat confused about the reason for some for loops starting at 0 and others starting at 1.
I have no idea if this is related to the problem. I suspect the code responsible for the hitbox issue for the nth player on a server with n slots lies within the engine code.
Now, I just looked at the hl.dll (server) code, and I found this: <!--c1--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>CODE</b> </td></tr><tr><td id='CODE'><!--ec1--> int CountPlayers( void ) { int num = 0;
for ( int i = 1; i <= gpGlobals->maxClients; i++ ) { CBaseEntity *pEnt = UTIL_PlayerByIndex( i );
This leads me to believe your theory that a simple error of "<=" replaced by "<" could be behind this error. However, I can't find any instances within either hl.dll or client.dll that refer to gpGlobals->maxClients (in hl.dll) or gEngfuncs->GetMaxClients() (in client.dll) that have used "<" mistakenly instead of "<=", so it probably lies within the engine code.
<!--QuoteBegin-Sarisel+Jul 25 2004, 09:58 PM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Sarisel @ Jul 25 2004, 09:58 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> It was quite interesting how this bug's tracking evolved. Obviously, in mods where speeds are slower and damage is higher (CS, for example, where the lethality of shots is greater - in addition to randomness of spread), the bug would not be so obvious to spot. However, it was spotted and documented in TFC before. Personally, I've seen it in action in CS, DOD, TFC, S&I, VS, HL:DM, and NS. NS is a very good place to spot it though, due to the accuracy of guns and faster moving players. If you want to prove that this bug exists in HL and all its mods, simply reduce the damage dealt to players and put players on a moving platform of 300+ units of speed.
I guess the only sour part of this story is that it took so long for this bug to be taken seriously by the devs/pts/exterms. Back when I first documented the bug during closed beta testing, most of the feedback that I got were dismissive. I remember a lot of people who were non-believers and who remained that way until I recorded demos of the bug in action. Who ended up actually reviewing the documentation, studying the bug themselves for two weeks, and finding a reliable way to reproduce it? Members of the NS community - Head Crab and Alpha. And meanwhile my documentation went through first stickying in the bug forums, then unstickying, and then got burried here in the general forums. Luckily Alpha read it before it got burried.
I just hope that in the future, if similar strange bugs pop up, the devs and pts actually take it seriously and put in considerable effort to isolate it. Pretty much all that was needed to be done was to fill up a server and to note that one player had a misalligned model. Perhaps it is easy to say this now with hindsight, but the fact still stands: more could have been done to bring this bug to attention earlier instead of just sitting back and giving up/writing it off. In the end, it was due to HL code, not NS code. Regardless, it was still a big problem that was affecting gameplay.
In the end, congratulations to Head Crab for the crucial goal and to Alpha for the assist. Congratulations to the exterminators for then taking it further and finding exactly what happens. It only took 7 months for significant work to get started. Now all that remains to be seen is how long it will take for the work to be completed.
Cheers. <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd--> Actually it goes further back than that, I originally documented this bug and had an .avi made of it back in the vet forums, where I documented BulletinTehHead running on the wall as a skulk. The .avi was made by matchbox. I forwarded the .avi to Max, who said he'd look into it.
I thought my job was done, but far from it as we can see. :o
And yes, I remember everyone saying "OMG your aim just sux", which we realize how ignorant that statement is.
<!--QuoteBegin-Gorfob+Jul 25 2004, 10:51 PM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Gorfob @ Jul 25 2004, 10:51 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> The OptusNet NS Admins have a fix called the: [PSHB] Bot
Its a bot that sits in the server permantly to take up the last slot. they incrased all the servers one higher eg 17 for a 16 player and slot 17 is the bot.
A couple fo servers i you want to see him in action:
Theese are Australian Servers. <!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd--> That would be mahnsawce's third fix that was removed shortly after it was released. It was removed from download because there were issues after map changes.
After disconnecting, connecting and some map changes, the bot will no longer hold the bugged slot, because bots never stay connected on map changes: they get disconnected and connected again. So a player will end up having the bugged slot, if you are a regular on their server, I'd recommend noticing them about this issue.
I've found a method that would add a bot and avoid this issue, but since adding bots to a server creates some very weird issues with AMX/AMXX as found by mahnsawce, we think it would be better not to release a plugin using that method, since the majority of servers use AMX/AMXX and the issues are probably occuring with Admin Mod as well.
I'll post the links to the temporary fixes available again to make sure it can be seen since there are so many pages in this thread.
Comments
So I guess the real question now is, when is VALVe going to fix this <!--emo&:0--><img src='http://www.unknownworlds.com/forums/html//emoticons/wow.gif' border='0' style='vertical-align:middle' alt='wow.gif' /><!--endemo-->
Added:
Bleh, I'm such a tard.. didn't even give thanks where it is due. Awesome job, really appreciate all the work put into finding out all this info <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo-->
actually this "bug" you've found is a common glitch in cs. A while back there was an article on gotfrag which fixed this. Explained some of the serverside commands/client commands that could make hitboxes more accurate threw rates, cl_cmdrate, cl_updaterate, ex_interp ect ect..
R a v e N`
<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
While a link would be lovely, I don't accept that changing your rates and network settings will make a difference when ONLY 1 player's model is rendered wrong. Screwing with those settings (and especially if you have no idea what works with your internet connection) will affect how you see everyone.
As for the comment by nsaRaveN re: 'common glitch in cs', I believe that is a completely different issue, having nothing to do with what this topic involves.
edit- cripes... what a daft way to spend the milestone of 200 posts...
Edit: Kalias said it better, and faster.
When you start an <i><b>n</i></b>-player server, entity IDs 1-<i><b>n</i></b> are reserved to represent connected players. It is for this reason that you cannot change the max players after the server has been started.
When you type status in your console, you see a list of the players' names, along with other info such as their SteamID, time connected, ping, loss, etc. The first bit of information shown, before the player's name, is the player's entity index (The reserved entity number which is referring to that player.) See attached screenshot.
Regardless of how many slots a server claims to have, there is a "true" number of slots which will never be exceeded because ONLY <i><b>n</i></b> entities are reserved for players. It is impossible to have <i><b>n</i></b>+1 players connected.
What I am uncertain of, however, is with a server that displays a certain number of slots, are ALL PLAYERS >= that number "bugged", or only the player with the entindex <i><b>n</i></b>?
The community would be useful in helping us discover this bit of information. Normally, the way I reproduce the PSHB is to create a 2-player HLDS and have two players connect that are NOT on a local area network with the server. Have the bugged player (verify with status) become a Fade with Celerity, Carapace, and 3 hives. (This makes him move faster, and gives him sufficient health to take many hits without stopping to be healed.) Have the fade strafe back and forth in front of a long wall while the other player, as a marine, aims an HMG directly at the fade's model and fires at it as he moves. The fade should take very little or no damage! For control purposes, repeat the process with the non-bugged player as the fade. He should take normal damage.
Let us know what you find out! Is it only player #<i><b>n</i></b> that is bugged, or are all players between <i><b>x</i></b> (max visible slots) and <i><b>n</i></b> bugged?
Thanks in advance.
*edit: The current prevailing speculation among we exterminators is that the lag compensation code parses players in the entindex with a for loop which terminates one player too soon, as posted earlier in the thread, with a < maxplayers instead of the necessary <= maxplayers. As a result, only the last player is failed in the loop. This may be clientside code, and if it is, servers which tell the player that they have <i><b>x</i></b> slots might cause players between <i><b>x</i></b> and <i><b>n</i></b> to be bugged as well. I await your test info, people. <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo-->*
Well. Lets say you want to have a 16 player public server. You'd need a server with 17 slots, have one be hidden to the server browser and have a bot installed on the server that would wait until the 16th player connected and then the bot would "connect" and never disconnect. But, it would have to be able to do the same thing on every map change.
I believe there are some plugins already that take an alternate approach that basically do not allow the last slot to be filled by a player, it remains empty. I have no idea if these work though, just because I dont have more information than that.
As has been said a few times it was Sarisel who found the bug in this post <a href='http://www.unknownworlds.com/forums/index.php?showtopic=70356&st=0' target='_blank'>here</a>
anyway the top link is a fix for the bug on anything less than a 32man server
On the server I referenced earlier that had the "extra slot" for the reserve plugin *waves to curly and hitman*, slot 16 is not bugged. Only slot 17 is, being the last slot on the server.
For example, a 14-player server with this reserved-slot plugin would have a bugged slot15, NOT 14.
An 18-player server with this plugin would have a bugged slot19, NOT 18.
This is saying that the bug goes to the true final entindex, not what the server claims is the final slot on the server browser.
I hope that made sense, it was hard wording it.
Wow wow wow! You all have gone far beyond the call of duty, and deserve a big pat on the back. Seriously, all of you have given the HL community a strong reminder why the NS Community is #1!
I wish to give my most sincere thanks to everyone involved in tracking down this bug!
I tried using my yahoo groups file base, doesn't work sorry <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html//emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif' /><!--endemo-->
[EDIT] On a side note we've hit +10,000 views. Publicity here we come...
<a href='http://www.teamzex.com/rector/roflecl.avi' target='_blank'>http://www.teamzex.com/rector/roflecl.avi</a>
perfect example only its not the ns video weve all seen :X
I uploaded the images to my host. You can access them here: <a href='http://www.holymight.com/ns/' target='_blank'>http://www.holymight.com/ns/</a>
You have 6 days to pull 40GB.
Its a bot that sits in the server permantly to take up the last slot. they incrased all the servers one higher eg 17 for a 16 player and slot 17 is the bot.
A couple fo servers i you want to see him in action:
OptusNet NS #2 v3Beta4a NS_ Maps 198.142.76.148:24230
OptusNet NS #3 v3Beta4a CO_ Maps 198.142.76.151:24260
Theese are Australian Servers.
I guess the only sour part of this story is that it took so long for this bug to be taken seriously by the devs/pts/exterms. Back when I first documented the bug during closed beta testing, most of the feedback that I got were dismissive. I remember a lot of people who were non-believers and who remained that way until I recorded demos of the bug in action. Who ended up actually reviewing the documentation, studying the bug themselves for two weeks, and finding a reliable way to reproduce it? Members of the NS community - Head Crab and Alpha. And meanwhile my documentation went through first stickying in the bug forums, then unstickying, and then got burried here in the general forums. Luckily Alpha read it before it got burried.
I just hope that in the future, if similar strange bugs pop up, the devs and pts actually take it seriously and put in considerable effort to isolate it. Pretty much all that was needed to be done was to fill up a server and to note that one player had a misalligned model. Perhaps it is easy to say this now with hindsight, but the fact still stands: more could have been done to bring this bug to attention earlier instead of just sitting back and giving up/writing it off. In the end, it was due to HL code, not NS code. Regardless, it was still a big problem that was affecting gameplay.
In the end, congratulations to Head Crab for the crucial goal and to Alpha for the assist. Congratulations to the exterminators for then taking it further and finding exactly what happens. It only took 7 months for significant work to get started. Now all that remains to be seen is how long it will take for the work to be completed.
Cheers.
I'd been wondering about this forever... and now my fear is confirmed... the last slot = pwnage city... damn...
Now, valve, what ya gotta do is get yo thumbs outa ya butts and fix this for us. XD
Great Job team... I love the smell of pwned bugs in the morning!
Throughout the source code, I looked at various for loops that cycle through the list of players.
For some reason, MAX_PLAYERS is defined as a constant value of 64 in hud.h.
Here is an example of code that cycles through the players in vgui_TeamFortressViewport.cpp:
<!--c1--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>CODE</b> </td></tr><tr><td id='CODE'><!--ec1-->
for ( int i = 1; i < MAX_PLAYERS; i++ )
{
GetPlayerInfo( i, &g_PlayerInfoList[i] );
if ( g_PlayerInfoList[i].thisplayer )
m_pScoreBoard->m_iPlayerNum = i; // !!!HACK: this should be initialized elsewhere... maybe gotten from the engine
}<!--c2--></td></tr></table><div class='postcolor'><!--ec2-->
Compare it to this code in hud_spectator.cpp:
<!--c1--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>CODE</b> </td></tr><tr><td id='CODE'><!--ec1-->
for (i=0; i < MAX_PLAYERS; i++ )
m_vPlayerPos[i][2] = -1; // mark as invisible
<!--c2--></td></tr></table><div class='postcolor'><!--ec2-->
As far as I can tell, the client.dll player loops cycle through up to 64 players. I am somewhat confused about the reason for some for loops starting at 0 and others starting at 1.
I have no idea if this is related to the problem. I suspect the code responsible for the hitbox issue for the nth player on a server with n slots lies within the engine code.
Now, I just looked at the hl.dll (server) code, and I found this:
<!--c1--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>CODE</b> </td></tr><tr><td id='CODE'><!--ec1-->
int CountPlayers( void )
{
int num = 0;
for ( int i = 1; i <= gpGlobals->maxClients; i++ )
{
CBaseEntity *pEnt = UTIL_PlayerByIndex( i );
if ( pEnt )
{
num = num + 1;
}
}
return num;
}
<!--c2--></td></tr></table><div class='postcolor'><!--ec2-->
This leads me to believe your theory that a simple error of "<=" replaced by "<" could be behind this error. However, I can't find any instances within either hl.dll or client.dll that refer to gpGlobals->maxClients (in hl.dll) or gEngfuncs->GetMaxClients() (in client.dll) that have used "<" mistakenly instead of "<=", so it probably lies within the engine code.
I guess the only sour part of this story is that it took so long for this bug to be taken seriously by the devs/pts/exterms. Back when I first documented the bug during closed beta testing, most of the feedback that I got were dismissive. I remember a lot of people who were non-believers and who remained that way until I recorded demos of the bug in action. Who ended up actually reviewing the documentation, studying the bug themselves for two weeks, and finding a reliable way to reproduce it? Members of the NS community - Head Crab and Alpha. And meanwhile my documentation went through first stickying in the bug forums, then unstickying, and then got burried here in the general forums. Luckily Alpha read it before it got burried.
I just hope that in the future, if similar strange bugs pop up, the devs and pts actually take it seriously and put in considerable effort to isolate it. Pretty much all that was needed to be done was to fill up a server and to note that one player had a misalligned model. Perhaps it is easy to say this now with hindsight, but the fact still stands: more could have been done to bring this bug to attention earlier instead of just sitting back and giving up/writing it off. In the end, it was due to HL code, not NS code. Regardless, it was still a big problem that was affecting gameplay.
In the end, congratulations to Head Crab for the crucial goal and to Alpha for the assist. Congratulations to the exterminators for then taking it further and finding exactly what happens. It only took 7 months for significant work to get started. Now all that remains to be seen is how long it will take for the work to be completed.
Cheers. <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd-->
Actually it goes further back than that, I originally documented this bug and had an .avi made of it back in the vet forums, where I documented BulletinTehHead running on the wall as a skulk. The .avi was made by matchbox. I forwarded the .avi to Max, who said he'd look into it.
I thought my job was done, but far from it as we can see. :o
And yes, I remember everyone saying "OMG your aim just sux", which we realize how ignorant that statement is.
Its a bot that sits in the server permantly to take up the last slot. they incrased all the servers one higher eg 17 for a 16 player and slot 17 is the bot.
A couple fo servers i you want to see him in action:
OptusNet NS #2 v3Beta4a NS_ Maps 198.142.76.148:24230
OptusNet NS #3 v3Beta4a CO_ Maps 198.142.76.151:24260
Theese are Australian Servers. <!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
That would be mahnsawce's third fix that was removed shortly after it was released. It was removed from download because there were issues after map changes.
After disconnecting, connecting and some map changes, the bot will no longer hold the bugged slot, because bots never stay connected on map changes: they get disconnected and connected again. So a player will end up having the bugged slot, if you are a regular on their server, I'd recommend noticing them about this issue.
I've found a method that would add a bot and avoid this issue, but since adding bots to a server creates some very weird issues with AMX/AMXX as found by mahnsawce, we think it would be better not to release a plugin using that method, since the majority of servers use AMX/AMXX and the issues are probably occuring with Admin Mod as well.
I'll post the links to the temporary fixes available again to make sure it can be seen since there are so many pages in this thread.
AMX fixes:
<a href='http://www.modns.org/forums/index.php?showtopic=660' target='_blank'>http://www.modns.org/forums/index.php?showtopic=660</a>
MetaMod fixes:
<a href='http://www.modns.org/forums/index.php?showtopic=661' target='_blank'>http://www.modns.org/forums/index.php?showtopic=661</a>
Again, the bot method that was available for a short amount of time <b>does not work properly</b>.
?
all you need to do is check who is bugged in console then aim ahead of them