Shoot at a skulk with the lmg then count the time it takes for the flinch animation to play. See Skie's post in the <a href="http://www.unknownworlds.com/ns2/forums/index.php?showtopic=116894&st=0&start=0" target="_blank">other thread</a>. It took 263ms for the animation to play indicating a hit. I've seen it take 300ms at the most.
Also, even if it was the interp then something is not right, because in source I don't get a huge delay even with 500ms interp.
You didnt read my entire post did you? You most likely dont get that delay because source is not using the interp your setting. Some mods (im not sure what DOD:S uses) use interp ratio / update rate to calc interp, and ignore the interp value set. As for the delay being under 150ms I can only assume you might be possibly seeing delays in the initial animation triggering after the fire command is already sent to the server.
<!--quoteo(post=1915203:date=Mar 19 2012, 09:39 PM:name=Mkk_Bitestuff)--><div class='quotetop'>QUOTE (Mkk_Bitestuff @ Mar 19 2012, 09:39 PM) <a href="index.php?act=findpost&pid=1915203"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->You didnt read my entire post did you? You most likely dont get that delay because source is not using the interp your setting. Some mods (im not sure what DOD:S uses) use interp ratio / update rate to calc interp, and ignore the interp value set. As for the delay being under 150ms I can only assume you might be possibly seeing delays in the initial animation triggering after the fire command is already sent to the server.<!--QuoteEnd--></div><!--QuoteEEnd-->
I did read it. Source was using my interp settings. Look at the net graph, 500ms lerp. I set the interp_ratio and interp settings accordingly. If it wasn't using those settings then the gun floating in mid air for exactly 500ms wouldn't happen.
I understand that source uses your update packets and interp_ratio and I set them accordingly to get 500 interp for my tests.
I guess it's a design decision, you can update death asap, or keep it consistent with the interpolation delay. Max doesn't like the first solution but I don't really understand why. Source is a bit weird, it updates the kill notification asap but not the model.
Here is what I get with the rifle.
0ms: fire (slight change in the rifle model one frame before muzzle flash) 150ms : kill notification, running animation stops 150+84 ms : death animation/ragdoll
<!--quoteo(post=1915211:date=Mar 19 2012, 10:08 PM:name=Yuuki)--><div class='quotetop'>QUOTE (Yuuki @ Mar 19 2012, 10:08 PM) <a href="index.php?act=findpost&pid=1915211"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Source is a bit weird, it updates the kill notification asap but not the model.<!--QuoteEnd--></div><!--QuoteEEnd-->
The ragdoll and death animations happen as soon as the player dies. The blood splatter is delayed but you really don't notice it unless you have a very high setting. I don't know what you're trying to prove. Do you want me to post examples where I have 300ms delay?
<!--quoteo(post=1915198:date=Mar 19 2012, 10:29 PM:name=Wilson)--><div class='quotetop'>QUOTE (Wilson @ Mar 19 2012, 10:29 PM) <a href="index.php?act=findpost&pid=1915198"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Shoot at a skulk with the lmg then count the time it takes for the flinch animation to play. See Skie's post in the <a href="http://www.unknownworlds.com/ns2/forums/index.php?showtopic=116894&st=0&start=0" target="_blank">other thread</a>. It took 263ms for the animation to play indicating a hit. I've seen it take 300ms at the most.
Also, even if it was the interp then something is not right, because in source I don't get a huge delay even with 500ms interp.<!--QuoteEnd--></div><!--QuoteEEnd-->
I still dont see the problem... Your FPS plus the servers tickrate and your ping all play into this, at worst that can add a significant amount to the 150ms. If you only have 5 ping thats only eliminating one of the delays.
Also note that i believe source uses messages/events for kill notifications, which may be why you see that instantly.
<!--quoteo(post=1915149:date=Mar 19 2012, 02:28 PM:name=Max)--><div class='quotetop'>QUOTE (Max @ Mar 19 2012, 02:28 PM) <a href="index.php?act=findpost&pid=1915149"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I disagree. It's important to keep the state of the world consistent to prevent bugs.<!--QuoteEnd--></div><!--QuoteEEnd-->
Unnescessary delay in the transfer of vital information to the player looks like a bug to me.
Dead people don't suddenly spring back to life and they don't block bullets, so at a minimum you should make an exception for dying players.
Making an exception for flinch animations should also work and would definitely feel more responsive. The server should know what the client knew and when it knew as it will have a record of ACKs for the packets it has sent. This should allow the server to reconstruct the flinch animations as they were displayed on a particular client so that hitbox positions are reconstructed on the server.
Making an exception for decrementing the health and armor and playing hit-noises on a client as soon as the information is recieved would also go a long way to improve the feeling of combat.
In no game that I have some insight in how the netcode works has it ever been an elegant thing. It has always been a bag of tricks and kludges to try and hide latency and make the game feel more responsive.
<!--quoteo(post=1915227:date=Mar 19 2012, 10:44 PM:name=Mkk_Bitestuff)--><div class='quotetop'>QUOTE (Mkk_Bitestuff @ Mar 19 2012, 10:44 PM) <a href="index.php?act=findpost&pid=1915227"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I still dont see the problem... Your FPS plus the servers tickrate and your ping all play into this, at worst that can add a significant amount to the 150ms. If you only have 5 ping thats only eliminating one of the delays.
Also note that i believe source uses messages/events for kill notifications, which may be why you see that instantly.<!--QuoteEnd--></div><!--QuoteEEnd-->
Even when the server has no buildings etc. and the tickrate is stable(ish) it still happens. The blood is rendered right away but the time it takes for the hit to register and play the animation is waaay too long. If it were just low FPS then everything would be delayed.
In source it's not just the message that comes up almost instantly. The player actually dies and your hit actually registers that fast!
Even if it were the interp setting, then I think that it is not working correctly or there is a problem with it, as stated many times before, in source the interpolation does not delay hits registering.
Even if it is only an animation issue and the hits are actually registering faster then it is still a big problem. It makes the entire game feel very laggy and unresponsive. Just improving this would make the game feel 10 times better.
Source may trigger animations based off the message, so its hard 2 say.
As for the added delays, it looks like spark triggers the blood/notification correctly, it may just be the animation update that is delayed. That may be because it takes an additional tick or two for that to trigger, i do not know how spark handles that.
<!--quoteo(post=1915234:date=Mar 19 2012, 10:59 PM:name=Mkk_Bitestuff)--><div class='quotetop'>QUOTE (Mkk_Bitestuff @ Mar 19 2012, 10:59 PM) <a href="index.php?act=findpost&pid=1915234"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->As for the added delays, it looks like spark triggers the blood/notification correctly, it may just be the animation update that is delayed. That may be because it takes an additional tick or two for that to trigger, i do not know how spark handles that.<!--QuoteEnd--></div><!--QuoteEEnd-->
That is because the blood is rendered client side, just like bullet sparks in the wall etc. There's no need to wait for a response from the server for things like that.
Have you read this? <a href="https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking#Entity_interpolation" target="_blank">https://developer.valvesoftware.com/wiki/So...y_interpolation</a>
If I understand this right, than the interpolation (of 150ms right now) <u>is</u> the cause of your observations. Plus the time your "firing"-command needs to transfer to the server + the time the server needs to verify that you have hit the target (normaly the next tick) + the time the server needs to transfer the packet with "target killed" to you.
Be careful when testing. Don't use bots (= client side computed and maybe without the interpolation which is only necessary on a real player).
Even if you are right and it is that way by design, it is still a big problem. The same behaviour is not seen in TF2 even with the default interpolation of 100ms. Having a huge delay of 300ms before a kill registers feels very unresponsive. I don't know what is causing it, I'm just trying to bring it up and get it acknowledged as a problem.
<!--quoteo(post=1915435:date=Mar 20 2012, 03:50 PM:name=Wilson)--><div class='quotetop'>QUOTE (Wilson @ Mar 20 2012, 03:50 PM) <a href="index.php?act=findpost&pid=1915435"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Even if you are right and it is that way by design, it is still a big problem.<!--QuoteEnd--></div><!--QuoteEEnd--> You are right. But if I'm right, than the devs know the cause = slow server tick rate and the interp. that will be scaled down on release.
<!--quoteo(post=1915435:date=Mar 20 2012, 03:50 PM:name=Wilson)--><div class='quotetop'>QUOTE (Wilson @ Mar 20 2012, 03:50 PM) <a href="index.php?act=findpost&pid=1915435"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->The same behaviour is not seen in TF2 even with the default interpolation of 100ms.<!--QuoteEnd--></div><!--QuoteEEnd--> Are you sure? No bots involved? Lower delay than 100ms? Do you know if they compute the hits completely server side or is it on both sides and the server only corrects the wrong computed packets from the client?
<!--quoteo(post=1915439:date=Mar 20 2012, 03:00 PM:name=_Necro_)--><div class='quotetop'>QUOTE (_Necro_ @ Mar 20 2012, 03:00 PM) <a href="index.php?act=findpost&pid=1915439"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->You are right. But if I'm right, than the devs know the cause = slow server tick rate and the interp. that will be scaled down on release.<!--QuoteEnd--></div><!--QuoteEEnd--> I don't think it's as simple as that. Since that would mean interpolation is working differently than source.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->Are you sure? No bots involved? Lower delay than 100ms? Do you know if they compute the hits completely server side or is it on both sides and the server only corrects the wrong computed packets from the client?<!--QuoteEnd--></div><!--QuoteEEnd--> Yes, I have tried this on a live server in multiple source games. The hits are completely server side, not predicted on the client (or else you would get guys coming back to life). It only takes a little over the time for you to receive the packet for the hit to register. if you play with 500 ping then you will notice a big delay like you would expect. NS2 has a big delay regardless of ping.
I really don't have a full understanding of how interp on the source engine works. Perhaps it updates any damage that you deal to the enemy right away, so that you don't get that laggy feeling (just the same way as you move right away even though it takes time for you to move on the server). I don't know. All I know is that it feels responsive to me as the player and currently NS2 does not.
IronHorseDeveloper, QA Manager, Technical Support & contributorJoin Date: 2010-05-08Member: 71669Members, Super Administrators, Forum Admins, Forum Moderators, NS2 Developer, NS2 Playtester, Squad Five Blue, Subnautica Playtester, Subnautica PT Lead, Pistachionauts
Where's Max? We need him to answer this further as its not clear if this is intentional or a bug, considering how he said its the same as source but it actually isn't, as wilson has demonstrated. People discussing this or debating it in this thread is not assisting wilson in getting his response, either. Goodluck wilson, I'm very interested in the outcome of this thread..
LOL at this thread. This is not interp. The engine that is simply taking way too long to calculate basic client server interactions. Read the thread he linked to. Jeez.
I think it was clear it is intentional. See what he said about updating death asap :
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->I disagree. It's important to keep the state of the world consistent to prevent bugs.<!--QuoteEnd--></div><!--QuoteEEnd-->
I did some recordings on a real server (ping ~50) and I get around 150ms between shot and death notification, and between 100 and 250ms between death notification and death animation. It seems particularly bad/visible when skulks are walking on a wall, the animation freeze for a while and they suddenly pop out the wall.
@Flounder, interpolation explains the 150ms between shot and death notification.
Yukki, explain why it is sometimes less than 150ms then?
I guess it's probably just poor server performance. Server doesn't send you the update packet for +100ms because it's too busy and therefore it takes ages to update. I think some of the animations seem slow/delayed as well which makes it feel more unresponsive.
swalkSay hello to my little friend.Join Date: 2011-01-20Member: 78384Members, Squad Five Blue
edited March 2012
<!--quoteo(post=1915855:date=Mar 21 2012, 12:55 PM:name=Yuuki)--><div class='quotetop'>QUOTE (Yuuki @ Mar 21 2012, 12:55 PM) <a href="index.php?act=findpost&pid=1915855"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->>Yukki, explain why it is sometimes less than 150ms then?
Most likely explanation is that there is a ~50ms delay in the firing animation.<!--QuoteEnd--></div><!--QuoteEEnd--> Could very well be an animation issue, we have seen alot of these lately. Like; not being able to shoot pistol the moment you land after a jump, and being able to fire your shotgun faster if you're moving forward. Could some of the delays from this thread have something to do with animations?
Comments
Also, even if it was the interp then something is not right, because in source I don't get a huge delay even with 500ms interp.
I did read it. Source was using my interp settings. Look at the net graph, 500ms lerp. I set the interp_ratio and interp settings accordingly. If it wasn't using those settings then the gun floating in mid air for exactly 500ms wouldn't happen.
I understand that source uses your update packets and interp_ratio and I set them accordingly to get 500 interp for my tests.
Here is what I get with the rifle.
0ms: fire (slight change in the rifle model one frame before muzzle flash)
150ms : kill notification, running animation stops
150+84 ms : death animation/ragdoll
<img src="http://i.imgur.com/yi72A.jpg" border="0" class="linked-image" />
<img src="http://i.imgur.com/8PTMd.jpg" border="0" class="linked-image" />
<img src="http://i.imgur.com/CSpj3.jpg" border="0" class="linked-image" />
The ragdoll and death animations happen as soon as the player dies. The blood splatter is delayed but you really don't notice it unless you have a very high setting. I don't know what you're trying to prove. Do you want me to post examples where I have 300ms delay?
Also, even if it was the interp then something is not right, because in source I don't get a huge delay even with 500ms interp.<!--QuoteEnd--></div><!--QuoteEEnd-->
Add your ping to the 150ms delay?
Also note that i believe source uses messages/events for kill notifications, which may be why you see that instantly.
Unnescessary delay in the transfer of vital information to the player looks like a bug to me.
Dead people don't suddenly spring back to life and they don't block bullets, so at a minimum you should make an exception for dying players.
Making an exception for flinch animations should also work and would definitely feel more responsive. The server should know what the client knew and when it knew as it will have a record of ACKs for the packets it has sent. This should allow the server to reconstruct the flinch animations as they were displayed on a particular client so that hitbox positions are reconstructed on the server.
Making an exception for decrementing the health and armor and playing hit-noises on a client as soon as the information is recieved would also go a long way to improve the feeling of combat.
In no game that I have some insight in how the netcode works has it ever been an elegant thing. It has always been a bag of tricks and kludges to try and hide latency and make the game feel more responsive.
Also note that i believe source uses messages/events for kill notifications, which may be why you see that instantly.<!--QuoteEnd--></div><!--QuoteEEnd-->
Even when the server has no buildings etc. and the tickrate is stable(ish) it still happens. The blood is rendered right away but the time it takes for the hit to register and play the animation is waaay too long. If it were just low FPS then everything would be delayed.
In source it's not just the message that comes up almost instantly. The player actually dies and your hit actually registers that fast!
Even if it were the interp setting, then I think that it is not working correctly or there is a problem with it, as stated many times before, in source the interpolation does not delay hits registering.
Even if it is only an animation issue and the hits are actually registering faster then it is still a big problem. It makes the entire game feel very laggy and unresponsive. Just improving this would make the game feel 10 times better.
As for the added delays, it looks like spark triggers the blood/notification correctly, it may just be the animation update that is delayed. That may be because it takes an additional tick or two for that to trigger, i do not know how spark handles that.
That is because the blood is rendered client side, just like bullet sparks in the wall etc. There's no need to wait for a response from the server for things like that.
If I understand this right, than the interpolation (of 150ms right now) <u>is</u> the cause of your observations. Plus the time your "firing"-command needs to transfer to the server + the time the server needs to verify that you have hit the target (normaly the next tick) + the time the server needs to transfer the packet with "target killed" to you.
Be careful when testing. Don't use bots (= client side computed and maybe without the interpolation which is only necessary on a real player).
You are right. But if I'm right, than the devs know the cause = slow server tick rate and the interp. that will be scaled down on release.
<!--quoteo(post=1915435:date=Mar 20 2012, 03:50 PM:name=Wilson)--><div class='quotetop'>QUOTE (Wilson @ Mar 20 2012, 03:50 PM) <a href="index.php?act=findpost&pid=1915435"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->The same behaviour is not seen in TF2 even with the default interpolation of 100ms.<!--QuoteEnd--></div><!--QuoteEEnd-->
Are you sure? No bots involved? Lower delay than 100ms? Do you know if they compute the hits completely server side or is it on both sides and the server only corrects the wrong computed packets from the client?
I don't think it's as simple as that. Since that would mean interpolation is working differently than source.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->Are you sure? No bots involved? Lower delay than 100ms? Do you know if they compute the hits completely server side or is it on both sides and the server only corrects the wrong computed packets from the client?<!--QuoteEnd--></div><!--QuoteEEnd-->
Yes, I have tried this on a live server in multiple source games. The hits are completely server side, not predicted on the client (or else you would get guys coming back to life). It only takes a little over the time for you to receive the packet for the hit to register. if you play with 500 ping then you will notice a big delay like you would expect. NS2 has a big delay regardless of ping.
I really don't have a full understanding of how interp on the source engine works. Perhaps it updates any damage that you deal to the enemy right away, so that you don't get that laggy feeling (just the same way as you move right away even though it takes time for you to move on the server). I don't know. All I know is that it feels responsive to me as the player and currently NS2 does not.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->I disagree. It's important to keep the state of the world consistent to prevent bugs.<!--QuoteEnd--></div><!--QuoteEEnd-->
I did some recordings on a real server (ping ~50) and I get around 150ms between shot and death notification, and between 100 and 250ms between death notification and death animation. It seems particularly bad/visible when skulks are walking on a wall, the animation freeze for a while and they suddenly pop out the wall.
@Flounder, interpolation explains the 150ms between shot and death notification.
I guess it's probably just poor server performance. Server doesn't send you the update packet for +100ms because it's too busy and therefore it takes ages to update. I think some of the animations seem slow/delayed as well which makes it feel more unresponsive.
Most likely explanation is that there is a ~50ms delay in the firing animation.
Most likely explanation is that there is a ~50ms delay in the firing animation.<!--QuoteEnd--></div><!--QuoteEEnd-->
Could very well be an animation issue, we have seen alot of these lately.
Like; not being able to shoot pistol the moment you land after a jump, and being able to fire your shotgun faster if you're moving forward.
Could some of the delays from this thread have something to do with animations?