Fundamental Problem with Hit Detection Identified
Jaweese
Join Date: 2006-11-04 Member: 58356Members
Join Date: 2006-11-04 Member: 58356Members
<div class="IPBDescription">I tested it</div>There is a major bug affecting hit registration, however it is not a problem with the hit registration itself. It is a weapon activation timing problem not related to the intended melee attack delay. If you click Mouse1 and then <i>quickly</i> rotate your view, you will fire in some direction along your turning path, as if the attack has been delayed. In other words, <b><u>the weapon doesn't fire when/where you clicked</u></b>. This is most evident with gorge spit and fade blink because you can plainly see when the weapon activated.
This delay scales with client performance. This was tested by using a lan server on a different computer and dropping the server tick rate to 10 using hydras. Looking at the hydras to get a low fps, this effect was maximized. Far away from the hydras, where fps was high, the effect was minimized and similar to what I experienced on my own empty server (but still present).
This is something that should never happen, regardless of client performance, because FPS games should always precisely determine the timing of your click. <b><u>So it is not a performance problem</u></b>, because even with increased performance, this will still be a flaw affecting the feel of the game.
This delay scales with client performance. This was tested by using a lan server on a different computer and dropping the server tick rate to 10 using hydras. Looking at the hydras to get a low fps, this effect was maximized. Far away from the hydras, where fps was high, the effect was minimized and similar to what I experienced on my own empty server (but still present).
This is something that should never happen, regardless of client performance, because FPS games should always precisely determine the timing of your click. <b><u>So it is not a performance problem</u></b>, because even with increased performance, this will still be a flaw affecting the feel of the game.
Comments
This delay scales with client performance. This was tested by using a lan server on a different computer and dropping the server tick rate to 10 using hydras. Looking at the hydras to get a low fps, this effect was maximized. Far away from the hydras, where fps was high, the effect was minimized and similar to what I experienced on my own empty server (but still present).
This is something that should never happen, regardless of client performance, because FPS games should always precisely determine the timing of your click. <b><u>So it is not a performance problem</u></b>, because even with increased performance, this will still be a flaw affecting the feel of the game.<!--QuoteEnd--></div><!--QuoteEEnd-->
Wasn't this covered in a discussion about CPU Cores somewhere already? Posting system and performance specs would help validate your findings but i do believe you may find your findings where discussed somewhere in the modding sub-forum already.
I really didn't note any timing issues when i tried this and the culprit in my case was a combination of CPU and graphics Load leading to a delay in the animation tied to the attack rather than an input device delay. +1 for OcclusionGeometry. Lets hope this build sports the magic pill.
From looking through the code and how the game is designed, this sounds like something that would be caused by server performance.
If you want to see some legit results, you need to test from clients separate from the server.
from looking at the code:
the player orientation is handled clientside, meaning the orientation of the player won't be affected by what the server is doing.
but! the attacks are handled serverside, which is necessary for the information to be reliably communicated to all players.
Most likely what is happening goes along this time flow. let's imagine the client is going at twice the rate of the server, so every dash is a client tick and every double dash is a server tick.
--server does stuff
- client changes orientation,clicks,continues changing orientation
--at this point the server registers the click (gunfire) but at this point the orientation has changed from when the click actually happened. fires at new orientation
It changes the blink destination, so has nothing to do with an animation.
<!--quoteo(post=1850410:date=Jun 6 2011, 10:29 PM:name=6john)--><div class='quotetop'>QUOTE (6john @ Jun 6 2011, 10:29 PM) <a href="index.php?act=findpost&pid=1850410"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->if you're testing on a local server<!--QuoteEnd--></div><!--QuoteEEnd-->
The client and the server were on separate machines.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->This was tested by using a lan server on a different computer and dropping the server tick rate to 10 using hydras. Looking at the hydras to get a low fps, this effect was maximized. Far away from the hydras, where fps was high, the effect was minimized and similar to what I experienced on my own empty server (but still present).<!--QuoteEnd--></div><!--QuoteEEnd-->
Because that sounds like what you're describing, it takes time for the hits to register, because it takes time for the client to tell the server 'hey I shot' and the server to go 'hey so you did let's see what you hit' and then to tell the client 'ok you hit this, congrats!' and then the client goes 'ok I'll display that onscreen thanks sever!'.
You're going to have this problem with any game, honestly I think the idea that it tracks the mouse while this is going on is better than having it lag behind, at least it lets you compensate for lag by tracking your target as you will (presumably) be doing.
Of course it's also entirely possible that a lot of attacks deliberately just have a small delay, like bites/claws only hit when their animation is at the right point, or blink pauses a little to play a sound or begin an animation before blinking.
Now that you say it, I found the ulimate bug. Tell UWE that computers are faster just cummunicating with numbers instead of coding them to ASCII before. And they don't need to say "thanks" everytime, no one will be mad.. The lag should be gone immediatly!
You're clueless and you're spreading confusion.
Game loop on client goes like this:
1. sample input
2. apply input to local player(prediction)/receive data from network
3. render
Delay between key being pressed to prediction and rendering viewmodel affected by predicted attack shouldn't be higher than 1 client frame. If the loop is structured otherwise it's wrong (let's say order is 2, 1, 3 then it takes longer than it has to to see the effect of your actions).
Mouse is sampled by DirectInput (and HW) at around 125Hz (or more). That's 8 ms. Let's say FPS=30 (~30ms per frame from 1 to 3). Perfectly at t=0 mouse button is pressed and rotation is started. Frame 0 doesn't catch that. At t=8 (ms) it gets to DirectInput. Stuff gets predicted and drawn at t=30. At t=30 input is sampled and game notices mouse click. At t=40 it gets predicted. At t=60 viewmodel in attacking state gets drawn (anims can have idle periods before anything noticeable happens). As far as I rememeber GPU might accept frame to render but show it a bit later so that could add to delay but that's delay for rendering not for aiming/actions.
There's 1 weird hack that Half-life used and I can't exactly explain it: they sample mouse state after 1. once again before finishing prediction/rendering.
<!--quoteo(post=1850459:date=Jun 7 2011, 08:54 AM:name=MOOtant)--><div class='quotetop'>QUOTE (MOOtant @ Jun 7 2011, 08:54 AM) <a href="index.php?act=findpost&pid=1850459"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Mouse is sampled by DirectInput (and HW) at around 125Hz (or more). That's 8 ms. Let's say FPS=30 (~30ms per frame from 1 to 3). Perfectly at t=0 mouse button is pressed and rotation is started. Frame 0 doesn't catch that. At t=8 (ms) it gets to DirectInput. Stuff gets predicted and drawn at t=30. At t=30 input is sampled and game notices mouse click. At t=40 it gets predicted. At t=60 viewmodel in attacking state gets drawn (anims can have idle periods before anything noticeable happens). As far as I rememeber GPU might accept frame to render but show it a bit later so that could add to delay but that's delay for rendering not for aiming/actions.<!--QuoteEnd--></div><!--QuoteEEnd-->
Thanks, that makes sense. If the mouse click isn't noticed until the following frame is drawn, it would explain the correlation between client performance and the magnitude of the delay.
So at 30 fps and 33 ms per frame, there's a window of potentially 33 ms in which the order and timing of view rotation and mouse clicking doesn't matter. Yet in other games, such as half-life 1, even if I set fps_max to 20, I don't have this problem. The timing of clicking and view rotation is nearly perfect.
I believe it affects your click timing all the time, even when your view is stationary; however, it is easiest to reproduce and see when it's happening when you're moving your view quickly.
I replicated this bug and can confirm it is still present in build 178.
Hope it gets added into Build 184!