Delayed Damage
NA1
Join Date: 2012-11-29 Member: 173677Members, Reinforced - Shadow
Join Date: 2012-11-29 Member: 173677Members, Reinforced - Shadow
<div class="IPBDescription">Ummm, wtf?</div>Why, exactly, is damage done to aliens occasionally delayed?
Example: I'm a lerk attacking an RT, and a marine shows up with an LMG. I fly around the corner to safety. I still take damage from that marine for up to a <u><i><b>FULL SECOND AFTER</b></i> </u>flying around the corner. I see this on every server, every alien, but usually only with LMGs.
Uh, this isn't 1998. There's no excuse for the damage not being nigh instant when my latency is < 80 ms. I can't measure threat if I can't tell when I'm taking damage vs. when I'm taking delayed damage.
Example: I'm a lerk attacking an RT, and a marine shows up with an LMG. I fly around the corner to safety. I still take damage from that marine for up to a <u><i><b>FULL SECOND AFTER</b></i> </u>flying around the corner. I see this on every server, every alien, but usually only with LMGs.
Uh, this isn't 1998. There's no excuse for the damage not being nigh instant when my latency is < 80 ms. I can't measure threat if I can't tell when I'm taking damage vs. when I'm taking delayed damage.
Comments
Example: I'm a lerk attacking an RT, and a marine shows up with an LMG. I fly around the corner to safety. I still take damage from that marine for up to a <u><i><b>FULL SECOND AFTER</b></i> </u>flying around the corner. I see this on every server, every alien, but usually only with LMGs.
Uh, this isn't 1998. There's no excuse for the damage not being nigh instant when my latency is < 80 ms. I can't measure threat if I can't tell when I'm taking damage vs. when I'm taking delayed damage.<!--QuoteEnd--></div><!--QuoteEEnd-->
This is due to the lag compensation in the netcode. On their screen you weren't around the corner yet. If the interpolation value is reduced this should lessen the problem. However this value isn't a cvar that the server admins have access to without a mod currently. Hopefully as server performance improves UWE will open up access to this variable or just drop it down at the very least.
If someone could confirm this, is interpolation still set to 150ms or did they reduce it recently?
If someone could confirm this, is interpolation still set to 150ms or did they reduce it recently?<!--QuoteEnd--></div><!--QuoteEEnd-->
I'm fairly sure you're not correct here. Interpolation is the amount of past game data the server stores, Lowering the interpolation data will just make the game increasingly unplayable for anyone who's latency goes above the interpolation figure. Having a very high interpolation figure on the server should not hurt hit detection for any of the players on the server, it simply hurts server performance (because lots of extra data is stored in RAM).
Also, extra data is stored in servers already to compensate for large player internet latencies. It has to look back in time to calculate shots. I'm not sure how much time it is, but I doubt dropping the interp to even 33ms would matter.
Lastly, interp is only one part of the total latency it takes for you to leave around a corner for the other player. Things add up.
Also, extra data is stored in servers already to compensate for large player internet latencies. It has to look back in time to calculate shots. I'm not sure how much time it is, but I doubt dropping the interp to even 33ms would matter.
Lastly, interp is only one part of the total latency it takes for you to leave around a corner for the other player. Things add up.<!--QuoteEnd--></div><!--QuoteEEnd-->
Traditionally, The server side interp variable simply delimits how long interpolation data is stored for. So if you have interp of 150ms, then every action taken on the server by every player, once the server receives the action report, is stored for 150ms. Therefore, when my server sends my client the current game state at the standard ticrate (30 times per second in NS2), it goes into the interp pool, pulls the data that matches my last known latency, and sends me back the historical data of whatever happened however much time in ping I am behind the server. This works via tickrate. So if the server tickrate is 30 and interp is 150ms, the server should be storing 5 full records of historical game state to send to players when it's requested, determining which of those game states is closest to the latency each player is experiencing. This is one of the reasons why increasing ticrate would be dangerous for the RAM of a server in NS2 (cysts are part of game state, so NS2 game states are pretty big, doubling tic rate doubles the amount of RAM needed to store historical game states)
If your latency is higher than the servers interp setting, you simply pull the last known interpolated game state, and your client is responsible for dealing with the rest. Meaning, if my latency is 300, and the interp is 150, Too bad, I get game states at the time stamp 150ms in the past. If I want to hit things I better lead their shots where they will be 150ms from where I'm actually seeing them.
If your latency is lower than the server interp value, it shouldn't effect you at all that interp is "high", unless the server is overloaded with too many game states in memory and drops in tic rate for some reason.
The real big trade off... if we halfed the interp, in theory we could handle higher server tickrates. That is, assuming NS2 handles interp via the standard interp algorithm. However, anyone playing on a server with a ping higher than the interp would have some weird issues, they'd be guessing where opponents actually were, the game states they would see would never be accurate historical game states.
It doesn't make the game unplayable, but I cannot recall any game (shooters specifically) where I've experienced this (or not often enough, and apparent enough to notice).
It is a frustrating situation, because it hinders the ability to play, and gives the impression of being randomly penalized.
you two are discussing two different topics, or mix-using terms
interpolation and lag compensation are different.
<a href="https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking" target="_blank">https://developer.valvesoftware.com/wiki/So...ayer_Networking</a>
It doesn't make the game unplayable, but I cannot recall any game (shooters specifically) where I've experienced this (or not often enough, and apparent enough to notice).
It is a frustrating situation, because it hinders the ability to play, and gives the impression of being randomly penalized.<!--QuoteEnd--></div><!--QuoteEEnd-->
If you think NS2 is the only game with this problem, go play some AAA Battlefield: Bad Company 2 or BF3! It's alot worse in those games if you ask me.
I agree though, it can be very frustrating. Especially because it sometimes reduces the TTK and leaves you no option to react when under fire. This happens on the Alien as well as the Marine side, getting killed instantly by an LMG early game or by just one skulk bite (as it seems) is just plain annoying.
It doesn't make the game unplayable, but I cannot recall any game (shooters specifically) where I've experienced this (or not often enough, and apparent enough to notice).
It is a frustrating situation, because it hinders the ability to play, and gives the impression of being randomly penalized.<!--QuoteEnd--></div><!--QuoteEEnd-->
It also harms skillful play because you can't safely predict whether you can escape or not.
Btw, other game do have this issue, but I don't think I've seen a game that is as bad as NS2. Closest that comes to midn is tf2 on a 200 ping server, but even then it's much better then in NS2. (Not to mention in ns2 it seems to depend on the OTHER player and not so much on your self. I.e. high pingers getting impossible kills from your pov, like shooting the air infront of them and hitting you behind them)
I've also seen it from the Kharaa point of view. Marines have had a shocking drop in perceived accuracy. It's harder to tell if you only play aliens, but switching sides each round and having played matches at launch where the hit detection seemed perfect, it's obvious that something is very wrong. I love this game, but this is starting to ruin the fun for me.
But yeah, this delay is terrible. Reminds me of playing old games on dial-up access! Come on UWE ..
I agree though, it can be very frustrating. Especially because it sometimes reduces the TTK and leaves you no option to react when under fire. This happens on the Alien as well as the Marine side, getting killed instantly by an LMG early game or by just one skulk bite (as it seems) is just plain annoying.<!--QuoteEnd--></div><!--QuoteEEnd-->
honestly bad company 2 wasnt that bad, the reg is actually better imo. bc2 was a great game even if you couldnt prone.
now bf3 is outright terrible.
I've also seen it from the Kharaa point of view. Marines have had a shocking drop in perceived accuracy. It's harder to tell if you only play aliens, but switching sides each round and having played matches at launch where the hit detection seemed perfect, it's obvious that something is very wrong. I love this game, but this is starting to ruin the fun for me.<!--QuoteEnd--></div><!--QuoteEEnd-->
I have a sneaking suspicion that NS2 is misbehaving somewhat badly when it comes to lost packet transfers, so if you shot a skulk 3 times on your client, and the packet that tells the server that this happened never gets there, the game never figures out there was a discrepancy. This is really bad policy because lost packets are what most internet based routing systems use to calibrate their traffic control systems. They will intentionally drop packets at random for just that reason.
Servers with lower ping feel much more meaty in how they reg to me than servers with higher ping (which is normal to some degree, but it's to a higher level than just the expected curve). I'm thinking more hops in the traceroute and NS hitreg stops adapting to the situation as nicely.
I'm playing a lot on a server based in Vancouver, and I always feel a bit godly playing there, where as when I play on LinuxMonster, which is based on the east coast, I feel much more anemic. Like quite substantially so.
Delay of a quarter second should be very normal, delay of longer than a half second is expected every now and then, but it should be very rare.
you two are discussing two different topics, or mix-using terms
interpolation and lag compensation are different.
<a href="https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking" target="_blank">https://developer.valvesoftware.com/wiki/So...ayer_Networking</a><!--QuoteEnd--></div><!--QuoteEEnd-->
cl_interp (client interpolation) is different from server interpolation. You shouldn't expect tweaks to server side interpolation variables to have the same effect as tweaks to cl_interp. cl_interp is the amount of time the client waits before rendering the state the server has given it. So, on your standard server the server sends new chunks of information to the client 30 times a second. Things in NS2 move fast, so if your client only updated every time it received a server, it would effectively give a rendering effect of things teleporting around at roughly 30 FPS. This isn't a desired situation, the way this is handled is the client takes the data it receives from the server, add a bit of delay time as a buffer (your interpolation period, or the number of cl_interp in milliseconds), and interpolates from the historical state to the next newest state.
It's pretty normal for cl_interp to be set such that the client has time to react if it happens to lose one game state. So at tickrate 30, your client normally has an interpolation period of about 70ms. If we imagine 3 ticks, the newest one, one that's about 33 seconds old, and one that's about 66 milli seconds old. If for some reason the one that was supposed to arrive at 33 ms never gets there, but we do get the newest one, the client can still interpolate between the two frames 66ms apart.
The down side is, your client side interp rate effectively means your client isn't actually putting things on your screen until 70 milliseconds after it's technically aware of them happening. For this reason, lots of competitive players would willingly take the hit to interp and expose themselves to jitter more often to half the interp time they had to wait before their client updated to the most recent game state.
Server Interpolation is different. The server doesn't intentionally send old game state data to your client, it sends the newest game state data it has available. However, if you are playing your game, and you have 60ms latency, then the newest data you can possibly receive to your machine is AT LEAST 60ms old before you can begin to render it on your screen. If your latency is worse, than the game states your client is receiving are older. This is why you need server side interpolation. Every client in the game is interacting with the map slightly ahead of what the server is aware of, and interacting with every other client slightly behind what the server is aware of.
Now, in first person shooters, we want it such that, if we shoot at something on our screen with a hitscan weapon, and we hit it on our screen, then it is hit in the game. However, this isn't strictly absolutely possible, because as we know our opponent is further in the future on the actual map than we see him, and we're further in the future on our map than either he, or the server, sees us. So if the server doesn't know where he is yet, and our client is even farther behind the server, there's no way we can accurately display where he actually is at our time. The solution is that we don't display where he actually is, we display where he was instead, and we assume that the differential in time is small enough that it doesn't break the feeling on either player's end.
So here in lies the problem, on my screen I'm shooting at where you were, not where you actually are. We don't want my client to be able to just tell the server "oh hey, by the way, I killed joe here at this location", it's not safe for the server to trust our client quite that much... so what we have happen is our client tells the server "I made these shots at this location, and I THINK I killed joe". Now the problem is, we're shooting at something in the past, so by the time the trajectories of the shots we made get to the server, it knows joe is now somewhere else. If the server compares our shot trajectories with joe's location in the most recent time it's aware of, our shots probably missed, because we shot where joe was on our screen, and our screen is delayed from what the server knows is happening.
This brings us to sv_interp. What sv_interp does, is saves some old game data for several tics, for whatever number of ms the sv_interp value is set to. Our client has sent data to the server saying "I'm about X amount delayed from you, I made these shots, I think I killed joe". Rather than checking against where joe is most recently. It dips into it's interpolatable locations, finds the two that are closest to the time the client made the shots it's claiming it made, interpolates where joe most accurately was between those times, and confirms that the hit was accurate at that time.
<!--sizeo:4--><span style="font-size:14pt;line-height:100%"><!--/sizeo--><b>TLDR; </b><!--sizec--></span><!--/sizec-->cl_interp isn't the same as sv_interp, and changing the values for the two variables will have VERY different effects. sv_interp being lower will not help anyone experience less lag, cl_interp will. Also: I have no idea if NS2's hitreg issues have anything to do with interp, either client side or server side. it's very likely a wild goose chase looking in interp for the solution to the problem.
[edit] for the record industry was right that lower cl_interp would help decrease the delayed damage problem, but he was mistaken in his assumption that it had anything to do with server admins. Client side interpolation increases perception delay, not server side interpolation. We need a client side cvar, not a server side one (which would be an svar, but that's neither here nor there)
I'll leave it at that..i don't want to derail or hijack anything. (still so many unanswered questions about many'a'things)
I'm very sensitive to this stuff, and it's just something I just have to live with. If we could modify the cl_interp value, I would use 1/updaterate myself (as I do in Source games). But not everyone would enjoy that value and 2/updaterate, which I think is what we're seeing, is pretty standard.
Well, that's your perception and your opinion. Don't know if you are right or wrong, but a lot of people here have a different perception and opinion, in that it seems to happen more (or simply be more noticeable) in NS2.
Personally, I've played a lot FPS, and I've never seen it be this frequent or noticeable. I haven't played much BF3 though (or any other game you might be able to list that has a lot of this phenomenon).
Regardless, it could be caused by a technical issue specific to NS2, or a design difference specific to NS2 (skulks are so fast people say), but in the end it simply should not be present.
Be it a technical fix, or a design fix, it would be good if it was fixed. The source of the problem, as well as the solution is mostly irrelevant to the end-user. As long as there is one (at some point).
I'll leave it at that..i don't want to derail or hijack anything. (still so many unanswered questions about many'a'things)<!--QuoteEnd--></div><!--QuoteEEnd-->
It may be worse than it should be in NS2, but it's always going to be existent. This happens in TF2, L4D, every FPS game engine ever made. What each player sees on their screen is always a historical (read about a quarter second old) version of where all the other players are on their own screens. Therefore, if you just got behind a corner, too bad, you won't be behind that corner for everyone else for another quarter second. Combine that with applying damage late in the case of lost packets and you can have some very interesting effects.
I'm very sensitive to this stuff, and it's just something I just have to live with. If we could modify the cl_interp value, I would use 1/updaterate myself (as I do in Source games). But not everyone would enjoy that value and 2/updaterate, which I think is what we're seeing, is pretty standard.<!--QuoteEnd--></div><!--QuoteEEnd-->
Not a chance dude. Been playing games online for 15 years now, and the delay in this game are MUCH worse than any other online game I've played. Any version of CS, TF, BF, L4D, you name it.. those games all handle lag just fine. NS2 does not handle it worth a damn. And don't say its because the aliens move so fast, go play NS1 and tell me thats the problem. Ns1 handles lag just fine .. because its based on the HL1 engine.
I'm sure UWE will keep improving it but for now, its pretty bad. I pretty much don't even go lerk anymore because every time I do, I am not able to anticipate the damage coming in. By the time I notice I'm being shot at, its too late.. duck around the corner only to die about 1 second later. Derp.
Not sure what it is atm but in Firefall they defaulted it to like 250ms and that basically killed any hope of a competitive scene
Strange, because EVERY online game I play has this effect :)
Strange, because EVERY online game I play has this effect :)<!--QuoteEnd--></div><!--QuoteEEnd-->
I'd personally say it feels worse in NS2 than it did in NS. There is SOMETHING going on in terms of this NS2 having some issues.
The UWE team should consider looking at the Q3 CPMA netcode which is the best I have experienced, and take lessons from the HL1 netcode which is very robust considering it was initially designed for dial-up.