To the devs: Any progress on the 250ms delay?
Wilson
Join Date: 2010-07-26 Member: 72867Members
Join Date: 2010-07-26 Member: 72867Members
Hey, I just wanted to ask the devs if you've made in progress or know what's causing the huge delay in spark? Skie brought it up in a thread last week but I didn't see any official response to it. It's the most annoying thing for me and I really can't play with it. I know you are *always* working on performance but I wanted to know about this particular issue. It makes the whole game feel like you are playing with 250+ ping.
I don't know if it's the exact same issue, but I have noticed that if you bite a wall or building, the sound won't play right away. There is a big delay. So if you bite the wall as a skulk and then you move away, you actually hear the bite sound at the location later. It makes it feel very unresponsive.
I don't know if it's the exact same issue, but I have noticed that if you bite a wall or building, the sound won't play right away. There is a big delay. So if you bite the wall as a skulk and then you move away, you actually hear the bite sound at the location later. It makes it feel very unresponsive.
Comments
Everything else shouldn't have any delay.
Go to a local server. Shoot a skulk with a shotgun, and it'll take 250ms for it to die. It most other games it's much less than that. Also, bite the wall as a skulk and then move away, you hear the bite sound after you have moved away from the wall, as if it was another skulk or something.
The reason for this is, deaths are not predicted ( i think its pretty much the only thing in the game that is not predicted). This is so that the situation where on your computer the enemy dies, and then suddenly comes to live again, never happens. If he is dead, he is dead. The price you pay for this is a delay +- as big as you ping value.
For me thats totaly acceptable. For others it might not be. Saying that it makes it impossible to play is a "little" exagerated. My guess is that in the final version, perhaps there will be a command to enable client side prediction for deaths, who knows, perhaps it even becomes default? I wouldn't worry too much about it yet anyway.
It's not just deaths either. It's any time you deal damage to the enemy or a building.
In ns1 this problem didn't exist.
It's not to do with interp as I said because sometimes it is less than 150ms. If it were the interp then it would be constantly equal or slightly greater than 150ms. Even if it were the interp then there would be a serious problem with it. In source the interp doesn't delay the time it takes for a hit/death to register. You can play with 100ms interp in TF2 and CSS and you wouldn't even notice.
The delay is a huge problem and it makes everything feel very unresponsive. Even if FPS and server performance are brilliant it wouldn't matter if this issue was still present.
Please don't speculate if you don't know what you're talking about. This is why I asked for a dev response, as only they can say what's really going on.
According to vavle 100ms interpolation is a bit outdated :
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->Interpolation adds artificial latency to a player's view of the game world, and as such should be kept to the barest minimum. Unfortunately Valve's games still default to a minimum interpolation delay ("lerp") of 100ms, a value tuned for the era of dial-up modems!<!--QuoteEnd--></div><!--QuoteEEnd-->
Shouldn't the interpolation delay be just bigger than the time between two server ticks, 33 ms (plus ping?)?
Interpolation time is normally set at twice the time it takes for you to receive 1 packet from the server. Since in ns2 you get 20 packets a second, that's 50ms per packet. Double that and you get the 100ms that Max has said.
It's 100ms so that if 1 packet is dropped your computer still has 2 packets to interpolate between. In source games you can use the command cl_interp_ratio to decrease this to the time between 1 packet (50ms). This means if drop a packet though the interpolation won't work correctly. It's not as much of a big deal if you're playing on a 60 tickrate server though, as the time between each packet is so short the movement will still appear smooth. Since in ns2 you are only getting 20 updates a second (and often less) I suspect it would be very jittery without interpolation.
That quote you posted is a little dated as valves latest game, cs:go has interp of 30ms as default. In older source games the default packets per second was 20 as well - that is pretty outdated now in source, but I guess it will be standard for spark. Perhaps it will be increased to 30 once server performance improves but I wouldn't expect higher tickrate servers.
Again though, I don't think it's anything to do with interp. As much as I would like ns2 to have less interp and higher tickrate servers, I really think this is different issue.
theres a good 200 ms delay to receiving feedback on your hits for players or structures - this is huge, and important, and needs to be tightened up - it gives the game a "beta" feel.. trust me once its gone things will just feel smoother and responsive in a notable way.
+1 for a MAX response! :)
If you test it (net_lag 300) you would see that the delay does scale with ping, and plateau around 100ms when ping goes to zero.
when i say latency does not factor i am referencing that thread where he started a LISTEN SERVER on his own machine <20ms latency and he was still getting 175-250 ms delays for structure and player dmg feedback.
compare this to any other FPS (as he did in that thread) and you will surely notice the gaping difference.
but somehow i feel that you knew thats how i meant it already...? especially after people are posting about their cable connection in this thread, as if that is the issue?? (your point was interesting to note, however)
In my understanding, it's due to interpolation, you need a delay in order to do interpolation, no ?
>compare this to any other FPS (as he did in that thread) and you will surely notice the gaping difference.
Well you need to compare with similar server settings, 20 update, 30 tick rate, 150 interpolation, otherwise it's not really useful.
Anyway, I'm not saying that there is no problem, but I'm not really convinced that ~100ms delay is unexpected given the server performance/settings.
AFAIK interpolation does not delay the time it takes for hits to register anyway. It's only the movement it smooths out.
100ms delay is very unexpected. It doesn't matter what your interp is. Go try the same thing in ns1 and you will see the massive difference.
This is a problem with the engine taking a very long amount of time to calculate hits. It's not to do with the network settings.
Interpolation is for continous variables(e.g. position, rotation). If you are interpolating discrete events like deaths it is surely a mistake and not intentional.
Ragdolls do not interact with the gameplay in any way; they do not need to be networked, it does not matter if they end up in slightly different places on different clients.
everyone here gets that this is a work in progress, ofc, some of us just feel that this is a major issue and the OP would like an acknowledgment from the devs obviously based on his title of his thread :)
you are probably right though that it is based on server performance instead of it being a bug or intentional.
<!--quoteo(post=1911830:date=Mar 10 2012, 04:23 AM:name=matso)--><div class='quotetop'>QUOTE (matso @ Mar 10 2012, 04:23 AM) <a href="index.php?act=findpost&pid=1911830"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Unfortunately, I don't know if the discrepancies shown is due to bugs in the tool or in the code ... but at least there are discrepancies to explain.<!--QuoteEnd--></div><!--QuoteEEnd-->
That's a good argument, it's true that events like should be updated asap.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->Go try the same thing in ns1 and you will see the massive difference.<!--QuoteEnd--></div><!--QuoteEEnd-->
Anyone knows how to set up a fair comparison (commands, etc..) ?
First frame before I shoot:
<img src="http://i.imgur.com/3wpsm.jpg" border="0" class="linked-image" />
I shoot, client side blood is shown on enemies face instantly:
<img src="http://i.imgur.com/2E2C0.jpg" border="0" class="linked-image" />
Kill is registered 17ms after shooting (perhaps less, limited by my video recording framerate)
<img src="http://i.imgur.com/bCy7E.jpg" border="0" class="linked-image" />
500ms later, blood splatter is rendered and gun drops to the floor (was frozen in mid air) - This is the 500ms interp effect, as you see, it does not delay the kill at all:
<img src="http://i.imgur.com/agBha.jpg" border="0" class="linked-image" />
With these settings I did get very bad reg and strange things happen like the guns floating in mid air after killing the player, but it does not effect the time for hits/kills to register. This issue in ns2 is nothing to do with interp and if it is then it's not working correctly.
I disagree. It's important to keep the state of the world consistent to prevent bugs.
I don't have time to go through each one, but there are a lot of incorrect statements in this thread. The client will impose a 150ms delay on everything to allow for interpolation and deal more gracefully with dropped packets or low server rate. This is exactly how the Source engine works, though the number varies (CS:30 uses 30ms, TF2 uses 100ms). We use 150ms because we've found that this value works better based on the current state of server performance. We will reduce we continue to work on server performance.
In the source engine even with 500ms interp my kills register in 17ms. As shown above.
i wonder if max means the client adds 150ms to <b>everything</b> (hitreg) so that the world appears smoother/synchronized (so that the helmet and gun drop at the same time as the hitreg.) -<u> in lieu of fast 17ms hit/kill feedback?</u>
if thats the case i cant see why you still wouldn't prioritize things as source does, such as kill registration, like you point out Wilson? to avoid dead bodies from coming back to life? does that ever happen in source even with 300 ping? i cant recall
This how I understand it. We still need to explain why we have less than 150ms death on our recordings, it might be due to firing animation delay, of maybe the recording itself (i was recording at 50fps).
<!--quoteo(post=1915160:date=Mar 19 2012, 08:45 PM:name=ironhorse)--><div class='quotetop'>QUOTE (ironhorse @ Mar 19 2012, 08:45 PM) <a href="index.php?act=findpost&pid=1915160"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->if thats the case i cant see why you still wouldn't prioritize things as source does, such as kill registration, like you point out Wilson? to avoid dead bodies from coming back to life? does that ever happen in source even with 300 ping? i cant recall<!--QuoteEnd--></div><!--QuoteEEnd-->
As soon as you receive the death message from the server, you display the kill, stop interpolating and play the ragdoll on the client ? Since dead players can't do anything it shouldn't be a problem.
That screenshot was from a listen server, but I also tested it on an actual server with 20ping and real players and it is the same result. The kills register within a very short period of time. Much less than 100ms.
I don't know why everyone is talking about interp though. It's clearly not interp if the delay is sometimes under 150ms. There is some other problem here. I hope Max doesn't think this whole thread was a whine at having 150ms interp settings. I really think this is a significant problem with spark at the moment. Sometimes it takes 300ms before a skulk displays the flinch animation to indicate it took damage. This is a huge problem for an fps game.
Max just said everything was delayed by 150ms for interpolation. He should know.
Under which conditions do you get 300 ? I got 140 at worse, but I did only 4-5 recordings.