Repro: Player-specific Bugged Hitboxes
Sarisel
.::' ( O ) ';:-. .-.:;' ( O ) '::. Join Date: 2003-07-30 Member: 18557Members, Constellation
.::' ( O ) ';:-. .-.:;' ( O ) '::. Join Date: 2003-07-30 Member: 18557Members, Constellation
<div class="IPBDescription">public demo-collection effort</div> <span style='font-size:14pt;line-height:100%'><span style='color:red'><b>Current status: PSHB has been isolated and is reproduceable. </b></span></span>
<a href='http://www.freewebs.com/iriot/pshbtheory.doc' target='_blank'>PSHB theory (.doc file)</a>
<u><b><span style='color:blue'>Temporary Fixes for Server Admins with AMX plugin (from [C.A.P.]HeadCrab):</span></b></u>
First fix: this one uses 2 slots and disconnects extra players:
There are two hidden slots for the server, the last and second last. If a client connects to the server when it is full (without the last two slots), he temporarily gets assigned the second last slotID, which doesn't do anything. He then gets disconnected. Theoretically, the last slotID should never be assigned to any player in this way.
<a href='http://www.capcstrike.com/ns/files/amx-psbh-fix1.sma' target='_blank'>First fix for AMX</a>
<a href='http://www.capcstrike.com/ns/files/amxx-psbh-fix1.sma' target='_blank'>First fix for AMX-X</a>
Second fix: this one uses 1 slot and adds a random password to the server:
Basically, this reserves only the last slotID and puts a random password on the server whenever the reserved slot is the only slot available to connect to. This way, the client cannot connect to the server and thus cannot get the last slotID.
<a href='http://www.capcstrike.com/ns/files/amx-psbh-fix2.sma' target='_blank'>Second fix for AMX</a>
<a href='http://www.capcstrike.com/ns/files/amxx-psbh-fix2.sma' target='_blank'>Second fix for AMX-X</a>
<u><b><span style='color:blue'>Temporary Fixes for Server Admins with METAMOD plugin (from [C.A.P.]HeadCrab):</span></b></u>
<a href='http://www.modns.org/forums/index.php?showtopic=661&st=0&#entry5720' target='_blank'>modns.org forum post with the fix</a>
<span style='font-size:8pt;line-height:100%'><u>History:</u>
10.05.2004 - exclusive footage (about 30 mins worth) of the bug recorded in 6 seperate demos, which make up the "t0x series."
11.05.2004 - more bug footage (about 40 mins) recorded in another 6 demos, which make up the "MMX-Darien series". Update to knowledge base, see d.3).
<span style='color:red'><b>27.06.2004 - I've been informed by sources that the PSHB has been tracked down and the cause of the problem is now known to be related to server code. </b></span>
01.07.2004 - <b>last update</b>: I am confident that the process of this bug's occurance has been isolated. My job here is done. Thanks to all of the people who have contributed in the pursuit of this issue. If not for you, this issue may have never been resolved.</span>
<!--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-->Today I was privileged to participate in some official testing of this now reproduceable effect with grep, tyr, and keis. It is real and I'm quite confident that the process of pshb has now been identified and isolated. Best of all, it is reproduceable. The bug that has frustrated so many people (including me) can now be recreated. It was a great feeling to finally confront the monster that has ruined so many of my NS game hours in the past. Almost like in a conclusion from a detective documentary, all the pieces of evidence collected finally resulted in the apprehension of the murderer.
A big thanks to [C.A.P]Alpha for reading this topic a few weeks ago, spreading the word, and actually taking a proactive approach to tracking the bug down. This is exactly what I had hoped would happen. Also, congratulations to the [C.A.P.] server admin (Head Crab) who managed to use his HL server knowledge to identify exactly what was going on. You have done an incredible service to the development of NS.
Now that the existence of this bug has been proven beyond a shadow of a doubt, my job is done. I have documented this bug as best as I could since the closed beta-testing period of NS3.0. Now, several months later, the breakthrough has finally come.
For those of you who do not know how the bug works, you can find comfort in knowing that even if the bug cannot be corrected via coding, a way of bypassing it has already been devised by the duo from [C.A.P.] before a bug report was even submitted.
As a final note, to all of you who completely wrote the entire issue off as netcode, bad aim, etc. and especially to all of those players (especially my fellow vets - in particular, one specific person who was very vocal in #cri's channel after a scrim) that have ridiculed and laughed at the claims of PSHB:
I told you so.
CAL should be informed of the process of reproducing this effect, since it is exploitable and it is quite possible that certain players have been intentionally using this bug in matches. <!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
<span style='color:blue'><u>Overview:</u></span>
Back in the days when the beta was still in closed testing mode, it was noted that sometimes certain players simply did not take normal damage, but only a fraction of it. Skulks would run through volleys of accurate machinegun fire, escaping with only a few scratches. Fades would absorb shotgun shells without taking any damage. On the marine side, players could jump around and not get hit by attacks from alien lifeforms. This was something that was rarely ever seen in 2.01, but which was now so common in the beta that it got repulsive.
At that time, I made a report on that bug in the private beta discussion forums, which grew to be 13 pages long before, finally, the veteran program was dissolved and now I no longer have access to those forums. The problem was never really addressed, but several excuses were used to explain it. Bad aim was the worst excuse, since the closed beta featured the best players playing on only a few servers. Special tests were made to demonstrate the bug through veteran and cm collaboration. Netcode issues and lag were the most notable arguments, but as I will mention later, they are not valid. At one point, I blamed Steam for this issue since I believed that I saw the same thing in other mods. However, after reviewing my convictions, I was forced to admit that this problem was not necessarily related to Steam at all.
This thread has two purposes. One is to make the public more aware of the bug's existence. It has been the most controversial topic of discussion for quite some time and, to this day, there are still many non-believers. The second purpose is to reach out to the public to provide evidence of this bug so that this issue can first be officially recognized so that maybe it could finally be addressed.
___________________________________________
The bug occurs when a certain player connects to the server. The player joins a team and enters the map. <u>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</u>. 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.
<u>
The effects of the bug are as follows:</u>
a) Whenever the player stands still, he takes normal damage from all attacks. It is <u>only when the player moves</u> that the bug takes effect. When the player moves, attacks are <u>absorbed with no damage taken or go through the player</u>.
a.1) The more mobile the bugged player is, the harder it is to deal damage. (Celerity fades, for example, are worse when bugged than normal bugged fades.)
a.2) However, the bug affects all classes to an extent no matter how fast they move, as long as they <b>move</b>. Vanilla marines, Jetpackers, Heavy Armors, Gorges, Skulks, whatever.
b) When attacks get absorbed, the sound of the attack landing on the player is heard, but no damage is taken and no blood is seen.
b.1) This can be differentiated from normal lag since the bugged players show this effect consistently and there is no discrimination whether the bugged player has high ping or low ping.
b.2) Every player that attacks the bugged player will experience the same effect. This disproves the 'bad aim' theory that was so popular during the early stages of this bug's discussion.
b.3) Observers can see the bugged players being hit. Before 3.0beta4, observers could see sparks from projectiles that hit the bugged player.
b.4)<u>In addition, the bugged players themselves can hear and could see sparks on themselves.</u> This disproves the netcode/lag theories, since <b>only the attacker should see the sparks/hear the sound, not the bugged player as well.</b>
c) Occasionally, upon attacking a bugged player, attackers can score full damage without aiming anywhere remotely near the actual bugged player's model - I am talking about several feet behind or around the model. Aiming at the model itself is <b>ineffective</b> as long as the bugged player moves.
c.1) The location of the actual hit-registering area has not been reliably charted for bugged players, which has been one of the difficulties with the tracking of this bug.
c.2) This effect is different from the normal hitbox lag that you may have noticed when playing on NS servers with all players. The normal hitbox lag has a range of a foot at most and slightly more if the player is moving at very high speeds. The bug in question, however, is not the same.
d) Once the player has the bug, the effects hold until the player switches servers. That means, if the player leaves the server and comes back then that player retains the bugged effect. The bugged effects remain throughout game rounds and map changes. Even if the player <b>quits his NS game and goes back to his desktop, upon return he still has the same bugged effects.</b>
d.1) It is unknown what causes the player to lose the bugged effect on his current server. From my experiences of being bugged, I tended to lose the effect after leaving the server for several hours. However, I did play while I was bugged for several hours without losing the effects.
d.2) The above clearly points to some problem that occurs between client and server during the connection process or throughout the client's connection time.
d.3) <b>11th May 2004 - update - The bugged effect is lost if the server crashes/restarts. </b>
e) The problem does not seem to be a client side issue since a variety of people get this bug when playing, each with different computer systems and network settings. HL specific settings that were tested included cl_updaterate, cl_rate, rate. These did not have any significant impact on the bugged hitboxes.
e.1) On a sidenote, exploiting of the cl_cmdrate command does affect hit registry but not in the same way as the hitbox bug in question here. Low values of cl_cmdrate cause visual lag and general jerkiness, which is not a feature of the bug in discussion.
___________________________________________
<u>
When to suspect the PSHB (Player Specific Hitbox Bug):</u>
<u>
Pre-requisites:</u>
1. Your aim must be good and you must be able to register damage on other enemies without nearly as much difficulty. If your aim is not on at least 60% of the time that you shoot, then chances are that you are just missing. If you are confident that your shots are landing on the target but producing no damage, that is usually the most obvious sign that PSHB is present.
2. Other players should also be having difficulty registering hits only on that specific player. The easiest way to find out about this is to ask whether they are having problems registering damage on that target.
3. Finally, if possible, ask the suspected player whether he is taking low damage. This is difficult since players are overprotective about their performance in-game - what you'll usually end up getting is an egoistic reply.
<u>
Observation:</u>
1. Enter spectator mode and watch the suspected player in first person mode. This way you can see the health and armor status. Now...
1.1 ...note whether or not the player takes damage at a rate that is constant when he is engaging enemies. In other words, does the health go down gradually or does it suddenly drop down (especially when the player stops for a split second, when changing direction for example).
1.2 ...listen for sounds and visuals of the suspected player getting hit by attacks and then see if the appropriate amount of health and armor is lost. Listen for 'hit' sounds that do not result in a significant loss of health and armor. This is easiest to note with skulks, who should not survive more than 9 lmg bullets and definitely not a direct shotgun blast.
1.3 ...observe from 3-rd person and see how much blood the suspected player drops when fighting and getting hit by attacks. From experience, you should know how much blood a direct shotgun blast produces and whether a splatter of blood is seen when one bullet connects.
1.4 ...try to look at how other players fight against the suspected bugged player. Do they all have the same problem (little to no hits registering) when fighting that player? This might take a few minutes due to the fast-paced nature of the game.
<u>
Conclusion:</u>
1. If your observations are consistent with the effects described above for the PSHB, then you may well be observing this bug.
2. Do not start criticizing or berating the player that has this bug. Public awareness of this issue is not very good and ranting about it will just get you ridiculed. If you can't stand playing with the bug in the server, go elsewhere. However, you could be more useful. Ask the player if he could record a demo. Once again, this is difficult and depends on how diplomatic you are.
3. Record your own demo when observing this player. Try to get as much good evidence in as possible.
4. If you want to test any of the effects of the bug, you may want to follow the player around to other servers to see if the effects persist. This is only for those who are interested enough to actually go that far.
___________________________________________
<u>
Evidence Collection</u>
The second reason for this thread, as stated before, was to try and retrieve more evidence to bring this bug to the attention of the people that can do something about it. So far, I have a small collection of demos that I have analyzed and reviewed. What I need is more demos (<u>valid demos</u>) to add to the collection. Once I have enough evidence on me to clearly prove to the development team that, without a doubt, this bug really does exist and that it really does affect the way that the game plays, both in competitive and public games, then perhaps a greater effort will be organized to hunt down this abomination.
Update: I no longer need any demos, since the bug has been isolated and acknowledged by the Exterminators.
<span style='color:red'><b>t0x series is made public, to encourage people's input. Thanks to Wyzkrak for hosting.</b>
<a href='http://s90175778.onlinehome.us/ns3.0/t0xseries.rar' target='_blank'>download t0x series here</a></span>
___________________________________________
<u>To record a demo (as per request):</u>
1. Open your console and type: record demoname
<i>where demoname is whatever you want to call your demo</i>
2. When you want to stop recording the demo, type in console: stop
3. If you want to review your demo, type either: viewdemo demoname
or: playdemo demoname
_________________________________________
<a href='http://www.freewebs.com/iriot/pshbtheory.doc' target='_blank'>PSHB theory (.doc file)</a>
<u><b><span style='color:blue'>Temporary Fixes for Server Admins with AMX plugin (from [C.A.P.]HeadCrab):</span></b></u>
First fix: this one uses 2 slots and disconnects extra players:
There are two hidden slots for the server, the last and second last. If a client connects to the server when it is full (without the last two slots), he temporarily gets assigned the second last slotID, which doesn't do anything. He then gets disconnected. Theoretically, the last slotID should never be assigned to any player in this way.
<a href='http://www.capcstrike.com/ns/files/amx-psbh-fix1.sma' target='_blank'>First fix for AMX</a>
<a href='http://www.capcstrike.com/ns/files/amxx-psbh-fix1.sma' target='_blank'>First fix for AMX-X</a>
Second fix: this one uses 1 slot and adds a random password to the server:
Basically, this reserves only the last slotID and puts a random password on the server whenever the reserved slot is the only slot available to connect to. This way, the client cannot connect to the server and thus cannot get the last slotID.
<a href='http://www.capcstrike.com/ns/files/amx-psbh-fix2.sma' target='_blank'>Second fix for AMX</a>
<a href='http://www.capcstrike.com/ns/files/amxx-psbh-fix2.sma' target='_blank'>Second fix for AMX-X</a>
<u><b><span style='color:blue'>Temporary Fixes for Server Admins with METAMOD plugin (from [C.A.P.]HeadCrab):</span></b></u>
<a href='http://www.modns.org/forums/index.php?showtopic=661&st=0&#entry5720' target='_blank'>modns.org forum post with the fix</a>
<span style='font-size:8pt;line-height:100%'><u>History:</u>
10.05.2004 - exclusive footage (about 30 mins worth) of the bug recorded in 6 seperate demos, which make up the "t0x series."
11.05.2004 - more bug footage (about 40 mins) recorded in another 6 demos, which make up the "MMX-Darien series". Update to knowledge base, see d.3).
<span style='color:red'><b>27.06.2004 - I've been informed by sources that the PSHB has been tracked down and the cause of the problem is now known to be related to server code. </b></span>
01.07.2004 - <b>last update</b>: I am confident that the process of this bug's occurance has been isolated. My job here is done. Thanks to all of the people who have contributed in the pursuit of this issue. If not for you, this issue may have never been resolved.</span>
<!--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-->Today I was privileged to participate in some official testing of this now reproduceable effect with grep, tyr, and keis. It is real and I'm quite confident that the process of pshb has now been identified and isolated. Best of all, it is reproduceable. The bug that has frustrated so many people (including me) can now be recreated. It was a great feeling to finally confront the monster that has ruined so many of my NS game hours in the past. Almost like in a conclusion from a detective documentary, all the pieces of evidence collected finally resulted in the apprehension of the murderer.
A big thanks to [C.A.P]Alpha for reading this topic a few weeks ago, spreading the word, and actually taking a proactive approach to tracking the bug down. This is exactly what I had hoped would happen. Also, congratulations to the [C.A.P.] server admin (Head Crab) who managed to use his HL server knowledge to identify exactly what was going on. You have done an incredible service to the development of NS.
Now that the existence of this bug has been proven beyond a shadow of a doubt, my job is done. I have documented this bug as best as I could since the closed beta-testing period of NS3.0. Now, several months later, the breakthrough has finally come.
For those of you who do not know how the bug works, you can find comfort in knowing that even if the bug cannot be corrected via coding, a way of bypassing it has already been devised by the duo from [C.A.P.] before a bug report was even submitted.
As a final note, to all of you who completely wrote the entire issue off as netcode, bad aim, etc. and especially to all of those players (especially my fellow vets - in particular, one specific person who was very vocal in #cri's channel after a scrim) that have ridiculed and laughed at the claims of PSHB:
I told you so.
CAL should be informed of the process of reproducing this effect, since it is exploitable and it is quite possible that certain players have been intentionally using this bug in matches. <!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
<span style='color:blue'><u>Overview:</u></span>
Back in the days when the beta was still in closed testing mode, it was noted that sometimes certain players simply did not take normal damage, but only a fraction of it. Skulks would run through volleys of accurate machinegun fire, escaping with only a few scratches. Fades would absorb shotgun shells without taking any damage. On the marine side, players could jump around and not get hit by attacks from alien lifeforms. This was something that was rarely ever seen in 2.01, but which was now so common in the beta that it got repulsive.
At that time, I made a report on that bug in the private beta discussion forums, which grew to be 13 pages long before, finally, the veteran program was dissolved and now I no longer have access to those forums. The problem was never really addressed, but several excuses were used to explain it. Bad aim was the worst excuse, since the closed beta featured the best players playing on only a few servers. Special tests were made to demonstrate the bug through veteran and cm collaboration. Netcode issues and lag were the most notable arguments, but as I will mention later, they are not valid. At one point, I blamed Steam for this issue since I believed that I saw the same thing in other mods. However, after reviewing my convictions, I was forced to admit that this problem was not necessarily related to Steam at all.
This thread has two purposes. One is to make the public more aware of the bug's existence. It has been the most controversial topic of discussion for quite some time and, to this day, there are still many non-believers. The second purpose is to reach out to the public to provide evidence of this bug so that this issue can first be officially recognized so that maybe it could finally be addressed.
___________________________________________
The bug occurs when a certain player connects to the server. The player joins a team and enters the map. <u>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</u>. 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.
<u>
The effects of the bug are as follows:</u>
a) Whenever the player stands still, he takes normal damage from all attacks. It is <u>only when the player moves</u> that the bug takes effect. When the player moves, attacks are <u>absorbed with no damage taken or go through the player</u>.
a.1) The more mobile the bugged player is, the harder it is to deal damage. (Celerity fades, for example, are worse when bugged than normal bugged fades.)
a.2) However, the bug affects all classes to an extent no matter how fast they move, as long as they <b>move</b>. Vanilla marines, Jetpackers, Heavy Armors, Gorges, Skulks, whatever.
b) When attacks get absorbed, the sound of the attack landing on the player is heard, but no damage is taken and no blood is seen.
b.1) This can be differentiated from normal lag since the bugged players show this effect consistently and there is no discrimination whether the bugged player has high ping or low ping.
b.2) Every player that attacks the bugged player will experience the same effect. This disproves the 'bad aim' theory that was so popular during the early stages of this bug's discussion.
b.3) Observers can see the bugged players being hit. Before 3.0beta4, observers could see sparks from projectiles that hit the bugged player.
b.4)<u>In addition, the bugged players themselves can hear and could see sparks on themselves.</u> This disproves the netcode/lag theories, since <b>only the attacker should see the sparks/hear the sound, not the bugged player as well.</b>
c) Occasionally, upon attacking a bugged player, attackers can score full damage without aiming anywhere remotely near the actual bugged player's model - I am talking about several feet behind or around the model. Aiming at the model itself is <b>ineffective</b> as long as the bugged player moves.
c.1) The location of the actual hit-registering area has not been reliably charted for bugged players, which has been one of the difficulties with the tracking of this bug.
c.2) This effect is different from the normal hitbox lag that you may have noticed when playing on NS servers with all players. The normal hitbox lag has a range of a foot at most and slightly more if the player is moving at very high speeds. The bug in question, however, is not the same.
d) Once the player has the bug, the effects hold until the player switches servers. That means, if the player leaves the server and comes back then that player retains the bugged effect. The bugged effects remain throughout game rounds and map changes. Even if the player <b>quits his NS game and goes back to his desktop, upon return he still has the same bugged effects.</b>
d.1) It is unknown what causes the player to lose the bugged effect on his current server. From my experiences of being bugged, I tended to lose the effect after leaving the server for several hours. However, I did play while I was bugged for several hours without losing the effects.
d.2) The above clearly points to some problem that occurs between client and server during the connection process or throughout the client's connection time.
d.3) <b>11th May 2004 - update - The bugged effect is lost if the server crashes/restarts. </b>
e) The problem does not seem to be a client side issue since a variety of people get this bug when playing, each with different computer systems and network settings. HL specific settings that were tested included cl_updaterate, cl_rate, rate. These did not have any significant impact on the bugged hitboxes.
e.1) On a sidenote, exploiting of the cl_cmdrate command does affect hit registry but not in the same way as the hitbox bug in question here. Low values of cl_cmdrate cause visual lag and general jerkiness, which is not a feature of the bug in discussion.
___________________________________________
<u>
When to suspect the PSHB (Player Specific Hitbox Bug):</u>
<u>
Pre-requisites:</u>
1. Your aim must be good and you must be able to register damage on other enemies without nearly as much difficulty. If your aim is not on at least 60% of the time that you shoot, then chances are that you are just missing. If you are confident that your shots are landing on the target but producing no damage, that is usually the most obvious sign that PSHB is present.
2. Other players should also be having difficulty registering hits only on that specific player. The easiest way to find out about this is to ask whether they are having problems registering damage on that target.
3. Finally, if possible, ask the suspected player whether he is taking low damage. This is difficult since players are overprotective about their performance in-game - what you'll usually end up getting is an egoistic reply.
<u>
Observation:</u>
1. Enter spectator mode and watch the suspected player in first person mode. This way you can see the health and armor status. Now...
1.1 ...note whether or not the player takes damage at a rate that is constant when he is engaging enemies. In other words, does the health go down gradually or does it suddenly drop down (especially when the player stops for a split second, when changing direction for example).
1.2 ...listen for sounds and visuals of the suspected player getting hit by attacks and then see if the appropriate amount of health and armor is lost. Listen for 'hit' sounds that do not result in a significant loss of health and armor. This is easiest to note with skulks, who should not survive more than 9 lmg bullets and definitely not a direct shotgun blast.
1.3 ...observe from 3-rd person and see how much blood the suspected player drops when fighting and getting hit by attacks. From experience, you should know how much blood a direct shotgun blast produces and whether a splatter of blood is seen when one bullet connects.
1.4 ...try to look at how other players fight against the suspected bugged player. Do they all have the same problem (little to no hits registering) when fighting that player? This might take a few minutes due to the fast-paced nature of the game.
<u>
Conclusion:</u>
1. If your observations are consistent with the effects described above for the PSHB, then you may well be observing this bug.
2. Do not start criticizing or berating the player that has this bug. Public awareness of this issue is not very good and ranting about it will just get you ridiculed. If you can't stand playing with the bug in the server, go elsewhere. However, you could be more useful. Ask the player if he could record a demo. Once again, this is difficult and depends on how diplomatic you are.
3. Record your own demo when observing this player. Try to get as much good evidence in as possible.
4. If you want to test any of the effects of the bug, you may want to follow the player around to other servers to see if the effects persist. This is only for those who are interested enough to actually go that far.
___________________________________________
<u>
Evidence Collection</u>
The second reason for this thread, as stated before, was to try and retrieve more evidence to bring this bug to the attention of the people that can do something about it. So far, I have a small collection of demos that I have analyzed and reviewed. What I need is more demos (<u>valid demos</u>) to add to the collection. Once I have enough evidence on me to clearly prove to the development team that, without a doubt, this bug really does exist and that it really does affect the way that the game plays, both in competitive and public games, then perhaps a greater effort will be organized to hunt down this abomination.
Update: I no longer need any demos, since the bug has been isolated and acknowledged by the Exterminators.
<span style='color:red'><b>t0x series is made public, to encourage people's input. Thanks to Wyzkrak for hosting.</b>
<a href='http://s90175778.onlinehome.us/ns3.0/t0xseries.rar' target='_blank'>download t0x series here</a></span>
___________________________________________
<u>To record a demo (as per request):</u>
1. Open your console and type: record demoname
<i>where demoname is whatever you want to call your demo</i>
2. When you want to stop recording the demo, type in console: stop
3. If you want to review your demo, type either: viewdemo demoname
or: playdemo demoname
_________________________________________
This discussion has been closed.
Comments
Keep the discussion flowing and if you have demos, contact Saraph (forum name: Sarisel) to send them to him.
<span style='color:green'>*webbed*</span>
I thought my skill was just improving, but now that I think about it, and have this thread to lead me to it, I don't think skill was the only factor. I didn't even think about getting a demo of it. Can you please post instructions on how to record a demo, so that next time I can record one?
Sorry if this post didn't help, but I just wanted to add my thoughts to it.
and i have observed this a few times, will work on a demo soon
For the person who has this bug, it will feel as though he's having a good day. Most attacks don't hit him and thus he manages to get away with doing things he'd usually die from. Would he consider whether he is bugged or not? Probably not. Who thinks about such a thing when doing very well? It is much easier to just take credit for 'playing well' or assume that you're just lucky. In a public game, this may be an annoyance for everybody else. One person has an unfair advantage, almost equivalent to turning on godmode whenever moving.
Let alone the unfair advantage, the end result is that games are affected and even turned around due to this bug. What about league games, where the stakes are higher than in public games? Even now, several matches in CAL and UGL have been affected by this bug. That means that teams are winning games with critical assists from bugged players. In the end, what you have is a lottery instead of a fair competitive game depending on skill.
If nobody steps up and provides demo/feedback about this bug, then we will all continue to play the lottery until we retire from NS. So far I only have a few demos and movie clips. I need public involvement in this, which is why I decided to post this thread in the first place. If nobody steps up, then crushing this bug will take much longer and maybe too long.
It's true that this bug is not so rare (some players really think it's a rare bug), but i think that what the devteam need is a way to make a player go in this state with a good probability instead of just demos where you see bugged players since the old vet post came the conclusion that with bug was not player related but server related.
The player notices that enemies are extremely hard to kill, often taking more damage than should be required to kill. This is all enemies, not just one or two in particular. I wouldn't remember this bug except I was a victim of it less than an hour before posting here. Quite often as skulk marines seem to require 3 bites or more to kill, and this is straight off the bat when marines have lvl0 armour.
How to spot the bug: it's pretty much the reverse of the afore mentioned bug. It's not uncommon either, i tend to look for choke or loss when i get this bug. Looking for the reverse symptoms of the above bug will help you diagnose the bug. For example marines taking 3 or 4 bites when you can safely know for sure that they have lvl0 armour, which is generally in the first minute of the game.
As a basic unit too you find that you are dying alot easier than usual, LMG's killing skulks in 5 shots etc. As marine it seems to be a harder bug to diagnose, because the only real evidence is that the marine class slows down in both strafing and forward/back movement. Being cornered, or not being able to jump over a skulk that is not jumping itself, is a good indicator of wether or not you are being effected by this bug or not. In the instant that you are bitten, you may notice that you stop and lose 100% of you're speed for the instant you are bitten. I am not sure of the speed loss as it's extremely hard to diagnose, but i am sure this bug exists. I have had lvl0 armour before and been left with 25 hp after 2 bites from a skulk, and tho i have no evidence ATM, i am sure i will soon collect enough to convince the NS community.
I am starting to think that both these bugs are larger mutations of the shotgun bug. After much playtesting in public servers I had decided that the shotgun bug was created by the client prediction system used by either NS or steam. You CAN see it in other mods, as a couple of days ago a friend awped someone in the head, and the enemy had lost only 3 hp from the shot. The shotgun bug was created, IMO and this is only a theory, by the client prediction refresh times being reduced to increase client side performance under steam. In 1.5 / HL / WON there was no real problem unless the source of the bug was net coding, so i assumed that the time between refresh on the client side prediction was too great to accurately measure damage done by weapons. Don't forget that client side prediction is corrected by the server, it's not 100% client side, otherwise the marine blood metamod plugin for 2.0 wouldn't have been possable. What I am thinking the cause of the bug may be, is the client's prediction is registering a shot, and 100ms later or so the server corrects this, seeing it as an error. There also lies an explanation for the "lagging hitbox" bug, as a leaping skulk can trick the cleint side prediction into projecting the model forward while the server is correcting only the hitbox. I eagerly await you're feedback for this, as it is a most vexing issue.
I think what was making the "sparkler" guns was the fact that 1 of 2 things or both were happening.
1. The player was suffering from Hitbox lag
2. The player was suffering from the Player Specific Hitbox Bug(PSHB)
When either of these were in effect the hitboxes were acting strangely. The hitboxe would be somewhere behind the player and when a shotgun was fired at him\her the pellets would hit the "invisible" wall surrounding the alien hitbox thus creating what was known as Sparkeler shotguns......
Abit off-topic but it is all relevent information.
I hope this has put into perspective the effects of the PSHB.
note: the sparkle effect was removed as of beta 4!!
The player notices that enemies are extremely hard to kill, often taking more damage than should be required to kill. This is all enemies, not just one or two in particular. I wouldn't remember this bug except I was a victim of it less than an hour before posting here. Quite often as skulk marines seem to require 3 bites or more to kill, and this is straight off the bat when marines have lvl0 armour.
How to spot the bug: it's pretty much the reverse of the afore mentioned bug. It's not uncommon either, i tend to look for choke or loss when i get this bug. Looking for the reverse symptoms of the above bug will help you diagnose the bug. For example marines taking 3 or 4 bites when you can safely know for sure that they have lvl0 armour, which is generally in the first minute of the game.
As a basic unit too you find that you are dying alot easier than usual, LMG's killing skulks in 5 shots etc. As marine it seems to be a harder bug to diagnose, because the only real evidence is that the marine class slows down in both strafing and forward/back movement. Being cornered, or not being able to jump over a skulk that is not jumping itself, is a good indicator of wether or not you are being effected by this bug or not. In the instant that you are bitten, you may notice that you stop and lose 100% of you're speed for the instant you are bitten. I am not sure of the speed loss as it's extremely hard to diagnose, but i am sure this bug exists. I have had lvl0 armour before and been left with 25 hp after 2 bites from a skulk, and tho i have no evidence ATM, i am sure i will soon collect enough to convince the NS community.
I am starting to think that both these bugs are larger mutations of the shotgun bug. After much playtesting in public servers I had decided that the shotgun bug was created by the client prediction system used by either NS or steam. You CAN see it in other mods, as a couple of days ago a friend awped someone in the head, and the enemy had lost only 3 hp from the shot. The shotgun bug was created, IMO and this is only a theory, by the client prediction refresh times being reduced to increase client side performance under steam. In 1.5 / HL / WON there was no real problem unless the source of the bug was net coding, so i assumed that the time between refresh on the client side prediction was too great to accurately measure damage done by weapons. Don't forget that client side prediction is corrected by the server, it's not 100% client side, otherwise the marine blood metamod plugin for 2.0 wouldn't have been possable. What I am thinking the cause of the bug may be, is the client's prediction is registering a shot, and 100ms later or so the server corrects this, seeing it as an error. There also lies an explanation for the "lagging hitbox" bug, as a leaping skulk can trick the cleint side prediction into projecting the model forward while the server is correcting only the hitbox. I eagerly await you're feedback for this, as it is a most vexing issue. <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd-->
If the effects that you are describing do, in fact, exist then you'll have even more trouble convincing people about them than I do. That is why demos are important here - the first step is to make people realize that a problem exists, then the next step is to find what is causing the problem, and then fix it. If people do not believe a problem exists, then there'll be no movement to try to find what causes it.
In response to what you have described in your post, I would be quite surprised if such an effect did exist. Try to get a demo of what you're describing to make sure that other factors are not at work.
I think what was making the "sparkler" guns was the fact that 1 of 2 things or both were happening.
1. The player was suffering from Hitbox lag
2. The player was suffering from the Player Specific Hitbox Bug(PSHB)
When either of these were in effect the hitboxes were acting strangely. The hitboxe would be somewhere behind the player and when a shotgun was fired at him\her the pellets would hit the "invisible" wall surrounding the alien hitbox thus creating what was known as Sparkeler shotguns......
Abit off-topic but it is all relevent information.
I hope this has put into perspective the effects of the PSHB.
note: the sparkle effect was removed as of beta 4!! <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd-->
Good hypothesis, but when shooting bugged players I have noticed that perhaps one or two bullets do hit from an entire lmg clip emptied right onto the model. Shooting behind doesn't seem to do much good most of the time. It is really strange. Also, even though the sparkler visual effects were removed, the sparkler effect itself is still there.
Keep a lookout at the bottom of my first post in this topic for status updates, as I am learning new things about the bugs every day that I spend playing with bugged players. Sometimes the players are nice enough to cooperate.
Last night I had this, I was killing marines as a skulk I really don't think I had any business killing.
I was even taking on 3 at a time with little bodily harm to myself.
I'm going to start demoing every round I play so I can watch them later for this issue.
However, I was playing on this server and playing pretty average, until my copy of steam borked when downloading a custom map, once I re-connected is when I started seeing this. So perhaps it not only resets ("Starts/Stops") itself after a server crash, but a client crash as well?
I've just recorded some demo's of myself playing, all short except for a long one that shows in detail the bug i described in a combat server. It's just normal playing, but the skulks were hitting us pretty hard so it won't be boring to watch. I need a place to put then though so i dunno what i should do, i'll try my tripod webby then i'll put a link here.
It's a very important bug to fix.
So I hope, the dev team see this bug as an important problem.
No I do not have any demo's yet but I intend to take some (and some just for fun <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html//emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif' /><!--endemo--> ).
I haven't looked closely to find Sarisel's address to send the demo's to but I will look over again for it. If it's not there I would appreciate you posting it so I know where to send my demo's to.
I don't know whether I have been a victim of the PSHB but I'm sure I have, like Sarisel said, people would just think they are having a good day or the opposite team is just not as good as you. And yes it is very hard to convince non-believers of this bug that it exists.
I'm not sure about one other thing though, that I would love to have some clarification on. I haven't checked other forums or this one for example either but I'm sure if I post it here someone will know the answer for me. If you are a marine and a skulk for example is really like stuck to you (I mean as close as possible to you) and you shoot him with a shotty, should he or should he not take damage? Because many times there have been skulks glued to me and I blast them and they take no damage although sometimes they do. I have heard some excuses/reasons but I just wanted to clarify. One of them was that if a skulks jumps on your chest then he's on your chests... where is your shotgun? He's pretty much standing on it so how are you going to hit him? <!--emo&:0--><img src='http://www.unknownworlds.com/forums/html//emoticons/wow.gif' border='0' style='vertical-align:middle' alt='wow.gif' /><!--endemo--> Although true these might not be accurate.
Anyways, I will try to get some demo's and send them to hopefully help will the analysis and fixing of the problem. Any clarification on the topic would be greatly appreciated and yes I know it's off topic. Thanks for the stats on the bug. Now I won't get so angry when I play NS and see these symptoms <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html//emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif' /><!--endemo-->
If the demos go public, I am confident that there will no longer be any disputes over the existence of this bug. With that out of the way, perhaps more ideas will come in to explain why what is happening is, in fact, happening.
It's the new "omg lag / hax / bs / hitboxes!"
Seriously though this is obviously something that needs to be fixed big time because I know sometimes it really could be the bug. Like 2 days ago when I went 44-0? Maybe. Thanks to Sarisel for investigating this problem so thoroughly.
[edit] Now that you got me interested, I feel like recording demos. Anyone know if it's possible to change playback speed? dem_speed is not implemented, methinks. Or applies to something else entirely.
What I need is for people to record demos featuring this bug and send them to me. The better the demos, the easier it will be to convince and raise awareness of this bug. Then, after I analyze the demos, I compile them into archives and publish them. At this step, I need hosts and mirrors. So far I have had two offers for which I am grateful.
There has been some valid discussion of the bug, but what I don't need is thread hijacking and unrelated replies.
<span style='color:red'><a href='http://s90175778.onlinehome.us/ns3.0/t0xseries.rar' target='_blank'>t0x series available here</a> Hosted by Wyzkrak.</span>
it depends on how long the demos are, but the 6 demos he has are a total of 11.0 MB compressed. anyways I think the t0xvswol.dem demo is shows enough to make anyone a believer in this 'issue'.
ive played since 1.04 and remember somthing about this.
Some demos dont work for me, have you got the same problem¿? They just crash the system
the dev team should probably be testing this already