Interp?
male_fatalities
ausns2.org Join Date: 2004-03-06 Member: 27185Members, Constellation
ausns2.org Join Date: 2004-03-06 Member: 27185Members, Constellation
<div class="IPBDescription">So how high is it set?</div>Does anyone know the value of interp in NS2?
Thing's i've noticed when both players on 40-60 ping
- Both skulk/marine standing still, bite range is acceptable
- Leaping skulks seem to bite me from 5m away
- Cele skulks seem to bite me from 3-4m away
It seems when I'm marine, I have to time the jump atleast a full 2-3m before the skulk reaches me. Compare this to NS1 where you time the jump just as the skulk is about to collide into you.
FYI for those wondering what interpolation is:
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->"Interp" is essentially how CS:S interprets differences in latency. It's sources way to deal with lag. Basically both parties(the shooter and the shootie) send all their data to the server with their respective timestamps. The server receives and interprets the data and gives the kill to whoevers shot should have hit first according the the info it receives when balanced against the latency statistics between the two parties.<!--QuoteEnd--></div><!--QuoteEEnd-->
Thing's i've noticed when both players on 40-60 ping
- Both skulk/marine standing still, bite range is acceptable
- Leaping skulks seem to bite me from 5m away
- Cele skulks seem to bite me from 3-4m away
It seems when I'm marine, I have to time the jump atleast a full 2-3m before the skulk reaches me. Compare this to NS1 where you time the jump just as the skulk is about to collide into you.
FYI for those wondering what interpolation is:
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->"Interp" is essentially how CS:S interprets differences in latency. It's sources way to deal with lag. Basically both parties(the shooter and the shootie) send all their data to the server with their respective timestamps. The server receives and interprets the data and gives the kill to whoevers shot should have hit first according the the info it receives when balanced against the latency statistics between the two parties.<!--QuoteEnd--></div><!--QuoteEEnd-->
Comments
There were patch notes saying they did something to interp. But it feels like they increased it rather then decreased it
Has anyone tried editing their own .lua file
So you would need to use DAK atm if you wanted to run a server with a lower interp without constantly re-entering the console command.
So you would need to use DAK atm if you wanted to run a server with a lower interp without constantly re-entering the console command.<!--QuoteEnd--></div><!--QuoteEEnd-->
Jup that is right.
Our servers run with an interp of 50ms, but there isn't such a big difference to 100ms.
"Shot around a corner" is a downside of lag compensation. The upside of lag-compensation is you don't have to lead your targets - if you press fire while they are under your crosshair then it's a hit.
Shot round a corner happens when someone shot you while you were in view, but the message that they fired had to get from them to the server, then the server had to calculate if it hit, then send the message that you got hit to you. While all that was happening you moved around the corner.
The alternative is Quake style - no "shot around a corner", but you have to aim ahead of where you see the enemy.
Interpolation is a different thing to lag compensation - it is needed so other players appear to move smoothly on your screen - if you had 0ms interp then you'd just see the other players jumping around from spot to spot 20 times a second as you get your updates from the server, which is hard to aim at (and dodge). Instead you see a slightly delayed version of the world that is smoothly interpolated between the most recent update from the server and the previous one. The server takes the interpolation amount into account when lag-compensating your shots (that is, it knows you are seeing a slightly delayed version of the world, and when it "rewinds time" to see if your shot would have hit, it rewinds it to the point in time you were seeing when you pressed fire).
EDIT: the issues with dodging and collision etc are probably just unavoidable side-effects of client-side prediction. Your position in the world is up to date, but where you see everyone else is slightly delayed. It is the other way around on their machine (they see themselves up to date and you slightly delayed). There is no way around it without a faster internet.. Lowering interp to 50ms might work on a rock-solid LAN, but you couldn't go lower than that unless the server started sending updates more frequently than one every 50ms. On the internet where packets get dropped and delayed, 100ms is probably as low as you could go for interp unless the server update rate was increased.
In theory that would make a delay in a connection from Berlin to New York (=6,392 km) of 0.042 seconds = 42ms. (One way! Before you get an answer it takes twice as long!)
BUT there isn't a straight cable. There is an amount of routers and switches the signal has to go through. In this devices the electrical signal gets processed (decoding and packeting) and that takes a while, slowing the connection further down to around 120ms. And don't forget that also the game-server needs do process the data and send it back to you.
Sure, now you will say: You shouldn't play on a server so far away and you are right. But this was just an example. The delay gets smaller if you connect to a server in your country. But it will never be 0ms! So always keep in mind when playing a fast paced 1st person shooter. What you see isn't the reality. This just isn't physical possible. You always see things some time in the past. Only with some tricks like interpolation and lag compensation, you perceive the illusion of real time.
I think 50ms is as low as you can go with 20 updates a second. I imagine setting it to lower than that would just be like turning it off entirely, since there would never be 2 updates to interpolate between. I would be interested in experimenting with turning it off though to see how it effects the game.
For me, ideally we would be getting 60 updates a second and then turning off interp or turning it down to 16.6ms would be possible with minimal disruption to gameplay. Of course, if you were playing against clients with 30fps then you would see them glitching since they wouldn't be sending enough updates, so perhaps it is better to wait until performance is higher for everyone...
everyone should read shaders post. it is accurate
Wilson you should also read shaders post. Interpolation does not decide if players can shoot other behind corners etc., that is lag compensation which does not have a variable "setting". Lag compensation is decided by each players latency to the game server.
Simple explanation: C1 has 5 latency, C2 has 200 latency (sorry I am mixing up C1 & 2's latencies with ping but I hope you get the idea). C2 comes around a corner and immediately sees C1, however, C2's position is -200 ms back in his actual position in the game state, in C1's view. Which means that it takes 205 ms before C1 sees C2 coming around the corner. Lag compensation is decided by each clients latency and can not be changed (effect e.g. in Source is setting cl_cmdrate to min value decreases the clients "visible latency", due to the way it is calculated, but not it's actual ping).
C1 can fire at C2 204 ms after C2 has fired at C1 in reality, and still C1 fires first in the server's lag compensated result.
Interpolation on the other hand is when you have two <u>net game state frames</u>. The game states are then INTERPOLATED, to avoid choppy movement, or if you have with one or several more frames missing in between, it is interpolated to avoid the activation of the EXTRAPOLATION and PREDICTED STATE ERROR-ADJUST(very restricted and often abused by hackers) routines.
There is far more to it than this but I hope I brought some additional explanation.
So if you have two players facing each other and one starts strafing to the left, in his first person view he sees himself moving right away, but the player watching him won't see him move until: both clients latency + interp delay. (time it takes the packet to reach him, plus view delay from interpolation)
So the higher that interp value, the more the moving player can move before the other sees it. I.E. the more likely he is to be shot around a corner from his perspective or bitten from 5ft away.
So if you have two players facing each other and one starts strafing to the left, in his first person view he sees himself moving right away, but the player watching him won't see him move until: both clients latency + interp delay. (time it takes the packet to reach him, plus view delay from interpolation)
So the higher that interp value, the more the moving player can move before the other sees it. I.E. the more likely he is to be shot around a corner from his perspective or bitten from 5ft away.<!--QuoteEnd--></div><!--QuoteEEnd-->
Interpolation does exacerbate the "shot around a corner" effect, because while you were running around the corner, interp means that the player who shot you was seeing where you were 100ms + half their ping in the past. And lag compensation means that the server calculates their shot against what they were seeing at that point in time.
But the main point is you can't do without interpolation. Smooth movement of your targets is essential for any action game. Any game that draws the world more frequently than it updates the game state needs interpolation. Even RTS games and single player games use interpolation - they might have the game logic running at 10fps, then the display runs as fast as your computer can go, interpolating between the last two game frames (that would be 100ms interp).
Another cause of all this inconsistency between players views of the world is <b>client-side prediction</b>. This was introduced in QuakeWorld, an update to Quake (ie Quake 1). In networked Quake games, when you pressed a movement or attack key, the message went to the server, the server calculated the result, then sent a message back to you telling your client to update your position. That meant that if you had a 250ms ping, there was at least a 250ms + the interpolation amount delay between you pressing forward, and your character actually moving forward. This really kills the "feel" in an action game. (Quake wasn't meant to be played over the internet, but people did it anyway).
QuakeWorld was designed for internet play. With client-side prediction, when you press a movement key, two things happen. 1) a movement message gets sent to the server 2) your local client just assumes the server will OK the move, and goes ahead and updates your players position. The client knows the level layout so it can tell if you are going to bump into level geometry, and it has a slightly delayed version of the other players locations so it can make a reasonable guess about wether you'll hit another player. If the server got a different result (eg because another player had moved into your path but your client didn't know that yet), then when it sends the result of the move back your position will be updated - this is why when the server is lagging, or you have high ping, you occasionally jump around and rubber band a bit - your client was predicting different results of your moves than the server calculated.
Upside of prediction is more responsive player movement - you don't have to wait for the server to OK your move, you just move straight away, and most of the time the server got the same result, so it's all smooth.
The downside is that now your local "predicted" position is ahead of where other players think you are. Similarly, other players see themselves ahead of where you think they are. Because NS2 is melee vs range, the inconsistencies in player position might be more apparent, as player-to-player collisions are more likely to get different results between the predicted version on the client and the actual one on the server.
[deleted a bunch of calculations about prediction timing inconsistencies - anyone know if NS2 interpolates the local player position or not? It recalcs this every frame, so technically wouldn't need to]
I don't know about the reason why there is a performance limit of 25 players at this stage but the next priority should be increasing the update rate to 30 fps. It was raised from 17 to 20 in one of the latest patches? Which is a very good direction.
Btw if you set the interpolation duration to 0 ms, interpolation will be disabled and all other player movement you see will be chunky and only update at 20 fps even though your rendering rate is 60 fps.
You can if you have 60 updates a second from the server instead of 20. I don't know if spark will ever have that though.
Packets are not guaranteed to arrive or guaranteed to arrive in the order they are sent.
If you send packets like so: 1...2...3...4...5...6...7...8...9... what you actually end up getting can look like this: ...1...2.....4.3...5....6..7.......9....
What Soylent_green said. PLUS there is much more data to send in NS2 than in Quake.
In Quake you only need to send player-positions, -directions and -state. What weapon the player holds and when a weapon is collected from the map. Maybe the state of some doors or elevators and thats it.
In NS2 you need to send in addition to the above, the position, direction and state of every building and AI-Unit. (That includes cysts!) That gets you a lot more traffic. And therefor a lower possible update rate.