Pshb And What's Going On.
ElvenThief
aka Elven Thief (ex. NS Programmer) Join Date: 2002-11-15 Member: 8754Members, Retired Developer, NS1 Playtester, Constellation
aka Elven Thief (ex. NS Programmer) Join Date: 2002-11-15 Member: 8754Members, Retired Developer, NS1 Playtester, Constellation
<div class="IPBDescription">I think you're in for a good read</div> [BIGGEST EDIT EVER]
Valve has fixed the bug.
It should be updated to Steam sometime soon, according to the email. GG on this one, everyone.
[Back to original post]
I talked with Nemesis Zero, and although he offered to announce what was going on, I took it upon myself to update you guys.
So, at this point, I'm sure a lot of you are imagining "What is going on with PHSB?" and, "Is it fixed in beta 5?"
The short of it is, we have discovered a lot more than we imagined about the Player Specific Hitbox Bug. As of right now, it is not fixed and with a bit of reason.
Here's the long of it:
Firstly, thanks needs to be extended to the community for putting such an effort into tracking down this bug and finding a surefire way of reproducing it.
For those who aren't familiar with the PSHB, it's a bug that affects player #N on a #N player server. For instance, if you're on a 10 player server and type "status" in your console, you'll find that player 10 will be harder to kill, seem invincible, or completely own you and never seem to die.
At first, I thought, perhaps it was some kind of issue where bullets weren't counting or an invulnerability or some kind of weird error was going on. Turns out, it was a weird error.
You CAN kill a bugged player, but there's a trick to it. If a bugged player is moving, the model you see on your screen is not the model that the server is seeing. Ironically, if a spectator is 1st person viewing you shooting at a bugged player, he will see what the server is seeing.
<b><u>Screenshots and examples</u></b>
Here I am, shooting a "bugged" TyrNemesis. This is a 2 player max server and he is number 2. He is also strafing in each picture, as if he's not moving, he takes damage like the rest of us. In the first 2 shots, I am shooting directly at the model I see (which is not what the server sees). Additionally, my view will render my bullets hitting the fade model and will not show bullet decals on the walls behind. If another player was watching me shoot at the fade, it would look like I was just shooting behind him. The 3rd party would also see sparks, bullet decals, and wonder where the hell I learned to aim (I'd tell em counter-strike - jk).
<img src='http://www.holymight.com/ns/hmgnolead.jpg' border='0' alt='user posted image' />
Here's another picture. You will notice in each picture, that there are no bullet holes behind the fade and that my bullets do render as if they're hitting the fade. There's just no blood.
<img src='http://www.holymight.com/ns/hmgnolead1.jpg' border='0' alt='user posted image' />
Essentially, what the client is seeing is not what the server believes to be true. A listenserver or 1st person spectator does not seem to have this problem.
Now... to kill a bugged player, you just have to lead a bit - A 3rd party onlooker would see me aiming directly at the fade and all my bullets hitting. At the same time, my rendering will show bullet decals on the wall and sparks, BUT it will also show blood, confirming I have actually hit our bugged player.
<img src='http://www.holymight.com/ns/hmglead.jpg' border='0' alt='user posted image' />
This is also hitting the "bugged' fade.
<img src='http://www.holymight.com/ns/hmglead1.jpg' border='0' alt='user posted image' />
RIP AND TEAR
<img src='http://www.holymight.com/ns/hmglead2.jpg' border='0' alt='user posted image' />
AND YOU WONDERED WHERE THE SPARKS BUG CAME FROM - example 4
<img src='http://www.holymight.com/ns/sparks.jpg' border='0' alt='user posted image' />
So, now you say "Yes Thief. Now we know what the bug does, what did you do to fix it?" Firstly, I scanned the crap out of the NS code for anything that would signify rendering a player different, based on being in the last slot on a server. Of course, I found nothing (OMG! what a nub).
However, thanks to the diligence of Grepdashv, Ari, and TyrNemesis, we came up with a little more shocking information...
<b><u>Uh Oh</u></b>
This bug exists in every Half-Life mod. That's right. We've managed to reproduce it in Counter-Strike(1.6 and 1.5), DoD, NS, and even Half-Life Death Match. Also have managed to reproduce it on both Steam and Won versions of Half-life, CS and even NS.
Me and Grep have some demos from on HLDM and CounterStike and successfully reproduced the bug there. Here's a pic Grep compiled from split second screenshots where he is shooting me with a gauss gun by aiming in front of my model - you'll see that the client registers the bounced beam effect like it completely missed me, but there is also blood, as the server has registered a hit and told the client to render it. The corpse in the background is from a previous attempt. This shot gibbed me.
<img src='http://www.holymight.com/ns/bugged3.jpg' border='0' alt='user posted image' />
Now, you've gotta be asking - "how in the world has this never been figured out?" Well... there are some suspicions going around, and other people have noticed it in TFC, as from this "bug report" on the Steam Forums <a href='http://www.steampowered.com/forums/showthread.php?s=&threadid=102551' target='_blank'>Link Here</a> Do a ctrl-f for "hitbox" and you'll find that even TFC gets a "bugged" player that they have to aim in front of to kill. It just appears that the reasoning and way of reproducing it wasn't figured out.
Here's a direct quote:
<!--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-->Name: Hitscan / Hitbox bug.
Explanation: This is a bug that's occurring frequently on most servers. When in effect, the hitbox bug results in 'afflicted' players being extremely tough to hit successfully with hitscan weapons. The effect appears to move the hitboxes ahead of the player (in that the player is always behind their hitbox). As a consequence, it is like a reverse of the old interp effect, and a return to the days of leading targets. Unfortunately, the faster the class, the more pronounced the effect. A scout with the hitbox bug is so fast and the hitboxes so seperated from the player that using grenades and projectile weapons (like the RPG) is the only way to kill them. No one has ever figured out for sure what causes this bug. It can affect players usiing the rates and configs they've always used. Their game does not suffer as a result, everything appears normal to them. Some players seem to experience this bug more than others, but in general, it can potentially affect anyone. Reconnecting to the server usually has little or no effect (for either the person experiencing the bug, or the players faced with the problem of dealing with the aforementioned player). In general, on an 18 person clanserver, you can expect one or two to be experiencing the bug. Curiously, some people appear to only be partially unhittable (in that a full on shot will do half damage) whilst others are just totally unhittable unless one leads them with the shot by half to one bodylength (sometimes more, if they are a scout).<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
Additionally, most other mods don't have players that move as fast as our players do (especially aliens). The disparity between what the server knows and what the client sees is proportional to the speed of the player moving. A blinking fade or flying lerk are damn near impossible to lead to deal any damage. Also keep in mind that for the longest time, the bug was blamed on lag or poor aim. That and a specator seems to see the correct placement of the model, so if you're spectating a guy shooting a bugged player, you'll just assume their aim sucks.
At this point, Ari and myself have already posted on the Half-Life coder's mailing, which many Valve employees do read. Unfortunately, at this moment, we do NOT have a fix for beta 5, as you can probably guess, as this appears to be engine related and affects every Half-Life mod. Or it's a bug that exists in every mod from same usage of the same SDK (I can't find evidence supporting this).
There's a strong chance that Valve is going to see this and read it, and hell, the more publicity,the better chances of getting a fix out there. Voogru has already started attempting work arounds for the last player to see what he can get fixed on the client rendering, but at the moment, we're at an impasse.
I just want to say thanks to the community for all the assistance in attempting to get this bug fixed (especially Saraph, for helping us track the specifics of this bug when our understanding of it was in its infancy, and to Head Crab and Alpha of [C.A.P] For realizing the cause of the bug)
I just feel everyone deserved to be "in the know" now, as it were.
[EDIT] - Here's another update.
Since I've posted this, there seems to be a lot of debate about whether this bug does exist. Some think it's nothing more than a rate or ex_interp change/bug/hack.
While I would buy that, I defend my case as any such change or bug would have to have a uniform effect, no matter what slot on the server you get.
However, a client with the same rate settings in slot 15 of 16 will not have the same problem getting shot as a client in slot 16 of 16. There is no logic in blaming it on rates.
[Big Edit 2] There seems to be a general consensus that I've failed to put credit where credit is due. I named Seraph, Head Crab and Alpha above already as they spearheaded the search to find a way to reproduce the bug (I used Seraph instead of Sarisel - his forum name - as I had talked with Firewater on irc before and that's the name that stuck.)
At the time that I joined the ns dev team as a coder - about 3 weeks ago, this was the first bug I wanted to tackle. I don't know all the politics behind finding the bug, as work had made my playtesting duties wane a bit. I was given Sarisel's document that had been sent to Flayra and went from there.
By that time I got Grep, Ari, Tyr and a variety of playtesters to constantly playtest and we were trying to find varients of ways to make it show or not show - this led to the weird spectator issues. This is where I spent most of the work and it all ended up 2 nights ago with us reproducing on every mod that we could get to run on a dedicated server.
This entire post was meant to be informative, and not to take credit. Take it as you will.
Valve has fixed the bug.
It should be updated to Steam sometime soon, according to the email. GG on this one, everyone.
[Back to original post]
I talked with Nemesis Zero, and although he offered to announce what was going on, I took it upon myself to update you guys.
So, at this point, I'm sure a lot of you are imagining "What is going on with PHSB?" and, "Is it fixed in beta 5?"
The short of it is, we have discovered a lot more than we imagined about the Player Specific Hitbox Bug. As of right now, it is not fixed and with a bit of reason.
Here's the long of it:
Firstly, thanks needs to be extended to the community for putting such an effort into tracking down this bug and finding a surefire way of reproducing it.
For those who aren't familiar with the PSHB, it's a bug that affects player #N on a #N player server. For instance, if you're on a 10 player server and type "status" in your console, you'll find that player 10 will be harder to kill, seem invincible, or completely own you and never seem to die.
At first, I thought, perhaps it was some kind of issue where bullets weren't counting or an invulnerability or some kind of weird error was going on. Turns out, it was a weird error.
You CAN kill a bugged player, but there's a trick to it. If a bugged player is moving, the model you see on your screen is not the model that the server is seeing. Ironically, if a spectator is 1st person viewing you shooting at a bugged player, he will see what the server is seeing.
<b><u>Screenshots and examples</u></b>
Here I am, shooting a "bugged" TyrNemesis. This is a 2 player max server and he is number 2. He is also strafing in each picture, as if he's not moving, he takes damage like the rest of us. In the first 2 shots, I am shooting directly at the model I see (which is not what the server sees). Additionally, my view will render my bullets hitting the fade model and will not show bullet decals on the walls behind. If another player was watching me shoot at the fade, it would look like I was just shooting behind him. The 3rd party would also see sparks, bullet decals, and wonder where the hell I learned to aim (I'd tell em counter-strike - jk).
<img src='http://www.holymight.com/ns/hmgnolead.jpg' border='0' alt='user posted image' />
Here's another picture. You will notice in each picture, that there are no bullet holes behind the fade and that my bullets do render as if they're hitting the fade. There's just no blood.
<img src='http://www.holymight.com/ns/hmgnolead1.jpg' border='0' alt='user posted image' />
Essentially, what the client is seeing is not what the server believes to be true. A listenserver or 1st person spectator does not seem to have this problem.
Now... to kill a bugged player, you just have to lead a bit - A 3rd party onlooker would see me aiming directly at the fade and all my bullets hitting. At the same time, my rendering will show bullet decals on the wall and sparks, BUT it will also show blood, confirming I have actually hit our bugged player.
<img src='http://www.holymight.com/ns/hmglead.jpg' border='0' alt='user posted image' />
This is also hitting the "bugged' fade.
<img src='http://www.holymight.com/ns/hmglead1.jpg' border='0' alt='user posted image' />
RIP AND TEAR
<img src='http://www.holymight.com/ns/hmglead2.jpg' border='0' alt='user posted image' />
AND YOU WONDERED WHERE THE SPARKS BUG CAME FROM - example 4
<img src='http://www.holymight.com/ns/sparks.jpg' border='0' alt='user posted image' />
So, now you say "Yes Thief. Now we know what the bug does, what did you do to fix it?" Firstly, I scanned the crap out of the NS code for anything that would signify rendering a player different, based on being in the last slot on a server. Of course, I found nothing (OMG! what a nub).
However, thanks to the diligence of Grepdashv, Ari, and TyrNemesis, we came up with a little more shocking information...
<b><u>Uh Oh</u></b>
This bug exists in every Half-Life mod. That's right. We've managed to reproduce it in Counter-Strike(1.6 and 1.5), DoD, NS, and even Half-Life Death Match. Also have managed to reproduce it on both Steam and Won versions of Half-life, CS and even NS.
Me and Grep have some demos from on HLDM and CounterStike and successfully reproduced the bug there. Here's a pic Grep compiled from split second screenshots where he is shooting me with a gauss gun by aiming in front of my model - you'll see that the client registers the bounced beam effect like it completely missed me, but there is also blood, as the server has registered a hit and told the client to render it. The corpse in the background is from a previous attempt. This shot gibbed me.
<img src='http://www.holymight.com/ns/bugged3.jpg' border='0' alt='user posted image' />
Now, you've gotta be asking - "how in the world has this never been figured out?" Well... there are some suspicions going around, and other people have noticed it in TFC, as from this "bug report" on the Steam Forums <a href='http://www.steampowered.com/forums/showthread.php?s=&threadid=102551' target='_blank'>Link Here</a> Do a ctrl-f for "hitbox" and you'll find that even TFC gets a "bugged" player that they have to aim in front of to kill. It just appears that the reasoning and way of reproducing it wasn't figured out.
Here's a direct quote:
<!--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-->Name: Hitscan / Hitbox bug.
Explanation: This is a bug that's occurring frequently on most servers. When in effect, the hitbox bug results in 'afflicted' players being extremely tough to hit successfully with hitscan weapons. The effect appears to move the hitboxes ahead of the player (in that the player is always behind their hitbox). As a consequence, it is like a reverse of the old interp effect, and a return to the days of leading targets. Unfortunately, the faster the class, the more pronounced the effect. A scout with the hitbox bug is so fast and the hitboxes so seperated from the player that using grenades and projectile weapons (like the RPG) is the only way to kill them. No one has ever figured out for sure what causes this bug. It can affect players usiing the rates and configs they've always used. Their game does not suffer as a result, everything appears normal to them. Some players seem to experience this bug more than others, but in general, it can potentially affect anyone. Reconnecting to the server usually has little or no effect (for either the person experiencing the bug, or the players faced with the problem of dealing with the aforementioned player). In general, on an 18 person clanserver, you can expect one or two to be experiencing the bug. Curiously, some people appear to only be partially unhittable (in that a full on shot will do half damage) whilst others are just totally unhittable unless one leads them with the shot by half to one bodylength (sometimes more, if they are a scout).<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
Additionally, most other mods don't have players that move as fast as our players do (especially aliens). The disparity between what the server knows and what the client sees is proportional to the speed of the player moving. A blinking fade or flying lerk are damn near impossible to lead to deal any damage. Also keep in mind that for the longest time, the bug was blamed on lag or poor aim. That and a specator seems to see the correct placement of the model, so if you're spectating a guy shooting a bugged player, you'll just assume their aim sucks.
At this point, Ari and myself have already posted on the Half-Life coder's mailing, which many Valve employees do read. Unfortunately, at this moment, we do NOT have a fix for beta 5, as you can probably guess, as this appears to be engine related and affects every Half-Life mod. Or it's a bug that exists in every mod from same usage of the same SDK (I can't find evidence supporting this).
There's a strong chance that Valve is going to see this and read it, and hell, the more publicity,the better chances of getting a fix out there. Voogru has already started attempting work arounds for the last player to see what he can get fixed on the client rendering, but at the moment, we're at an impasse.
I just want to say thanks to the community for all the assistance in attempting to get this bug fixed (especially Saraph, for helping us track the specifics of this bug when our understanding of it was in its infancy, and to Head Crab and Alpha of [C.A.P] For realizing the cause of the bug)
I just feel everyone deserved to be "in the know" now, as it were.
[EDIT] - Here's another update.
Since I've posted this, there seems to be a lot of debate about whether this bug does exist. Some think it's nothing more than a rate or ex_interp change/bug/hack.
While I would buy that, I defend my case as any such change or bug would have to have a uniform effect, no matter what slot on the server you get.
However, a client with the same rate settings in slot 15 of 16 will not have the same problem getting shot as a client in slot 16 of 16. There is no logic in blaming it on rates.
[Big Edit 2] There seems to be a general consensus that I've failed to put credit where credit is due. I named Seraph, Head Crab and Alpha above already as they spearheaded the search to find a way to reproduce the bug (I used Seraph instead of Sarisel - his forum name - as I had talked with Firewater on irc before and that's the name that stuck.)
At the time that I joined the ns dev team as a coder - about 3 weeks ago, this was the first bug I wanted to tackle. I don't know all the politics behind finding the bug, as work had made my playtesting duties wane a bit. I was given Sarisel's document that had been sent to Flayra and went from there.
By that time I got Grep, Ari, Tyr and a variety of playtesters to constantly playtest and we were trying to find varients of ways to make it show or not show - this led to the weird spectator issues. This is where I spent most of the work and it all ended up 2 nights ago with us reproducing on every mod that we could get to run on a dedicated server.
This entire post was meant to be informative, and not to take credit. Take it as you will.
This discussion has been closed.
Comments
Additionally:
<!--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-->
[04:37] <@TyrNemesis^[GP]> try playing with sv_unlag 0
[04:37] <@TyrNemesis^[GP]> EVERYONE will be bugged
[04:37] <@TyrNemesis^[GP]> that should be mentioned
[04:37] <@TyrNemesis^[GP]> sv_unlag 0 makes ALL players behave this way
<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
RIP AND TEAR YOUR GUTS <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html//emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif' /><!--endemo-->
nice read <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo-->
Thanks for the update, I can now go off at anyone blaming Flayra for the bug and start knocking VALVe as usual <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo-->
Baha
Good, diligent work from the people that reproduced this bug and tested it in other mods.
No, he said he found the same problem on WON servers. Just takes a leet community like ns to find these long standing bugs. GJ guys.
/me cant wait for hl2.
[04:37] <@TyrNemesis^[GP]> EVERYONE will be bugged
[04:37] <@TyrNemesis^[GP]> that should be mentioned
[04:37] <@TyrNemesis^[GP]> sv_unlag 0 makes ALL players behave this way <!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
Sounds like theres a < being used instead of a <= within the sv_unlag code.
btw...
does this mean we can have the update now? (he asks in a meak voice. dont hit me)
or are there some other problems that need to be fixed first?
yeah that sounds like the most possible situation. Hope valve decide to haul some **** and fix it and use this magical steam thing they claim to have to deliver the fix to all of us <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo-->.
Congratulations to everyone involved in helping us bring this bug to the light of day. NS is truly a game about teamwork, and it's teamwork that's allowed us to make the progress we've made here.
Much love to everyone out there, particularly Head Crab, Alpha, Saraph, grep, ari, Elven, voogru, KaiserRoll, Chimpzealot, JazzX, Yumosis, Magitek, myself, and everyone else that's made this possible.
W00t!
*edit: I made up a nice tombstone. It's up to valve to dig a nice, deep grave.*
btw...
does this mean we can have the update now? (he asks in a meak voice. dont hit me)
or are there some other problems that need to be fixed first? <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd-->
The ball is in Valve's court now.
RIP AND TEAR!
See these are the type of updates the community wants to hear...
Wouldn’t the simplest work around for this be to simply make the server one slot larger and have one reserve slot, as a temporary work around until valve fixes their problem?
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?
<!--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-->Sounds like theres a < being used instead of a <= within the sv_unlag code. <!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
That would be such a shamefull error to make. <!--emo&:D--><img src='http://www.natural-selection.org/forums/html//emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif' /><!--endemo-->
Keep up the good work.
The ball is in Valve's court now. [/QUOTE]
i know. that is why i asked <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo-->
That would be such a shamefull error to make. <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html//emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif' /><!--endemo--><!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
The little mistakes are ALWAYS the hardest to find, so that would come as no surprise I'm sure....
Someone will be beating their head against thge desk for hours over this one XD
j/k.. its bad news tbh.. i guess im not the only one who's swearin when i dont kill that buggy player.
<!--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--> Is it possible to get around this problem by creating a dummy last slot?<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
Hopefully, if you got a 20 player server then make it 21 with one slot not open <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo-->.
Im not an expert but thats my guess
Credit where credit is due I say!
<a href='http://www.unknownworlds.com/forums/index.php?showtopic=70356&hl=' target='_blank'>http://www.unknownworlds.com/forums/in...topic=70356&hl=</a>