<!--quoteo(post=2000272:date=Oct 29 2012, 06:38 PM:name=dushan)--><div class='quotetop'>QUOTE (dushan @ Oct 29 2012, 06:38 PM) <a href="index.php?act=findpost&pid=2000272"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->It was a simple update order issue - the view angles were updated after the gun was fired. This meant that every shot was using last frame's angle - making it super tricky to hit fast moving targets as your tracking was always a frame off. We found few other minor issues that will get fixed after 1.0 as they're a bit risky and the error is much smaller.<!--QuoteEnd--></div><!--QuoteEEnd--> Earlier in the beta, view angles were updated before the gun was fired, which had a similar, but reverse effect. If your view angle changed shortly after you fired, your shot wouldn't be fired until the next frame. Will this be fixed now?
So one frame difference caused the problem. 1 frame difference on the server doesn't seem like a lot.
1 frame difference pre b224 would have had a variable difference to players as the server processed as many frames as a player could handle. So people with 60-100 fps would have only been out by (60fps) 16.6ms - (100fps) 10ms.
But then they changed the server in b224 to have a fixed fps of 30 I believe, so suddenly those people who had fast PCs were getting an error of 33.3ms. Hence the noticeable hit reg problems.
This explains why some people didn't notice the problem, people with crappy PCs who were getting 30fps before b224 won't have noticed any difference, it was always crappy for them, it might have even improved if they were getting <30fps.
This also explains how I noticed a massive improvement myself when I got a new PC and went from 30fps to 60-100 fps. I felt it wasn't just improved visuals, hit reg was improved too.
I find it hard to believe 1 frame could cause that much problems, but I suppose when skulks are jumping around with celerity 33.3ms is probably quite noticeable.
I am looking forward to playing this new build tonight.
<!--quoteo(post=2000817:date=Oct 30 2012, 10:54 PM:name=_Necro_)--><div class='quotetop'>QUOTE (_Necro_ @ Oct 30 2012, 10:54 PM) <a href="index.php?act=findpost&pid=2000817"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Nice work. And thx to all the people who created evidence on video. Can you try to make a new video with 226 to show if it is fixed?<!--QuoteEnd--></div><!--QuoteEEnd-->
I can,i dont think its necessary though. 225 i was complaining and noticing hit reg in my first game. i havent complained at all since playing the new patch. Its defiantly alot better. I dont think its perfect yet tho.
<!--quoteo(post=2000819:date=Oct 30 2012, 05:55 AM:name=CheesyPeteza)--><div class='quotetop'>QUOTE (CheesyPeteza @ Oct 30 2012, 05:55 AM) <a href="index.php?act=findpost&pid=2000819"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->So one frame difference caused the problem. 1 frame difference on the server doesn't seem like a lot.
1 frame difference pre b224 would have had a variable difference to players as the server processed as many frames as a player could handle. So people with 60-100 fps would have only been out by (60fps) 16.6ms - (100fps) 10ms.
But then they changed the server in b224 to have a fixed fps of 30 I believe, so suddenly those people who had fast PCs were getting an error of 33.3ms. Hence the noticeable hit reg problems.
This explains why some people didn't notice the problem, people with crappy PCs who were getting 30fps before b224 won't have noticed any difference, it was always crappy for them, it might have even improved if they were getting <30fps.
This also explains how I noticed a massive improvement myself when I got a new PC and went from 30fps to 60-100 fps. I felt it wasn't just improved visuals, hit reg was improved too.
I find it hard to believe 1 frame could cause that much problems, but I suppose when skulks are jumping around with celerity 33.3ms is probably quite noticeable.
I am looking forward to playing this new build tonight.<!--QuoteEnd--></div><!--QuoteEEnd--> This is basically it, though 225 was the change to a fixed 30 FPS, 224 had a variable rate which was adjusted to minimize prediction errors.
Max do you know any way to test hit registration properly rather than just double checking the code? Perhaps something automated.
I don't like testing things by general consensus that things are better.
It seems a difficult thing to test, I know half-life had a interpolation error that wasn't found till about 10 years after release. I'd like to avoid that if possible.
Shouldn't it be possible to implement a console command that checks if you aim at a player-model. (not at the hitbox!) It would hit performance, but optional for tests it would be good to have a tool that checks and compares: - has the client detected a hit - has the server confirmed the hit - was the crosshair on the 3d model
When activated it would write into the console if a missmatch of one of the 3 happened.
<!--quoteo(post=2000891:date=Oct 30 2012, 09:12 AM:name=_Necro_)--><div class='quotetop'>QUOTE (_Necro_ @ Oct 30 2012, 09:12 AM) <a href="index.php?act=findpost&pid=2000891"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Shouldn't it be possible to implement a console command that checks if you aim at a player-model. (not at the hitbox!) It would hit performance, but optional for tests it would be good to have a tool that checks and compares: - has the client detected a hit - has the server confirmed the hit - was the crosshair on the 3d model
When activated it would write into the console if a missmatch of one of the 3 happened.<!--QuoteEnd--></div><!--QuoteEEnd-->
You probably should check against hitboxes, not the render model, hitboxes and render models might be different for good reasons, and the hitbox is the one that counts. It's easy to verify if your hitboxes are using the same animation state as the render model.
If you do 'was the crosshair on the 3d model' in code as a trace just before rendering, it would catch this recent case where the shot trace used the previous frame's view angles.
Or, for 'was the crosshair on the 3d model', you could use some image-based solution that renders hitboxes out to the frame buffer in individual colors and checks the color of the pixel at the centre of the crosshair. That would catch a few possible problems. Won't work for guns with spread, but I guess they are just modifications of the perfectly accurate case.
Do you really need this though? I don't think this is something that will keep breaking.
Comments
Earlier in the beta, view angles were updated before the gun was fired, which had a similar, but reverse effect. If your view angle changed shortly after you fired, your shot wouldn't be fired until the next frame. Will this be fixed now?
<a href="http://www.youtube.com/watch?v=bS-FY00mRn0&feature=related" target="_blank">http://www.youtube.com/watch?v=bS-FY00mRn0...feature=related</a>
1 frame difference pre b224 would have had a variable difference to players as the server processed as many frames as a player could handle. So people with 60-100 fps would have only been out by (60fps) 16.6ms - (100fps) 10ms.
But then they changed the server in b224 to have a fixed fps of 30 I believe, so suddenly those people who had fast PCs were getting an error of 33.3ms. Hence the noticeable hit reg problems.
This explains why some people didn't notice the problem, people with crappy PCs who were getting 30fps before b224 won't have noticed any difference, it was always crappy for them, it might have even improved if they were getting <30fps.
This also explains how I noticed a massive improvement myself when I got a new PC and went from 30fps to 60-100 fps. I felt it wasn't just improved visuals, hit reg was improved too.
I find it hard to believe 1 frame could cause that much problems, but I suppose when skulks are jumping around with celerity 33.3ms is probably quite noticeable.
I am looking forward to playing this new build tonight.
I can,i dont think its necessary though. 225 i was complaining and noticing hit reg in my first game. i havent complained at all since playing the new patch. Its defiantly alot better. I dont think its perfect yet tho.
1 frame difference pre b224 would have had a variable difference to players as the server processed as many frames as a player could handle. So people with 60-100 fps would have only been out by (60fps) 16.6ms - (100fps) 10ms.
But then they changed the server in b224 to have a fixed fps of 30 I believe, so suddenly those people who had fast PCs were getting an error of 33.3ms. Hence the noticeable hit reg problems.
This explains why some people didn't notice the problem, people with crappy PCs who were getting 30fps before b224 won't have noticed any difference, it was always crappy for them, it might have even improved if they were getting <30fps.
This also explains how I noticed a massive improvement myself when I got a new PC and went from 30fps to 60-100 fps. I felt it wasn't just improved visuals, hit reg was improved too.
I find it hard to believe 1 frame could cause that much problems, but I suppose when skulks are jumping around with celerity 33.3ms is probably quite noticeable.
I am looking forward to playing this new build tonight.<!--QuoteEnd--></div><!--QuoteEEnd-->
This is basically it, though 225 was the change to a fixed 30 FPS, 224 had a variable rate which was adjusted to minimize prediction errors.
I don't like testing things by general consensus that things are better.
It seems a difficult thing to test, I know half-life had a interpolation error that wasn't found till about 10 years after release. I'd like to avoid that if possible.
- has the client detected a hit
- has the server confirmed the hit
- was the crosshair on the 3d model
When activated it would write into the console if a missmatch of one of the 3 happened.
- has the client detected a hit
- has the server confirmed the hit
- was the crosshair on the 3d model
When activated it would write into the console if a missmatch of one of the 3 happened.<!--QuoteEnd--></div><!--QuoteEEnd-->
You probably should check against hitboxes, not the render model, hitboxes and render models might be different for good reasons, and the hitbox is the one that counts. It's easy to verify if your hitboxes are using the same animation state as the render model.
If you do 'was the crosshair on the 3d model' in code as a trace just before rendering, it would catch this recent case where the shot trace used the previous frame's view angles.
Or, for 'was the crosshair on the 3d model', you could use some image-based solution that renders hitboxes out to the frame buffer in individual colors and checks the color of the pixel at the centre of the crosshair. That would catch a few possible problems. Won't work for guns with spread, but I guess they are just modifications of the perfectly accurate case.
Do you really need this though? I don't think this is something that will keep breaking.