Sarisel.::' ( O ) ';:-. .-.:;' ( O ) '::.Join Date: 2003-07-30Member: 18557Members, Constellation
edited July 2004
The first post does contain the current info, but not the way to reproduce it. It isn't random at all, just that it is mostly based on your luck when you join the server. I'll see what I can do to clarify in the first post.
BTW, this bug does occur in Vampire Slayer as well - which has not been updated since the WON days. It doesn't occur in any other mods that I know of, like DOD, CS, and TFC.
PSHB - PLAYER SPECIFIC HITBOX BUG – Theory By Vladimir “VK” Kazakov; Credit to Alpha and HeadCrab of [C.A.P.]
SlotIDs
1. In a server with a capacity of (x) slots, there are (x) unique slotIDs numbered from #1 to #(x) that can be assigned to connecting clients' steamIDs. (You can see these if you type 'status' in console, on the very left of a player's name.)
2. These "reserved" slotIDs remain assigned to the clients' steamIDs throughout the duration of their connection to the server and even after disconnection. This includes changes in maps and the passing of rounds. Their steamIDs are in the server's memory. The client could reconnect to the server and still have the same slotID.
3. SlotIDs that are assigned to steamIDs are "reserved", slotIDs that have not been assigned to steamIDs are "free". Clients who have "reserved" slotIDs are "old" players, clients who do not have a slotID assigned to them are "new" players. a) In an freshly restarted empty server, slotIDs will be assigned on a first come first serve basis, from #1 to #(x), since they are all "free" and all of the clients are "new" players. b) The first come first serve policy continues until a client disconnects, in which case the following client will get the disconnected client's "reserved" slotID. Ex. Client with slotID #4 leaves, next player to connect gets slotID #4. c) If more than one player leaves, the "reserved" slots are filled in first even in order of the recency in disconnection, even if there are "free" slots available. Ex. slotID #4, #5, #9 leave in sequence - the next three players to connect get slotIDs #9, #5, and #4.
4. The slotID is guaranteed to be released if: a) The server is reset - all slots are reset to "free" status. b) A "new" client takes away a slotID by joining and acquiring the slotID of the client that disconnected most recently. In this case, the vacant "reserved" slotID (which has the greatest recency) gets taken away from the "old" player to whom it was assigned. c) Possibly, slotIDs may get refreshed after a certain period of time without the server restarting - perhaps after about 3-4 hours. This is not certain but it is possible.
How PSHB works:
1. If a client connects to a server and gets the last slotID assigned to his steamID, he acquires PSHB. Illustration: <a href='http://www.picgoo.com/uploads7/bug.jpg' target='_blank'>http://www.picgoo.com/uploads7/bug.jpg</a>
2. This can happen easiest if the client takes the last "free" slotID available on a freshly restarted server by filling up the last available client slot (ex. slotID #16 on a server with 16 available slots). Once the PSHB slotID is assigned to a client's steamID, that client will have PSHB throughout games, map changes, and even through reconnections. As long as the client returns before his slotID is re-assigned to the next newly connecting client, he will still have PSHB. Otherwise PSHB belongs to the new client that takes his slotID.
3. If the server was full at one point, the last slotID has already been "reserved" for the steamID of the client that was connected before and has since left. If another client comes in, he may take away the reservation of the PSHB slot if it is the "youngest" reserved slotID. If, however, several other players left after the PSHB client left, then his slot will take longer to be picked up by a new client. Ex. A server with 22 slot capacity empties out from slotID #22 to #1 - then the 22nd "new" client will get slotID #22 and PSHB.
4. Assuming no "old" player rejoin during the process, if there are (y) number of slotIDs that are "younger" than slotID #(x), which is the PSHB slot, then the (y+1)st client to connect to the server will acquire slotID #(x) and PSHB along with it. The "youngest" vacant slotID gets re-assigned first.
What you need to do: As an admin
As an admin, you need to ensure that the last slotID on your server never gets assigned to any active client’s steamID. I am sure that there are several ways to do this.
[C.A.P.]Head Crab made a system so that 2 reserved slots are unavailable to anybody – the bugged slot never gets taken as long as the 2nd last slot always gets kicked. However, if two players were to connect at the same time to those two reserved slots, the last slot would be assigned to a client’s steamID, who could then come back later when the server is not full and have PSHB.
If there is a way to assign the PSHB slotID to a static player who only observes or just sits in the ready room, that could be another way of going around the bug.
The best way would probably be to make a plug-in that makes it so that nobody can ever connect to the last slotID ever. If this is possible, it will solve the problem until the dev team fixes the coding error that caused this.
All you need to do to ensure this bug doesn’t happen in clan matches is to make sure nobody plays with the last slotID. If somebody gets it, have him disconnect and just have a non-playing client join and take that slotID away right after the disconnection. Then the previously bugged client can rejoin and get another slotID while the non-playing client is still in the server. After all playing clients have slotIDs (but nobody has the last one), the game can start.
What you need to do: As a player
PSHB gives an extremely unfair edge to whoever has it. Don’t play if you find that you have the PSHB slotID. In competitive games, make sure before you begin that nobody has the PSHB slotID by checking through the console. In pub games, there isn’t that much you can do unless the administrators of the server are informed about this effect.
CAL admins are aware of this bug and how it can be exploited. They will be taking steps to prevent it from occurring in upcoming matches and until the problem is fixed permanently by Flayra and co. (if ever).
Exploitation: How it is possible (and, therefore, how to tell that it is happening)
Exploiting PSHB individually in a random unprotected public server is very difficult, since the only way you can be sure that you will get the bugged slotID is to join when there’s one slot left on a freshly restarted server. Otherwise, it depends on how many clients are on the server, how many have left, and in what order they did so when you join.
With collaboration, it is possible to fill up other slotIDs to give a player the PSHB slotID. Also, it is possible to pass on the PSHB slotID if one player leaves and another joins right away to take that slotID for himself.
In smaller organized games, it is possible to intentionally set up the PSHB slotID before a match starts by following the steps described earlier. This is why it is of utmost importance that both teams make sure that the PSHB slotID is not assigned to any player before the match starts.
Finally, there may be ways to code server plug-ins to reproduce the bugged code that occurs on the last slotID for other slotIDs. However, this would mean a conspiracy between server administrators and players under them. Watch out for this possibility - make sure that there are no plugins on the server that you play on that allow this to happen.
PSHB - PLAYER SPECIFIC HITBOX BUG – Theory By Vladimir “VK” Kazakov; Credit to Alpha and HeadCrab of [C.A.P.]
SlotIDs
1. In a server with a capacity of (x) slots, there are (x) unique slotIDs numbered from #1 to #(x) that can be assigned to connecting clients' steamIDs. (You can see these if you type 'status' in console, on the very left of a player's name.)
2. These "reserved" slotIDs remain assigned to the clients' steamIDs throughout the duration of their connection to the server and even after disconnection. This includes changes in maps and the passing of rounds. Their steamIDs are in the server's memory. The client could reconnect to the server and still have the same slotID.
3. SlotIDs that are assigned to steamIDs are "reserved", slotIDs that have not been assigned to steamIDs are "free". Clients who have "reserved" slotIDs are "old" players, clients who do not have a slotID assigned to them are "new" players. a) In an freshly restarted empty server, slotIDs will be assigned on a first come first serve basis, from #1 to #(x), since they are all "free" and all of the clients are "new" players. b) The first come first serve policy continues until a client disconnects, in which case the following client will get the disconnected client's "reserved" slotID. Ex. Client with slotID #4 leaves, next player to connect gets slotID #4. c) If more than one player leaves, the "reserved" slots are filled in first even in order of the recency in disconnection, even if there are "free" slots available. Ex. slotID #4, #5, #9 leave in sequence - the next three players to connect get slotIDs #9, #5, and #4.
4. The slotID is guaranteed to be released if: a) The server is reset - all slots are reset to "free" status. b) A "new" client takes away a slotID by joining and acquiring the slotID of the client that disconnected most recently. In this case, the vacant "reserved" slotID (which has the greatest recency) gets taken away from the "old" player to whom it was assigned. c) Possibly, slotIDs may get refreshed after a certain period of time without the server restarting - perhaps after about 3-4 hours. This is not certain but it is possible.
How PSHB works:
1. If a client connects to a server and gets the last slotID assigned to his steamID, he acquires PSHB. Illustration: <a href='http://www.picgoo.com/uploads7/bug.jpg' target='_blank'>http://www.picgoo.com/uploads7/bug.jpg</a>
2. This can happen easiest if the client takes the last "free" slotID available on a freshly restarted server by filling up the last available client slot (ex. slotID #16 on a server with 16 available slots). Once the PSHB slotID is assigned to a client's steamID, that client will have PSHB throughout games, map changes, and even through reconnections. As long as the client returns before his slotID is re-assigned to the next newly connecting client, he will still have PSHB. Otherwise PSHB belongs to the new client that takes his slotID.
3. If the server was full at one point, the last slotID has already been "reserved" for the steamID of the client that was connected before and has since left. If another client comes in, he may take away the reservation of the PSHB slot if it is the "youngest" reserved slotID. If, however, several other players left after the PSHB client left, then his slot will take longer to be picked up by a new client. Ex. A server with 22 slot capacity empties out from slotID #22 to #1 - then the 22nd "new" client will get slotID #22 and PSHB.
4. Assuming no "old" player rejoin during the process, if there are (y) number of slotIDs that are "younger" than slotID #(x), which is the PSHB slot, then the (y+1)st client to connect to the server will acquire slotID #(x) and PSHB along with it. The "youngest" vacant slotID gets re-assigned first.
What you need to do: As an admin
As an admin, you need to ensure that the last slotID on your server never gets assigned to any active client’s steamID. I am sure that there are several ways to do this.
[C.A.P.]Head Crab made a system so that 2 reserved slots are unavailable to anybody – the bugged slot never gets taken as long as the 2nd last slot always gets kicked. However, if two players were to connect at the same time to those two reserved slots, the last slot would be assigned to a client’s steamID, who could then come back later when the server is not full and have PSHB.
If there is a way to assign the PSHB slotID to a static player who only observes or just sits in the ready room, that could be another way of going around the bug.
The best way would probably be to make a plug-in that makes it so that nobody can ever connect to the last slotID ever. If this is possible, it will solve the problem until the dev team fixes the coding error that caused this.
All you need to do to ensure this bug doesn’t happen in clan matches is to make sure nobody plays with the last slotID. If somebody gets it, have him disconnect and just have a non-playing client join and take that slotID away right after the disconnection. Then the previously bugged client can rejoin and get another slotID while the non-playing client is still in the server. After all playing clients have slotIDs (but nobody has the last one), the game can start.
What you need to do: As a player
PSHB gives an extremely unfair edge to whoever has it. Don’t play if you find that you have the PSHB slotID. In competitive games, make sure before you begin that nobody has the PSHB slotID by checking through the console. In pub games, there isn’t that much you can do unless the administrators of the server are informed about this effect.
CAL admins are aware of this bug and how it can be exploited. They will be taking steps to prevent it from occurring in upcoming matches and until the problem is fixed permanently by Flayra and co. (if ever).
Exploitation: How it is possible (and, therefore, how to tell that it is happening)
Exploiting PSHB individually in a random unprotected public server is very difficult, since the only way you can be sure that you will get the bugged slotID is to join when there’s one slot left on a freshly restarted server. Otherwise, it depends on how many clients are on the server, how many have left, and in what order they did so when you join.
With collaboration, it is possible to fill up other slotIDs to give a player the PSHB slotID. Also, it is possible to pass on the PSHB slotID if one player leaves and another joins right away to take that slotID for himself.
In smaller organized games, it is possible to intentionally set up the PSHB slotID before a match starts by following the steps described earlier. This is why it is of utmost importance that both teams make sure that the PSHB slotID is not assigned to any player before the match starts.
Finally, there may be ways to code server plug-ins to reproduce the bugged code that occurs on the last slotID for other slotIDs. However, this would mean a conspiracy between server administrators and players under them. Watch out for this possibility - make sure that there are no plugins on the server that you play on that allow this to happen.
Sarisel.::' ( O ) ';:-. .-.:;' ( O ) '::.Join Date: 2003-07-30Member: 18557Members, Constellation
While I do not know who the person is that posted my document above, that was what I sent to CAL-NS league admins and clan team leaders to make sure that the bug would not affect any more matches and scrims. You took it on your self to post it here without permission.
Should probably be removed as it in essence shows players exactly how to exploit the bug, twice. Now that I know Sarisel, have you guys found out anything about why the the bug only occurs on the last slot?
Oh and in the first post you should basicly post something that looks like that essay, except removing all the exploitable information, expalaining that it is exploitable information. EI instead of lying to people saying "the bug is procuced at random" say "we have located a way to reproduce the bug, but can't release information on it as it is exploitable."
So, that's it ? All the secretive talking about sth. that I consider a lesser problem (exploit-wise) than i.e. the leap exploit or invis-models (erm, should I have asked for permission to mention those ?). Somewhat dissapointing, IMO <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html//emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif' /><!--endemo-->
Now that we know how to spot the PSHB player (which, according to the bug description, must exist on <i>every</i> full server - strange how the bug isn't noticed more often), I'm wondering if this is the same bug that's already been fixed (but pbly. not yet released ?) by Valve (see Soylent's quote from the Steam forums on page 3 of this thread).
Cause I was scrimming the other day and me and my teamate got ambushed from behind in a dead end hallway. Then seamingly (after I died) the skulk appeared out of nowhere and killed my teamate.
heh....wereon is a smurf name. Somebody just started the account solely to post the info. The fact that he had to use a smurf name to do it means that he knows he was not supposed to. GG moron.
Sarisel.::' ( O ) ';:-. .-.:;' ( O ) '::.Join Date: 2003-07-30Member: 18557Members, Constellation
<!--QuoteBegin-Swiftspear+Jul 3 2004, 04:20 PM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Swiftspear @ Jul 3 2004, 04:20 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Should probably be removed as it in essence shows players exactly how to exploit the bug, twice. Now that I know Sarisel, have you guys found out anything about why the the bug only occurs on the last slot?
Oh and in the first post you should basicly post something that looks like that essay, except removing all the exploitable information, expalaining that it is exploitable information. EI instead of lying to people saying "the bug is procuced at random" say "we have located a way to reproduce the bug, but can't release information on it as it is exploitable." <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd--> Ok, where do I say that it is produced random? Does the bold text at the top of the first post not indicate that it is <b>isolated and reproduceable</b>? Do I really have to raise the size of the text, and color it in red as well? Just read the post, for crying out loud.
The information about the bug doesn't show people how to exploit it. You can give people a full technical report as to how it happens exactly, and they'd still not be able to use it because a) they can't understand it and, most importantly, b) it is not easy to exploit even if you have the given information.
I'm sure if the mods deem the information to require deletion, it will dissapear. I don't really mind.
<!--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-->The bug occurs when a certain player connects to the server. The player joins a team and enters the map. The chances of being affected by this bug are about 1 in 15 or 1 in 20, meaning that the probability of encountering this bug in a server is very high if not inevitable. It isn't that rare, but is often overlooked because the players who are affected by this bug do not have the playing skill to exploit it to its maximum potential.<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd--> Sorry, I just took this the wrong way I guess. One way or another you might want to mention the fact that you are withholding information to prevent exploitation, I only really picked that up after reading several other posts in this thread.
Although you've seem to have isolated a reproducable bugged player, are you sure that's the only way for someone to get bugged? I've been looking at the whole status thing and usually well yup they're the last person, however sometimes they are not and I pretty dam sure they are bugged. A typing skulk can't take a full lmg clip and not die. Those are the obviously cases. Or any time you just unload everything on a skulk and before and after you die, you look around and realized, you didn't miss a single bullet cause they are no bullet holes on the wall. I mean these people are surely bugged. I mean even sometimes I've been bugged. I can feel the bullets him me, see my blood on the wall and realized I havn't been damaged. Or most fun of all sit on the armory and see how long it takes 10 rines to kill me. These times I suspect myself I'm bugged but I'm not the last server ID. I mean you definatly found part of the problem but are you sure you found the whole?
Sarisel.::' ( O ) ';:-. .-.:;' ( O ) '::.Join Date: 2003-07-30Member: 18557Members, Constellation
I'd really like to say that this is the only way somebody can get bugged. Experience, however, suggests otherwise. There may be other variations of it. I do know for sure that this represents the majority of bugged cases. It fits the description that I made way back in closed beta testing like a glove fits a hand.
Sarisel.::' ( O ) ';:-. .-.:;' ( O ) '::.Join Date: 2003-07-30Member: 18557Members, Constellation
<!--QuoteBegin-ViPr+Jul 4 2004, 04:08 AM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (ViPr @ Jul 4 2004, 04:08 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> right so are you gonna tell Valve you found this bug instead of just telling one server admin? <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd--> "Valve" never listens.
This is not a Steam/Valve related bug. If it happens in some other mods, it's because the coder of these mods did the same common coding error as this one.
The way this error is caused is also a common in many plugins.
On another note, server admins may see the first post for the AMX fixes that they can install on their server.
A Metamod fix is also on its way, being coded by the great [mahn]sawce.
<span style='color:red'><b>All the informations about this bug are in the first post, check it out before asking repetitive questions.</b></span>
You, as a regular of a certain server, can make a difference by talking to an admin of that server and informing him about the available fixes for this bug.
great so how are we supposed to know a server is fixed? <!--emo&:angry:--><img src='http://www.unknownworlds.com/forums/html//emoticons/mad.gif' border='0' style='vertical-align:middle' alt='mad.gif' /><!--endemo-->
can't you just tell Flayra so we can be done with this nonsense please.
telling an admin to fix this is just not going to work. on this major popular server i play on, everytime there is an admin on there, they change the level after each round because that's what they like and everyone else too because nobody likes sleeping in the same position the whole night and i keep asking them to change the map change time limit because when there is no admin then we have to play the same map several times which is really annoying and i've been telling them for ages and they always change the level manually themselves but they don't bloody change the friggen goddamn map change timer coz server admins are retarded or something ok?! so if they don't even know how to change the goddamn map change time limit how are you gonna expect them to fix this?
and btw people complained about this bug in CS and that is Valve's responsibility so Valve better bloody well listen!
<!--QuoteBegin-Lt. Hendrickson+Jul 3 2004, 10:33 PM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Lt. Hendrickson @ Jul 3 2004, 10:33 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->do those leap and invisa exploits still exist?
Cause I was scrimming the other day and me and my teamate got ambushed from behind in a dead end hallway. Then seamingly (after I died) the skulk appeared out of nowhere and killed my teamate.<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd--> The leap exploit still exists. A typical giveaway of this exploit is that you can see a skulk leaping repeatedly without making any leaping noises (while he has <i>not</i> upgraded silence, i.e. you still hear it's footstep and biting. However, an occasional lack of a leap sound may also have other reasons, like packet loss or overflow of sound channels!).
As to my technical understanding, this due to the player movement being fully client-side only - which seems to be a necessity for the netcode to allow smooth player movement, but also may be the reason for other problems, like the PSHB.
And invis models can be prevented with mp_consistency enabled on the server, <i>if</i> the server has it enabled.
<!--QuoteBegin-Head crab+Jul 4 2004, 04:19 AM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Head crab @ Jul 4 2004, 04:19 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> This is not a Steam/Valve related bug. If it happens in some other mods, it's because the coder of these mods did the same common coding error as this one.
The way this error is caused is also a common in many plugins.<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd--> Head crab, do you have any further details or references about this ?
<!--QuoteBegin-ViPr+Jul 4 2004, 08:23 AM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (ViPr @ Jul 4 2004, 08:23 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> great so how are we supposed to know a server is fixed? <!--emo&:angry:--><img src='http://www.unknownworlds.com/forums/html//emoticons/mad.gif' border='0' style='vertical-align:middle' alt='mad.gif' /><!--endemo-->
can't you just tell Flayra so we can be done with this nonsense please.
telling an admin to fix this is just not going to work. on this major popular server i play on, everytime there is an admin on there, they change the level after each round because that's what they like and everyone else too because nobody likes sleeping in the same position the whole night and i keep asking them to change the map change time limit because when there is no admin then we have to play the same map several times which is really annoying and i've been telling them for ages and they always change the level manually themselves but they don't bloody change the friggen goddamn map change timer coz server admins are retarded or something ok?! so if they don't even know how to change the goddamn map change time limit how are you gonna expect them to fix this?
and btw people complained about this bug in CS and that is Valve's responsibility so Valve better bloody well listen! <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd--> Read the important posts and you will see that the dev team knows about this bug since the first day we have found it.
There is a Metamod version of the fixes, as stated in my post above, check it out at <a href='http://www.modns.org/' target='_blank'>modns.org</a>
this is disgraceful. this thread has gone off the front page and basically nothing has been done. i followed the link and read the thread in the other forums of the fix. the server admins don't understand what the hell is going on and how the fix fixes this bug. the reason they don't understand how it fixes the bug is because it doesn't fix the bug. it just introduces another bug that causes this bug to be avoided. and again how are we supposed to know that a server has this fix and even if it is working. this is not a solution. Flayra or Valve needs to do something.
Where is it stated that this is an absolute perfect solution for this problem? This merely is a bandaid fix until it can be fixed in NS or in Half-Life itself, whichever happens to be at fault.
<!--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--> the reason they don't understand how it fixes the bug is because it doesn't fix the bug. it just introduces another bug that causes this bug to be avoided. <!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd--> And how does this create yet another bug?
I'm pretty sure that while the last slot player is always bugged, there is another slot that is bugged too. I was playing as a fade today in a pug and I was being shot at directly (as in the tracers were going into me) and taking little or no damage. Server slot ID was #4.
I have seen you moom, and I have the feeling that the tracers do not have to do anything with teh actual hitscan attack of the lmg. Can anyone confirm that?
Comments
BTW, this bug does occur in Vampire Slayer as well - which has not been updated since the WON days. It doesn't occur in any other mods that I know of, like DOD, CS, and TFC.
By Vladimir “VK” Kazakov; Credit to Alpha and HeadCrab of [C.A.P.]
SlotIDs
1. In a server with a capacity of (x) slots, there are (x) unique slotIDs numbered from #1 to #(x) that can be assigned to connecting clients' steamIDs. (You can see these if you type 'status' in console, on the very left of a player's name.)
2. These "reserved" slotIDs remain assigned to the clients' steamIDs throughout the duration of their connection to the server and even after disconnection. This includes changes in maps and the passing of rounds. Their steamIDs are in the server's memory. The client could reconnect to the server and still have the same slotID.
3. SlotIDs that are assigned to steamIDs are "reserved", slotIDs that have not been assigned to steamIDs are "free". Clients who have "reserved" slotIDs are "old" players, clients who do not have a slotID assigned to them are "new" players.
a) In an freshly restarted empty server, slotIDs will be assigned on a first come first serve basis, from #1 to #(x), since they are all "free" and all of the clients are "new" players.
b) The first come first serve policy continues until a client disconnects, in which case the following client will get the disconnected client's "reserved" slotID. Ex. Client with slotID #4 leaves, next player to connect gets slotID #4.
c) If more than one player leaves, the "reserved" slots are filled in first even in order of the recency in disconnection, even if there are "free" slots available. Ex. slotID #4, #5, #9 leave in sequence - the next three players to connect get slotIDs #9, #5, and #4.
4. The slotID is guaranteed to be released if:
a) The server is reset - all slots are reset to "free" status.
b) A "new" client takes away a slotID by joining and acquiring the slotID of the client that disconnected most recently. In this case, the vacant "reserved" slotID (which has the greatest recency) gets taken away from the "old" player to whom it was assigned.
c) Possibly, slotIDs may get refreshed after a certain period of time without the server restarting - perhaps after about 3-4 hours. This is not certain but it is possible.
How PSHB works:
1. If a client connects to a server and gets the last slotID assigned to his steamID, he acquires PSHB. Illustration: <a href='http://www.picgoo.com/uploads7/bug.jpg' target='_blank'>http://www.picgoo.com/uploads7/bug.jpg</a>
2. This can happen easiest if the client takes the last "free" slotID available on a freshly restarted server by filling up the last available client slot (ex. slotID #16 on a server with 16 available slots). Once the PSHB slotID is assigned to a client's steamID, that client will have PSHB throughout games, map changes, and even through reconnections. As long as the client returns before his slotID is re-assigned to the next newly connecting client, he will still have PSHB. Otherwise PSHB belongs to the new client that takes his slotID.
3. If the server was full at one point, the last slotID has already been "reserved" for the steamID of the client that was connected before and has since left. If another client comes in, he may take away the reservation of the PSHB slot if it is the "youngest" reserved slotID. If, however, several other players left after the PSHB client left, then his slot will take longer to be picked up by a new client. Ex. A server with 22 slot capacity empties out from slotID #22 to #1 - then the 22nd "new" client will get slotID #22 and PSHB.
4. Assuming no "old" player rejoin during the process, if there are (y) number of slotIDs that are "younger" than slotID #(x), which is the PSHB slot, then the (y+1)st client to connect to the server will acquire slotID #(x) and PSHB along with it. The "youngest" vacant slotID gets re-assigned first.
What you need to do: As an admin
As an admin, you need to ensure that the last slotID on your server never gets assigned to any active client’s steamID. I am sure that there are several ways to do this.
[C.A.P.]Head Crab made a system so that 2 reserved slots are unavailable to anybody – the bugged slot never gets taken as long as the 2nd last slot always gets kicked. However, if two players were to connect at the same time to those two reserved slots, the last slot would be assigned to a client’s steamID, who could then come back later when the server is not full and have PSHB.
If there is a way to assign the PSHB slotID to a static player who only observes or just sits in the ready room, that could be another way of going around the bug.
The best way would probably be to make a plug-in that makes it so that nobody can ever connect to the last slotID ever. If this is possible, it will solve the problem until the dev team fixes the coding error that caused this.
All you need to do to ensure this bug doesn’t happen in clan matches is to make sure nobody plays with the last slotID. If somebody gets it, have him disconnect and just have a non-playing client join and take that slotID away right after the disconnection. Then the previously bugged client can rejoin and get another slotID while the non-playing client is still in the server. After all playing clients have slotIDs (but nobody has the last one), the game can start.
What you need to do: As a player
PSHB gives an extremely unfair edge to whoever has it. Don’t play if you find that you have the PSHB slotID. In competitive games, make sure before you begin that nobody has the PSHB slotID by checking through the console. In pub games, there isn’t that much you can do unless the administrators of the server are informed about this effect.
CAL admins are aware of this bug and how it can be exploited. They will be taking steps to prevent it from occurring in upcoming matches and until the problem is fixed permanently by Flayra and co. (if ever).
Exploitation: How it is possible (and, therefore, how to tell that it is happening)
Exploiting PSHB individually in a random unprotected public server is very difficult, since the only way you can be sure that you will get the bugged slotID is to join when there’s one slot left on a freshly restarted server. Otherwise, it depends on how many clients are on the server, how many have left, and in what order they did so when you join.
With collaboration, it is possible to fill up other slotIDs to give a player the PSHB slotID. Also, it is possible to pass on the PSHB slotID if one player leaves and another joins right away to take that slotID for himself.
In smaller organized games, it is possible to intentionally set up the PSHB slotID before a match starts by following the steps described earlier. This is why it is of utmost importance that both teams make sure that the PSHB slotID is not assigned to any player before the match starts.
Finally, there may be ways to code server plug-ins to reproduce the bugged code that occurs on the last slotID for other slotIDs. However, this would mean a conspiracy between server administrators and players under them. Watch out for this possibility - make sure that there are no plugins on the server that you play on that allow this to happen.
By Vladimir “VK” Kazakov; Credit to Alpha and HeadCrab of [C.A.P.]
SlotIDs
1. In a server with a capacity of (x) slots, there are (x) unique slotIDs numbered from #1 to #(x) that can be assigned to connecting clients' steamIDs. (You can see these if you type 'status' in console, on the very left of a player's name.)
2. These "reserved" slotIDs remain assigned to the clients' steamIDs throughout the duration of their connection to the server and even after disconnection. This includes changes in maps and the passing of rounds. Their steamIDs are in the server's memory. The client could reconnect to the server and still have the same slotID.
3. SlotIDs that are assigned to steamIDs are "reserved", slotIDs that have not been assigned to steamIDs are "free". Clients who have "reserved" slotIDs are "old" players, clients who do not have a slotID assigned to them are "new" players.
a) In an freshly restarted empty server, slotIDs will be assigned on a first come first serve basis, from #1 to #(x), since they are all "free" and all of the clients are "new" players.
b) The first come first serve policy continues until a client disconnects, in which case the following client will get the disconnected client's "reserved" slotID. Ex. Client with slotID #4 leaves, next player to connect gets slotID #4.
c) If more than one player leaves, the "reserved" slots are filled in first even in order of the recency in disconnection, even if there are "free" slots available. Ex. slotID #4, #5, #9 leave in sequence - the next three players to connect get slotIDs #9, #5, and #4.
4. The slotID is guaranteed to be released if:
a) The server is reset - all slots are reset to "free" status.
b) A "new" client takes away a slotID by joining and acquiring the slotID of the client that disconnected most recently. In this case, the vacant "reserved" slotID (which has the greatest recency) gets taken away from the "old" player to whom it was assigned.
c) Possibly, slotIDs may get refreshed after a certain period of time without the server restarting - perhaps after about 3-4 hours. This is not certain but it is possible.
How PSHB works:
1. If a client connects to a server and gets the last slotID assigned to his steamID, he acquires PSHB. Illustration: <a href='http://www.picgoo.com/uploads7/bug.jpg' target='_blank'>http://www.picgoo.com/uploads7/bug.jpg</a>
2. This can happen easiest if the client takes the last "free" slotID available on a freshly restarted server by filling up the last available client slot (ex. slotID #16 on a server with 16 available slots). Once the PSHB slotID is assigned to a client's steamID, that client will have PSHB throughout games, map changes, and even through reconnections. As long as the client returns before his slotID is re-assigned to the next newly connecting client, he will still have PSHB. Otherwise PSHB belongs to the new client that takes his slotID.
3. If the server was full at one point, the last slotID has already been "reserved" for the steamID of the client that was connected before and has since left. If another client comes in, he may take away the reservation of the PSHB slot if it is the "youngest" reserved slotID. If, however, several other players left after the PSHB client left, then his slot will take longer to be picked up by a new client. Ex. A server with 22 slot capacity empties out from slotID #22 to #1 - then the 22nd "new" client will get slotID #22 and PSHB.
4. Assuming no "old" player rejoin during the process, if there are (y) number of slotIDs that are "younger" than slotID #(x), which is the PSHB slot, then the (y+1)st client to connect to the server will acquire slotID #(x) and PSHB along with it. The "youngest" vacant slotID gets re-assigned first.
What you need to do: As an admin
As an admin, you need to ensure that the last slotID on your server never gets assigned to any active client’s steamID. I am sure that there are several ways to do this.
[C.A.P.]Head Crab made a system so that 2 reserved slots are unavailable to anybody – the bugged slot never gets taken as long as the 2nd last slot always gets kicked. However, if two players were to connect at the same time to those two reserved slots, the last slot would be assigned to a client’s steamID, who could then come back later when the server is not full and have PSHB.
If there is a way to assign the PSHB slotID to a static player who only observes or just sits in the ready room, that could be another way of going around the bug.
The best way would probably be to make a plug-in that makes it so that nobody can ever connect to the last slotID ever. If this is possible, it will solve the problem until the dev team fixes the coding error that caused this.
All you need to do to ensure this bug doesn’t happen in clan matches is to make sure nobody plays with the last slotID. If somebody gets it, have him disconnect and just have a non-playing client join and take that slotID away right after the disconnection. Then the previously bugged client can rejoin and get another slotID while the non-playing client is still in the server. After all playing clients have slotIDs (but nobody has the last one), the game can start.
What you need to do: As a player
PSHB gives an extremely unfair edge to whoever has it. Don’t play if you find that you have the PSHB slotID. In competitive games, make sure before you begin that nobody has the PSHB slotID by checking through the console. In pub games, there isn’t that much you can do unless the administrators of the server are informed about this effect.
CAL admins are aware of this bug and how it can be exploited. They will be taking steps to prevent it from occurring in upcoming matches and until the problem is fixed permanently by Flayra and co. (if ever).
Exploitation: How it is possible (and, therefore, how to tell that it is happening)
Exploiting PSHB individually in a random unprotected public server is very difficult, since the only way you can be sure that you will get the bugged slotID is to join when there’s one slot left on a freshly restarted server. Otherwise, it depends on how many clients are on the server, how many have left, and in what order they did so when you join.
With collaboration, it is possible to fill up other slotIDs to give a player the PSHB slotID. Also, it is possible to pass on the PSHB slotID if one player leaves and another joins right away to take that slotID for himself.
In smaller organized games, it is possible to intentionally set up the PSHB slotID before a match starts by following the steps described earlier. This is why it is of utmost importance that both teams make sure that the PSHB slotID is not assigned to any player before the match starts.
Finally, there may be ways to code server plug-ins to reproduce the bugged code that occurs on the last slotID for other slotIDs. However, this would mean a conspiracy between server administrators and players under them. Watch out for this possibility - make sure that there are no plugins on the server that you play on that allow this to happen.
Oh and in the first post you should basicly post something that looks like that essay, except removing all the exploitable information, expalaining that it is exploitable information. EI instead of lying to people saying "the bug is procuced at random" say "we have located a way to reproduce the bug, but can't release information on it as it is exploitable."
Now that we know how to spot the PSHB player (which, according to the bug description, must exist on <i>every</i> full server - strange how the bug isn't noticed more often), I'm wondering if this is the same bug that's already been fixed (but pbly. not yet released ?) by Valve (see Soylent's quote from the Steam forums on page 3 of this thread).
Cause I was scrimming the other day and me and my teamate got ambushed from behind in a dead end hallway. Then seamingly (after I died) the skulk appeared out of nowhere and killed my teamate.
Oh and in the first post you should basicly post something that looks like that essay, except removing all the exploitable information, expalaining that it is exploitable information. EI instead of lying to people saying "the bug is procuced at random" say "we have located a way to reproduce the bug, but can't release information on it as it is exploitable." <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd-->
Ok, where do I say that it is produced random? Does the bold text at the top of the first post not indicate that it is <b>isolated and reproduceable</b>? Do I really have to raise the size of the text, and color it in red as well? Just read the post, for crying out loud.
The information about the bug doesn't show people how to exploit it. You can give people a full technical report as to how it happens exactly, and they'd still not be able to use it because a) they can't understand it and, most importantly, b) it is not easy to exploit even if you have the given information.
I'm sure if the mods deem the information to require deletion, it will dissapear. I don't really mind.
Sorry, I just took this the wrong way I guess. One way or another you might want to mention the fact that you are withholding information to prevent exploitation, I only really picked that up after reading several other posts in this thread.
"Valve" never listens.
The way this error is caused is also a common in many plugins.
On another note, server admins may see the first post for the AMX fixes that they can install on their server.
A Metamod fix is also on its way, being coded by the great [mahn]sawce.
You can view the Metamod versions of the fixes that are listed in the first post in this topic at modns.org:
<a href='http://www.modns.org/forums/index.php?showtopic=661' target='_blank'>http://www.modns.org/forums/index.php?showtopic=661</a>
You can also view any further AMX versions of the fixes in this topic at modns.org:
<a href='http://www.modns.org/forums/index.php?showtopic=660' target='_blank'>http://www.modns.org/forums/index.php?showtopic=660</a>
<span style='color:red'><b>All the informations about this bug are in the first post, check it out before asking repetitive questions.</b></span>
You, as a regular of a certain server, can make a difference by talking to an admin of that server and informing him about the available fixes for this bug.
can't you just tell Flayra so we can be done with this nonsense please.
telling an admin to fix this is just not going to work. on this major popular server i play on, everytime there is an admin on there, they change the level after each round because that's what they like and everyone else too because nobody likes sleeping in the same position the whole night and i keep asking them to change the map change time limit because when there is no admin then we have to play the same map several times which is really annoying and i've been telling them for ages and they always change the level manually themselves but they don't bloody change the friggen goddamn map change timer coz server admins are retarded or something ok?! so if they don't even know how to change the goddamn map change time limit how are you gonna expect them to fix this?
and btw people complained about this bug in CS and that is Valve's responsibility so Valve better bloody well listen!
Cause I was scrimming the other day and me and my teamate got ambushed from behind in a dead end hallway. Then seamingly (after I died) the skulk appeared out of nowhere and killed my teamate.<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
The leap exploit still exists. A typical giveaway of this exploit is that you can see a skulk leaping repeatedly without making any leaping noises (while he has <i>not</i> upgraded silence, i.e. you still hear it's footstep and biting. However, an occasional lack of a leap sound may also have other reasons, like packet loss or overflow of sound channels!).
As to my technical understanding, this due to the player movement being fully client-side only - which seems to be a necessity for the netcode to allow smooth player movement, but also may be the reason for other problems, like the PSHB.
And invis models can be prevented with mp_consistency enabled on the server, <i>if</i> the server has it enabled.
<!--QuoteBegin-Head crab+Jul 4 2004, 04:19 AM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Head crab @ Jul 4 2004, 04:19 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> This is not a Steam/Valve related bug. If it happens in some other mods, it's because the coder of these mods did the same common coding error as this one.
The way this error is caused is also a common in many plugins.<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
Head crab, do you have any further details or references about this ?
PSHBf
in the server's hostname.
Thank you to everyone involved for your efforts. Best of luck moving forward.
can't you just tell Flayra so we can be done with this nonsense please.
telling an admin to fix this is just not going to work. on this major popular server i play on, everytime there is an admin on there, they change the level after each round because that's what they like and everyone else too because nobody likes sleeping in the same position the whole night and i keep asking them to change the map change time limit because when there is no admin then we have to play the same map several times which is really annoying and i've been telling them for ages and they always change the level manually themselves but they don't bloody change the friggen goddamn map change timer coz server admins are retarded or something ok?! so if they don't even know how to change the goddamn map change time limit how are you gonna expect them to fix this?
and btw people complained about this bug in CS and that is Valve's responsibility so Valve better bloody well listen! <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd-->
Read the important posts and you will see that the dev team knows about this bug since the first day we have found it.
There is a Metamod version of the fixes, as stated in my post above, check it out at <a href='http://www.modns.org/' target='_blank'>modns.org</a>
<!--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-->
the reason they don't understand how it fixes the bug is because it doesn't fix the bug. it just introduces another bug that causes this bug to be avoided. <!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
And how does this create yet another bug?
To repeat what others are already saying: They <i>do</i>.
mfg
Lance