Being on LAN is irrelevant because the amount of interpolation is not related to ping. The amount of interpolation should be based on the frequency at which the server sends updates to clients and that doesn't increase just because you're playing on LAN.
no, but the amount of interpolation is there to mimic a low ping and reduce lag, which is not applicable on a LAN.
Nope, interpolation does not mimic a low ping or reduce lag. Its purpose is to eliminate animation jitter/choppiness.
actually yes. semantic lag argument aside, the interpolation makes it possible to turn a 'choppy' low ping into a smooth 100ms ping which can then simulate the low ping through lag compensation (which i believe is technically impossible without the interpolation delay).
anyway, would you care to follow through and explain why jitter/choppiness is a big deal at LAN?
i'm bored by the mechanics of computers/networking/telecommunications, but i always thought the majority of jitter/choppiness came from long distance/poor intermediary hardware/bad weather etc and therefore entirely bypassed during LAN.
ScardyBobScardyBobJoin Date: 2009-11-25Member: 69528Forum Admins, Forum Moderators, NS2 Playtester, Squad Five Blue, Reinforced - Shadow, WC 2013 - Shadow
edited April 2013
I think the big issue is that people are confusing interpolation and lag compensation. They are related, but don't do the same thing. How I keep them separated in my head is:
- Interpolation = Related to server update rate
- Lag Compensation = Related to client latency
Reducing interp will increase the 'jitteriness' of gameplay unless the servers update and/or tickrate is also increased.
I think the big issue is that people are confusing interpolation and lag compensation. They are related, but don't do the same thing. How I keep them separated in my head is:
- Interpolation = Related to server update rate
- Lag Compensation = Related to client latency
Reducing interp will increase the 'jitteriness' of gameplay unless the servers update and/or tickrate is also increased.
Jitter models is what counter-strike 1.6 has, however the hit detection is superb (minus the model/hitbox bug when planting the bomb or excessively crouching)
Compare that to source or csgo, and you'll wonder how it went so backwards, source 09 sdk feels like a pile of crap (mainly because somewhere in 2010 they moved the game to another engine and lowered the ticrate) and csgo feels like junk because it's updating so fast and the models move faster, yet the game still has lag compensation, and everyone has different interp settings, it just causes a gigantic crap fest) Which is weird because csgo generally runs at 128 tic, and the engine supports even higher than that.. yet the lag comp plus the random interp settings of players makes it all feel so wrong
On that note, why are these variables locked server side? Possibly the game engine just isn't stable with higher settings, or the performance requirement is too high for a computer to handle. Could be a list of varying things!
@ezekel
My theory why the server is locked to 30 tick right now is because of the inherent LUA cpu performance cost, as UWE haven't yet released the LUAJIT implementation they've been working on.
You can see the potential performance increase here: http://luajit.org/performance_x86.html
Most of the gamerules, menus, HUD, weapons etc are in pure LUA which stand to gain insane performance boosts.
As a client you can't set your own interp setting in NS2, the server provides one and enforces it onto the clients.
Personally, all I want is a confirm/deny from the devs on whether they will allow server owners the option to change tickrate, updaterate and maxsendrate at will.
I don't see why almost everyone is arguing about the effects of lag compensation/interp/jitter and what they are, matso linked the answer to all your questions on page one with the third post:
It discusses tickrate, interpolation and lag compensation; please read it if you do not understand, instead of posting.
This thread should serve as a petition to UWE to allow the community the ability to tweak these important network variables, not to discuss the mechanics and or implementation of them and how they work.
@ezekel
the 1.6 models were changed recently, (a couple years ago) to nine-way looking models. This caused the weird, model of the head to appear where the head hitbox was not. The change was for aesthetic purposes only, and is a perfect example of why gameplay trumps graphics. Rather have models line up perfectly to where hitboxes are, than have models that look in 9 directions.
Theres some badddd information in this thread...
HL1 uses almost identical netcode compared to Spark, and Source... There are various reasons why it does not feel as good in Source/Spark vs HL1, but the base concepts are near identical, and this is not the thread to discuss those. The biggest difference with Spark from the Source/HL1 is the lack of configurable options (which is what I want currently). After that, the lack of per client settings (interp, rate, etc) could be brought up, but is a much smaller issue. Having these settings is important for both lan events (things could be minimized as much as possible), and also that there is more cpu overhead with 6v6 servers currently that could most likely support atleast a client update rate of 30 (along with a tickrate of 35-40), so that interp could be safely reduced into the 40-50ms range.
Theres some badddd information in this thread...
HL1 uses almost identical netcode compared to Spark, and Source... There are various reasons why it does not feel as good in Source/Spark vs HL1, but the base concepts are near identical, and this is not the thread to discuss those. The biggest difference with Spark from the Source/HL1 is the lack of configurable options (which is what I want currently). After that, the lack of per client settings (interp, rate, etc) could be brought up, but is a much smaller issue. Having these settings is important for both lan events (things could be minimized as much as possible), and also that there is more cpu overhead with 6v6 servers currently that could most likely support atleast a client update rate of 30 (along with a tickrate of 35-40), so that interp could be safely reduced into the 40-50ms range.
If they are so similar, why do they feel so different? I'm not trying to just be awkward, I geniunely want to understand why NS2 feels so different to the HL1 engine. I never got along with Source. HL1 is by far my favourite FPS multilayer engines by a large marin. The accuracy of the player in the world and the netcode just seemed to be extremely good.
The biggest difference with Spark from the Source/HL1 is the lack of configurable options (which is what I want currently). After that, the lack of per client settings (interp, rate, etc) could be brought up, but is a much smaller issue. Having these settings is important for both lan events (things could be minimized as much as possible), and also that there is more cpu overhead with 6v6 servers currently that could most likely support atleast a client update rate of 30 (along with a tickrate of 35-40), so that interp could be safely reduced into the 40-50ms range.
This is my case exactly.
The only difference is that I would be very wary of letting individual players tinker with their net settings in their clients. It has really caused some wonky situations in the past. Source games as a good example which several people in here have brought up already.
Improving the 6v6 servers would be very, very welcome.
If they are so similar, why do they feel so different? I'm not trying to just be awkward, I geniunely want to understand why NS2 feels so different to the HL1 engine. I never got along with Source. HL1 is by far my favourite FPS multilayer engines by a large marin. The accuracy of the player in the world and the netcode just seemed to be extremely good.
Graphics.
One of the biggest destroyers of engines is dynamic lighting. The extra workload caused is heavy and leads to the sense of 'sluggishness' that you get in today's modern engines. I am pretty sure physics and other game 'improvements' over the years have added to this burden, but it is highly unlikely you'll find light and nimble engines like HL1 again unless a new method of rendering lighting is conceived that uses far less hardware for a much better result..
Comments
Server tick rate is 30 but update rate is 20.
actually yes. semantic lag argument aside, the interpolation makes it possible to turn a 'choppy' low ping into a smooth 100ms ping which can then simulate the low ping through lag compensation (which i believe is technically impossible without the interpolation delay).
anyway, would you care to follow through and explain why jitter/choppiness is a big deal at LAN?
i'm bored by the mechanics of computers/networking/telecommunications, but i always thought the majority of jitter/choppiness came from long distance/poor intermediary hardware/bad weather etc and therefore entirely bypassed during LAN.
See my post at the bottom of page 2 of this thread.
- Interpolation = Related to server update rate
- Lag Compensation = Related to client latency
Reducing interp will increase the 'jitteriness' of gameplay unless the servers update and/or tickrate is also increased.
Jitter models is what counter-strike 1.6 has, however the hit detection is superb (minus the model/hitbox bug when planting the bomb or excessively crouching)
Compare that to source or csgo, and you'll wonder how it went so backwards, source 09 sdk feels like a pile of crap (mainly because somewhere in 2010 they moved the game to another engine and lowered the ticrate) and csgo feels like junk because it's updating so fast and the models move faster, yet the game still has lag compensation, and everyone has different interp settings, it just causes a gigantic crap fest) Which is weird because csgo generally runs at 128 tic, and the engine supports even higher than that.. yet the lag comp plus the random interp settings of players makes it all feel so wrong
On that note, why are these variables locked server side? Possibly the game engine just isn't stable with higher settings, or the performance requirement is too high for a computer to handle. Could be a list of varying things!
My theory why the server is locked to 30 tick right now is because of the inherent LUA cpu performance cost, as UWE haven't yet released the LUAJIT implementation they've been working on.
You can see the potential performance increase here: http://luajit.org/performance_x86.html
Most of the gamerules, menus, HUD, weapons etc are in pure LUA which stand to gain insane performance boosts.
As a client you can't set your own interp setting in NS2, the server provides one and enforces it onto the clients.
Personally, all I want is a confirm/deny from the devs on whether they will allow server owners the option to change tickrate, updaterate and maxsendrate at will.
I don't see why almost everyone is arguing about the effects of lag compensation/interp/jitter and what they are, matso linked the answer to all your questions on page one with the third post:
It discusses tickrate, interpolation and lag compensation; please read it if you do not understand, instead of posting.
This thread should serve as a petition to UWE to allow the community the ability to tweak these important network variables, not to discuss the mechanics and or implementation of them and how they work.
Are you saying we're getting a big performance boost??
the 1.6 models were changed recently, (a couple years ago) to nine-way looking models. This caused the weird, model of the head to appear where the head hitbox was not. The change was for aesthetic purposes only, and is a perfect example of why gameplay trumps graphics. Rather have models line up perfectly to where hitboxes are, than have models that look in 9 directions.
HL1 uses almost identical netcode compared to Spark, and Source... There are various reasons why it does not feel as good in Source/Spark vs HL1, but the base concepts are near identical, and this is not the thread to discuss those. The biggest difference with Spark from the Source/HL1 is the lack of configurable options (which is what I want currently). After that, the lack of per client settings (interp, rate, etc) could be brought up, but is a much smaller issue. Having these settings is important for both lan events (things could be minimized as much as possible), and also that there is more cpu overhead with 6v6 servers currently that could most likely support atleast a client update rate of 30 (along with a tickrate of 35-40), so that interp could be safely reduced into the 40-50ms range.
If they are so similar, why do they feel so different? I'm not trying to just be awkward, I geniunely want to understand why NS2 feels so different to the HL1 engine. I never got along with Source. HL1 is by far my favourite FPS multilayer engines by a large marin. The accuracy of the player in the world and the netcode just seemed to be extremely good.
This is my case exactly.
The only difference is that I would be very wary of letting individual players tinker with their net settings in their clients. It has really caused some wonky situations in the past. Source games as a good example which several people in here have brought up already.
Improving the 6v6 servers would be very, very welcome.
Graphics.
One of the biggest destroyers of engines is dynamic lighting. The extra workload caused is heavy and leads to the sense of 'sluggishness' that you get in today's modern engines. I am pretty sure physics and other game 'improvements' over the years have added to this burden, but it is highly unlikely you'll find light and nimble engines like HL1 again unless a new method of rendering lighting is conceived that uses far less hardware for a much better result..