Just for the sake of server performance, you could have made the interpolation client side. That saves a lot of ressources:
-Clients only have to interpolate entities they see.
-Servers dont have to backtrack the movement of every entity with snapshots
Plus all the annoying "features" the OP listed are gone. The only downside is, that sometimes you dont hit what you aim at - since your target evaded you during the interpolation time. So playing with +150ms ping is quite tedious.
Regarding server rate variables, I had head that there was a plan to set up "premade" settings that can be adjusted based on Server hardware...is that even possible due to the variety of server hardware outhere?
You are correct:
Around the time when we unlocked the network variables there were plans to release a set of recommended settings to the public. You can make such kind of sets assuming a certain setup for most of the ns2 servers.
But there was a small fraction of cdt members who were against the release of those and after a really long internal debate this plan was dropped and a decision was made i will explain further later in this post.
Overall releasing such a set might be good to give server admins a kind of guideline how to modify network settings overall generally. But there a more reasons speaking against doing so and why this plan was finally dropped:
Due to the variance of ns2 server setups we currently see it's pretty hard to come up with a setup which would cover most of them (due to hardware differences and more important network setups)
Admins will be temped to "turn the switch" without actually understanding what that switch does which might make the experience for most ns2 players even worse than it is currently.
Most servers are already struggling with the current default values. Giving out values which need even more cpu power won't do any good. And due to the lack of knowledge we can assume that most admins will resist to use lower setups than the default ones even if those would improve the user experience.
Also at that point when this discussion came up internally we didn't had enough time to test how modified network variables affect the game-play overall. Today we know that at a update-rate around 60 you already notice some weird effects in-game which indicate that certain parts of the game-code were not coded with having in mind that the update-rate might be a lot higher than 30.
So the cdt decided to not release any details about the settings at all, instead to just tell the community that the variables can now be chosen freely and that interested server admins should contact given cdt members who are well aware how the spark/ns2 network code works.
By doing this and adding the warning to the server-browser we did make sure that the network variables are handles with the needed care and that admins tweaking those are fully aware about what they do.
This all has been done with the goal to improve the overall ns2 user experience and don't make it worse.
And good example at this place is that it might be a good idea at some servers running currently into a cpu limit in the late-game to lower the tick-rate. If you are now aware that the tick-rate only controls the A.I. update rate and that the player movement update rate is only 20 by default this makes totally sense and overall can lower the cpu load without that the user even notice it while playing.
But most ns2 players without reading about it and understanding how the ns2 networking actually work will just declare you as an idiot if you suggest to lower the tick-rate ...
Just looking at some posts in this thread (no offense) tell me that some ppl still don't understand how things work.
Just for the sake of server performance, you could have made the interpolation client side. That saves a lot of ressources:
-Clients only have to interpolate entities they see.
-Servers dont have to backtrack the movement of every entity with snapshots
Plus all the annoying "features" the OP listed are gone. The only downside is, that sometimes you dont hit what you aim at - since your target evaded you during the interpolation time. So playing with +150ms ping is quite tedious.
No offense but I don't think you understand what interpolation does.. sounds like you are describing "Lag compensation" which is an entirely different thing.
Please read Ghoul's prior post on page 2 for a detailed explanation.
But even if you meant lag compensation.. it's an industry standard now for a reason. It works just fine if properly implemented.
As much as i enjoyed my Action Quake 2 days of aiming my sniper rifle 15 player widths ahead of the falling enemy.. it's insanely unintuitive and varying based upon fluctuating latency - which is fine only if you are playing on a LAN or enjoy randomness.
But even if you meant lag compensation.. it's an industry standard now for a reason. It works just fine if properly implemented.
As much as i enjoyed my Action Quake 2 days of aiming my sniper rifle 15 player widths ahead of the falling enemy.. it's insanely unintuitive and varying based upon fluctuating latency - which is fine only if you are playing on a LAN or enjoy randomness.
unlimited lag compensation isn't standard
they invented the limited form and use it in fast-paced games for a reason
shooting remains 100% intuitive (LAN-like) as long as you are below the limit
you only have to lead shots if you have super high ping and the game didn't implement good prediction
there's only randomess if you have significant packet loss or unpredictable routing + high ping
for NS2 in particular, removing unlimited lag compensation would greatly reduce randomness
right now figuring out whether you are hitatble (on your enemy's client) or how much HP you actually have (after accounting for incoming shots that you haven't registerd yet) involves a lot of gueswork
limiting lag compensation just clamps the uppper limit (of how detached your client isfrom the effective game state). the range of possibilities is much smaller and much closer to what the player sees on his screen
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
@biz
What exactly do you mean by "unlimited lag compensation" ?? That's not a universally known or documented term.
Not everything is lag compensated in NS2, if that was what you were implying?
And structurally, it is implemented in the same way as other fast paced games like TF2, Warsow, Q3, and Tribes. (and ofc slower ones like CS and COD)
Soooo it's pretty fair to say what is being utilized IS the standard.
The only difference is that some (non hitscan) items like the flamethrower or rockets are not compensated in these games... but really it's not like NS2 Marines have a rocket launcher; their main weapons are all hitscan so there wouldn't be much perceived improvement by changing this.
This is what you dont get Ironhorse, there ARE tons of things like the rocketlauncher in NS2. The whole melee combad revolves around the same principle as reacting to an incoming rocket. Skulks are basically rockets you want to dodge before they get close and bite you. This makes evading shots or melee attacks from people with different latency as unintuitive as what you say happens with quake 2 aiming.
I'm not calling for you to completly rewrite the netcode and fall back to HL1 standards. I'm just saying that the netcode feels worse than other state of the art games and even worse than HL1. Moreover, since it seems to cost so much server-side performance I don't think it is worth it.
PS: What the interpolation i was talking about does is to calculate the position an entity would have on the server's game reality by the time a shot delayed by your latency would reach it.
if NS2 does not have unlimited lag compensation, then there has to be a limit
if such a limit exists, then what is it?
500 ms?
10 server updates?
some other unit of measurement?
is it different for different weapons?
another way to ask it might be:
what's the maximum amount of time that a server is allowed to go back (in order to check whether a client hits something) after a shot has been submitted?
The whole melee combad revolves around the same principle as reacting to an incoming rocket. Skulks are basically rockets you want to dodge before they get close and bite you. This makes evading shots or melee attacks from people with different latency as unintuitive as what you say happens with quake 2 aiming.
It would make zero sense if skulks were not lag compensated, because then shots that would otherwise 100% hit a skulk you were aiming at would miss every time...
What you are referring to is the current delayed update of entity positions to the other player - which would occur with any authoritative server setup that understandably doesn't trust the client.
The side effect of lag compensation in any game is that the attacker has a slight advantage over the retreating player because each player sees itself in the present but sees the other entities in the past.
This means a skulk has the advantage walljumping around the corner - but has the disadvantage when trying to escape to cover.
It's a pretty fair trade off for hitting what you aim at.
PS: What the interpolation i was talking about does is to calculate the position an entity would have on the server's game reality by the time a shot delayed by your latency would reach it.
That is prediction then, not interpolation.
Entity interpolation doesn't predict future positions at all – it uses only real entity data provided by the server, thus showing the other entities slightly delayed in time - it's a safety net that provides smooth entity movement despite network hiccups. Here's great 3 part article on the subject.
what's the maximum amount of time that a server is allowed to go back (in order to check whether a client hits something) after a shot has been submitted?
what's the maximum amount of time that a server is allowed to go back (in order to check whether a client hits something) after a shot has been submitted?
2 frames afaik
there's no way it's that low
that would be 66 ms at an updaterate of 30/sec
it would mean you would have to start leading shots at 66 ping
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
@biz Well then I am probably wrong.
But what's so wrong with hitting something you aim at?
Even players connecting from other continents typically only reach around 220 ms.. only an extra 100 ms from connecting to the other side of my own country.
So what is this concern for "unlimited" lag compensation?
it means you get notified so late about incoming damage that you lose your chance to do anything about it
it reverses the balance of the game in terms of attack & defense (see example in first post) or movement vs stealth
even if the game has some extremely generous cap like 200 ms (many fast games use <100), it would at least guarantee that a player with 50 ping would never receive more than ~250 ms of damage from a single opponent before being notified about it
right now marines get bit twice before their clients (or the commander's client) even registers the first one
aliens lose expensive lifeforms because their effective HP (what the marine client sees) is reduced much earlier than the alien gets any indication of that happening
you basically play the game a completely different way depending on the pings of your opponents.
and when your opponents all have different latencies, you get confused and don't know whether to engage or retreat
instead, the game should be more intuitive. if you have to adjust your playstyle, it should be more about your own ping to the server and less about your opponents' pings
the game is designed so that there are many situations where staying alive is way more important than getting a kill. the netcode should complement that game instead of just favoring combat at the expense of survival
there are solutions to deal with scenarios where rendered models lag behind the true hitboxes (prediction)
there is no solution to deal with scenarios where your rendered HP lags behind the true HP
the game is designed so that there are many situations where staying alive is way more important than getting a kill. the netcode should complement that game instead of just favoring combat at the expense of survival
How exactly?
Authoritative server + Lag compensation + interpolation + prediction isn't perfect - but it's as good as it gets today. There aren't any better solutions out there. If you know of any please suggest them.. but if you only have "it should be more about your own ping to the server" then that just doesn't work for any game that isn't insanely popular where you can easily play with people within close distances. It also comes with the HUGE downside of not hitting what you aim at... an important consideration when you are suggesting that the game "should be more intuitive".
you basically play the game a completely different way depending on the pings of your opponents.
This is true for any game not being played on a LAN....?
Even in the days before lag compensation that sentence holds true (even moreso)
not really. I don't have to worry about other peoples' ping when I play other FPS games
I only have to think about what weapons I use based on my own ping to the server
the main reason is that the client and server don't have radically different gamestate in those games due to better netcode in general (including capped lag compensation)
also there isn't really this whole melee vs ranged asymmetry
the game is designed so that there are many situations where staying alive is way more important than getting a kill. the netcode should complement that game instead of just favoring combat at the expense of survival
How exactly?
Authoritative server + Lag compensation + interpolation + prediction isn't perfect - but it's as good as it gets today. There aren't any better solutions out there. If you know of any please suggest them.. but if you only have "it should be more about your own ping to the server" then that just doesn't work for any game that isn't insanely popular where you can easily play with people within close distances. It also comes with the HUGE downside of not hitting what you aim at... an important consideration when you are suggesting that the game "should be more intuitive".
the solution is to enforce that whenever a client receives an update from the server, that game state is always a 100% accurate representation of all actions taken excluding the past <ping> + <lag compensation limit>
that means if I get an update within 50 ms (ping of 50), and the lag compensation limit is 80 ms, people can only do 130 ms of actions before I get a chance to respond
you never have to worry about receiving a ton of damage that your client hasn't registered yet
it allows for wonderful things like actually being able to dodge projectiles or actually running away before you take lethal damage
in most of these games, projectiles actually get even more accurate netcode so that they are dodge-able (unlike NS2 GLs)
you will still die around corners to hitscan weapons, but instead of dying from half a second of damage (eg. NS2), you will at most die from an extra 130 ms of damage
as long as your latency is below the lag compensation limit, you still shoot exactly what you see on screen
if you are slightly over it, you can get by by shooting at predicted models
people tested and tuned these solutions for over 10 years
I'm not saying that 80 ms of lag comp is the best limit for NS2, but there should be some limit so that people can at least learn how to play the game intuitively + properly instead of just randomly winning or losing engagements based on opponents' pings
Correct me if I'm wrong, but doesn't the current system actually favour players with ~100 to maybe ~250 ping (before it gets unplayable) by essentially giving them the ability to travel back in time and landing damage on someone.
As an example, early game I tend to drop dead after what appears to be one bite from a skulk. If I check, it often turns out it was someone with 100+ ping.
I would assume that its because while I think I moved away before the skulk got to me, in his time line he landed some of the damage before I even turned around.
That works both ways, if you attack him he is informed of it later because of his high ping.
With high ping it becomes less about reacting and more about moving unpredictably and being the first to strike. HIgher ping servers are a great equalizer in a way.
Nb. Getting three bites off in one go would need a latency over 450ms (two bites still in transit, one conveyed).
Not uncommon, not exactly pervasive either. I can't objectively say if it's the game or under-performing servers that allow 250ms ping players.
As an example, early game I tend to drop dead after what appears to be one bite from a skulk. If I check, it often turns out it was someone with 100+ ping.
I would assume that its because while I think I moved away before the skulk got to me, in his time line he landed some of the damage before I even turned around.
Have this every time I play. Skulks are just like frikin nades early game: they jump and explode in your face.
I used to play games like Zombie Panic source and GMod Murder. Melee combat there raised no questions.
I used to play games like Zombie Panic source and GMod Murder. Melee combat there raised no questions.
Woooo Zombie Panic Source! I coded the grenade cooking in that. And some other things I'd like to forget about
Can't speak for murder but Zombie Panic has slowly lumbering zombies, they're far from lerk, fade or skulk speed. Plus Source netcode is just exceptionally well done.
Nb. can we bribe someone to mod in the ZPS panic button for marines? Explode your gear in all directions and get a short speed boost for a few seconds. Include the scream and I'll give you a cookie.
GhoulofGSG9Join Date: 2013-03-31Member: 184566Members, Super Administrators, Forum Admins, Forum Moderators, NS2 Developer, NS2 Playtester, Squad Five Blue, Squad Five Silver, Reinforced - Supporter, WC 2013 - Supporter, Pistachionauts
edited October 2014
Ok theoretically ns2 has a lag compensation of 100 ms.
But events like the WC have shown that this function is not really working the way it is intended to work. Meaning yes players with a ping of above 200 ms or ping delta jitters of above 50 ms sometimes have a unfair advantage against normal players as there movements get pretty hard to predict for the normal players and they do things like sudden jumps and direction turns etc. .
That's basically the reason there exists the shine plug-in "Ping Tracker". Beside this issue there is another one you see specially when it comes to grenades projectiles.
The flight way of grenades it not networked (only the event of it getting fired and exploding and hitting something. The hole flight movement gets predicted at the client. So this ends up to be incorrect with what the server calculates due to the facts that first the client might miss some updated situation and that the grenade prediction code has some smaller issues.
So you end up with the grenade exploding somewhere else than you would suspect it in the end because the flight ways of the grenade differ at the client from what the server calculated. This should not happen.
Same btw is kinda also true with the whips sometimes at the moment. But currently nobody of the cdt has time to really look at the grenade prediction code (even if we should at some point) or the lag compensation in the net-code.
Kind of the major reason ppl get hit by grenades even as they might think they would not because the physic model of the grenades is larger than the visual.
Talking about bigger hitboxes, I love the pulse grenade, the hitbox feels as big as a volkswagen beetle!
I agree there can be value in having a limit, but I'm not convinced it's right to set it that low. About 200 ms is still somewhat playable if you're in a casual mindset and can be neat to visit other continents. It would be a shame to make it intentionally unplayable when it doesn't have to be, though I'm fully aware of how a high ping opponent can cause you serious grief, so I see your point.
I agree there can be value in having a limit, but I'm not convinced it's right to set it that low. About 200 ms is still somewhat playable if you're in a casual mindset and can be neat to visit other continents. It would be a shame to make it intentionally unplayable when it doesn't have to be, though I'm fully aware of how a high ping opponent can cause you serious grief, so I see your point.
The main issue are not really player with constantly high pings but ppl whose ping jitter a lot. Because actually you can use "jittering" to get a unfair advantages in a combat in-game and I've sadly already seen players using this technique.
Therefor imho high "ping jittering" has to be reviewed in case of ns2 the same way as cheating.
Jitter is a bigger problem, but I'm actually talking about plain high ping. For example in a scenario against a very high ping marine tracking you with his rifle, you will take damage for much longer after moving into cover (or what appeared to be moving into cover on your client), which can be the difference between life and death if you didn't know an opponent has a high ping and played carefully because of it. Goes both ways though. Jitter is worse and I too see it as basically cheating.
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
@biz if you're experiencing more responsive net code in other fps it's not because they lack lag compensation - it's because their update rates are much higher.
If server performance wasn't an issue and we spent time ironing out bugs, there'd be no discernable difference between the fps games you play and ns2 once we increased the rates.
To drive this point home : if we mimicked quake live's original implementation of "unlagged" that engaged lag compensation beyond 80 ms, (iirc that's no longer the case?) which I presume is where you got this idea from... And this is all we changed.. You'd still have the same issues of receiving tons of damage before it registers on your client!
Now, if you wanted instant updates then you have to trust the client - something that has invited cheaters and ruined most games that have done this. Bf3 had to hire an entire 10 man team dedicated to battling these cheaters because of this setup.. And still that game had horrendous hit reg issues
Correct me if I'm wrong, but doesn't the current system actually favour players with ~100 to maybe ~250 ping (before it gets unplayable) by essentially giving them the ability to travel back in time and landing damage on someone.
high ping players can do more "surprise" damage than low ping players
it's supposed to be "balanced" because high ping players will also receive more "surprise" damage
but the game is asymmetrical so that "balance" doesn't really translate to anything objectively balanced
As an example, early game I tend to drop dead after what appears to be one bite from a skulk. If I check, it often turns out it was someone with 100+ ping.
I would assume that its because while I think I moved away before the skulk got to me, in his time line he landed some of the damage before I even turned around.
yeah. unlagged netcode will make it much harder (sometimes impossible) to react in time to stuff like that
if you play this scenario from the skulk's perspective, you can do really stupid things like move up to the marine in a straight line on the floor, except it's not that dangerous because you will land 2 bites before the marine's client reacts
the weird thing is 100-200 ping shouldn't result in so much timeshift between client & server.
you would expect that behavior from 400 ping maybe. that's why people say 100-200 ping in NS2 is like 300-500 ping in a normal game
I agree there can be value in having a limit, but I'm not convinced it's right to set it that low. About 200 ms is still somewhat playable if you're in a casual mindset and can be neat to visit other continents. It would be a shame to make it intentionally unplayable when it doesn't have to be, though I'm fully aware of how a high ping opponent can cause you serious grief, so I see your point.
The main issue are not really player with constantly high pings but ppl whose ping jitter a lot. Because actually you can use "jittering" to get a unfair advantages in a combat in-game and I've sadly already seen players using this technique.
Therefor imho high "ping jittering" has to be reviewed in case of ns2 the same way as cheating.
in source engine you can make a script that switches your interp between 33 and 500, forcing enemy player models to freeze in time for the difference. it's pretty funny for when you're playing a hitscan class such as sniper or scout in tf2.
alias +interp "cl_interp_ratio 2; cl_interp .5"
alias -interp "cl_interp .033"
bind +interp <key>
for anybody who's looking for a lolarbears time. i doubt they've fixed it. edit: as soon as I clicked save comment I remembered that they made it so you can't change interp while inside of servers anymore, oh well.
@biz if you're experiencing more responsive net code in other fps it's not because they lack lag compensation - it's because their update rates are much higher.
If server performance wasn't an issue and we spent time ironing out bugs, there'd be no discernable difference between the fps games you play and ns2 once we increased the rates.
To drive this point home : if we mimicked quake live's original implementation of "unlagged" that engaged lag compensation beyond 80 ms, (iirc that's no longer the case?) which I presume is where you got this idea from... And this is all we changed.. You'd still have the same issues of receiving tons of damage before it registers on your client!
i'm not comparing unlagged to NS2
that was a quake 3 mod which became obsolete once someone introduced lag compensation limits. a limit of 80 ms made its way into quake live in early beta
even if NS2 updated 120/sec (8 ms) instead of 30/sec (33 ms), it would only account for 25 ms of damage
compared to QL which uses 40/sec (25 ms), it's only 8 ms of damage
low numbers like that aren't even the issue when we're talking about multiple hundreds of ms
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
I just tested 185 ms ping in Quake live and hitscan weapons were definitely lag compensated so I don't know what you mean by "lag compensation limits"
Quake live doesn't have interpolation AFAIK, so there's 100 ms of difference right there.
In quake live, the now cheat protected server update setting of cl_maxpackets is 125 (8 ms) .. compare that to NS2's 50 ms.
I am sure there is another 100 ms of delay somewhere (i recall matso breaking down all the delays once) but right there, that's an extra 140 ms of delay, not counting latency or differences in lag compensation.
Another way to look at it is compared to Quake live, NS2's update rates add a delay which is 70% of the average gamer's reaction time.
Comments
-Clients only have to interpolate entities they see.
-Servers dont have to backtrack the movement of every entity with snapshots
Plus all the annoying "features" the OP listed are gone. The only downside is, that sometimes you dont hit what you aim at - since your target evaded you during the interpolation time. So playing with +150ms ping is quite tedious.
You are correct:
Around the time when we unlocked the network variables there were plans to release a set of recommended settings to the public. You can make such kind of sets assuming a certain setup for most of the ns2 servers.
But there was a small fraction of cdt members who were against the release of those and after a really long internal debate this plan was dropped and a decision was made i will explain further later in this post.
Overall releasing such a set might be good to give server admins a kind of guideline how to modify network settings overall generally. But there a more reasons speaking against doing so and why this plan was finally dropped:
Also at that point when this discussion came up internally we didn't had enough time to test how modified network variables affect the game-play overall. Today we know that at a update-rate around 60 you already notice some weird effects in-game which indicate that certain parts of the game-code were not coded with having in mind that the update-rate might be a lot higher than 30.
So the cdt decided to not release any details about the settings at all, instead to just tell the community that the variables can now be chosen freely and that interested server admins should contact given cdt members who are well aware how the spark/ns2 network code works.
By doing this and adding the warning to the server-browser we did make sure that the network variables are handles with the needed care and that admins tweaking those are fully aware about what they do.
This all has been done with the goal to improve the overall ns2 user experience and don't make it worse.
And good example at this place is that it might be a good idea at some servers running currently into a cpu limit in the late-game to lower the tick-rate. If you are now aware that the tick-rate only controls the A.I. update rate and that the player movement update rate is only 20 by default this makes totally sense and overall can lower the cpu load without that the user even notice it while playing.
But most ns2 players without reading about it and understanding how the ns2 networking actually work will just declare you as an idiot if you suggest to lower the tick-rate ...
Just looking at some posts in this thread (no offense) tell me that some ppl still don't understand how things work.
Please read Ghoul's prior post on page 2 for a detailed explanation.
But even if you meant lag compensation.. it's an industry standard now for a reason. It works just fine if properly implemented.
As much as i enjoyed my Action Quake 2 days of aiming my sniper rifle 15 player widths ahead of the falling enemy.. it's insanely unintuitive and varying based upon fluctuating latency - which is fine only if you are playing on a LAN or enjoy randomness.
unlimited lag compensation isn't standard
they invented the limited form and use it in fast-paced games for a reason
shooting remains 100% intuitive (LAN-like) as long as you are below the limit
you only have to lead shots if you have super high ping and the game didn't implement good prediction
there's only randomess if you have significant packet loss or unpredictable routing + high ping
for NS2 in particular, removing unlimited lag compensation would greatly reduce randomness
right now figuring out whether you are hitatble (on your enemy's client) or how much HP you actually have (after accounting for incoming shots that you haven't registerd yet) involves a lot of gueswork
limiting lag compensation just clamps the uppper limit (of how detached your client isfrom the effective game state). the range of possibilities is much smaller and much closer to what the player sees on his screen
What exactly do you mean by "unlimited lag compensation" ?? That's not a universally known or documented term.
Not everything is lag compensated in NS2, if that was what you were implying?
And structurally, it is implemented in the same way as other fast paced games like TF2, Warsow, Q3, and Tribes. (and ofc slower ones like CS and COD)
Soooo it's pretty fair to say what is being utilized IS the standard.
The only difference is that some (non hitscan) items like the flamethrower or rockets are not compensated in these games... but really it's not like NS2 Marines have a rocket launcher; their main weapons are all hitscan so there wouldn't be much perceived improvement by changing this.
I'm not calling for you to completly rewrite the netcode and fall back to HL1 standards. I'm just saying that the netcode feels worse than other state of the art games and even worse than HL1. Moreover, since it seems to cost so much server-side performance I don't think it is worth it.
PS: What the interpolation i was talking about does is to calculate the position an entity would have on the server's game reality by the time a shot delayed by your latency would reach it.
if such a limit exists, then what is it?
500 ms?
10 server updates?
some other unit of measurement?
is it different for different weapons?
another way to ask it might be:
what's the maximum amount of time that a server is allowed to go back (in order to check whether a client hits something) after a shot has been submitted?
What you are referring to is the current delayed update of entity positions to the other player - which would occur with any authoritative server setup that understandably doesn't trust the client.
The side effect of lag compensation in any game is that the attacker has a slight advantage over the retreating player because each player sees itself in the present but sees the other entities in the past.
This means a skulk has the advantage walljumping around the corner - but has the disadvantage when trying to escape to cover.
It's a pretty fair trade off for hitting what you aim at.
That is prediction then, not interpolation.
Entity interpolation doesn't predict future positions at all – it uses only real entity data provided by the server, thus showing the other entities slightly delayed in time - it's a safety net that provides smooth entity movement despite network hiccups. Here's great 3 part article on the subject.
2 frames afaik I guess I don't know?
there's no way it's that low
that would be 66 ms at an updaterate of 30/sec
it would mean you would have to start leading shots at 66 ping
But what's so wrong with hitting something you aim at?
Even players connecting from other continents typically only reach around 220 ms.. only an extra 100 ms from connecting to the other side of my own country.
So what is this concern for "unlimited" lag compensation?
it reverses the balance of the game in terms of attack & defense (see example in first post) or movement vs stealth
even if the game has some extremely generous cap like 200 ms (many fast games use <100), it would at least guarantee that a player with 50 ping would never receive more than ~250 ms of damage from a single opponent before being notified about it
right now marines get bit twice before their clients (or the commander's client) even registers the first one
aliens lose expensive lifeforms because their effective HP (what the marine client sees) is reduced much earlier than the alien gets any indication of that happening
you basically play the game a completely different way depending on the pings of your opponents.
and when your opponents all have different latencies, you get confused and don't know whether to engage or retreat
instead, the game should be more intuitive. if you have to adjust your playstyle, it should be more about your own ping to the server and less about your opponents' pings
the game is designed so that there are many situations where staying alive is way more important than getting a kill. the netcode should complement that game instead of just favoring combat at the expense of survival
there are solutions to deal with scenarios where rendered models lag behind the true hitboxes (prediction)
there is no solution to deal with scenarios where your rendered HP lags behind the true HP
Even in the days before lag compensation that sentence holds true (even moreso)
How exactly?
Authoritative server + Lag compensation + interpolation + prediction isn't perfect - but it's as good as it gets today.
There aren't any better solutions out there. If you know of any please suggest them.. but if you only have "it should be more about your own ping to the server" then that just doesn't work for any game that isn't insanely popular where you can easily play with people within close distances. It also comes with the HUGE downside of not hitting what you aim at... an important consideration when you are suggesting that the game "should be more intuitive".
not really. I don't have to worry about other peoples' ping when I play other FPS games
I only have to think about what weapons I use based on my own ping to the server
the main reason is that the client and server don't have radically different gamestate in those games due to better netcode in general (including capped lag compensation)
also there isn't really this whole melee vs ranged asymmetry
the solution is to enforce that whenever a client receives an update from the server, that game state is always a 100% accurate representation of all actions taken excluding the past <ping> + <lag compensation limit>
that means if I get an update within 50 ms (ping of 50), and the lag compensation limit is 80 ms, people can only do 130 ms of actions before I get a chance to respond
you never have to worry about receiving a ton of damage that your client hasn't registered yet
it allows for wonderful things like actually being able to dodge projectiles or actually running away before you take lethal damage
in most of these games, projectiles actually get even more accurate netcode so that they are dodge-able (unlike NS2 GLs)
you will still die around corners to hitscan weapons, but instead of dying from half a second of damage (eg. NS2), you will at most die from an extra 130 ms of damage
as long as your latency is below the lag compensation limit, you still shoot exactly what you see on screen
if you are slightly over it, you can get by by shooting at predicted models
people tested and tuned these solutions for over 10 years
I'm not saying that 80 ms of lag comp is the best limit for NS2, but there should be some limit so that people can at least learn how to play the game intuitively + properly instead of just randomly winning or losing engagements based on opponents' pings
As an example, early game I tend to drop dead after what appears to be one bite from a skulk. If I check, it often turns out it was someone with 100+ ping.
I would assume that its because while I think I moved away before the skulk got to me, in his time line he landed some of the damage before I even turned around.
With high ping it becomes less about reacting and more about moving unpredictably and being the first to strike. HIgher ping servers are a great equalizer in a way.
Nb. Getting three bites off in one go would need a latency over 450ms (two bites still in transit, one conveyed).
Not uncommon, not exactly pervasive either. I can't objectively say if it's the game or under-performing servers that allow 250ms ping players.
Have this every time I play. Skulks are just like frikin nades early game: they jump and explode in your face.
I used to play games like Zombie Panic source and GMod Murder. Melee combat there raised no questions.
Woooo Zombie Panic Source! I coded the grenade cooking in that.
Can't speak for murder but Zombie Panic has slowly lumbering zombies, they're far from lerk, fade or skulk speed. Plus Source netcode is just exceptionally well done.
Nb. can we bribe someone to mod in the ZPS panic button for marines? Explode your gear in all directions and get a short speed boost for a few seconds. Include the scream and I'll give you a cookie.
But events like the WC have shown that this function is not really working the way it is intended to work. Meaning yes players with a ping of above 200 ms or ping delta jitters of above 50 ms sometimes have a unfair advantage against normal players as there movements get pretty hard to predict for the normal players and they do things like sudden jumps and direction turns etc. .
That's basically the reason there exists the shine plug-in "Ping Tracker". Beside this issue there is another one you see specially when it comes to grenades projectiles.
The flight way of grenades it not networked (only the event of it getting fired and exploding and hitting something. The hole flight movement gets predicted at the client. So this ends up to be incorrect with what the server calculates due to the facts that first the client might miss some updated situation and that the grenade prediction code has some smaller issues.
So you end up with the grenade exploding somewhere else than you would suspect it in the end because the flight ways of the grenade differ at the client from what the server calculated. This should not happen.
Same btw is kinda also true with the whips sometimes at the moment. But currently nobody of the cdt has time to really look at the grenade prediction code (even if we should at some point) or the lag compensation in the net-code.
So until then we try to solve the situation with some smaller tweaks like this (https://trello.com/c/DJnlDPE6/603-increase-visual-scale-of-the-gl-rounds-and-add-make-it-highlighted-in-av ). Kind of the major reason ppl get hit by grenades even as they might think they would not because the physic model of the grenades is larger than the visual.
Talking about bigger hitboxes, I love the pulse grenade, the hitbox feels as big as a volkswagen beetle!
The main issue are not really player with constantly high pings but ppl whose ping jitter a lot. Because actually you can use "jittering" to get a unfair advantages in a combat in-game and I've sadly already seen players using this technique.
Therefor imho high "ping jittering" has to be reviewed in case of ns2 the same way as cheating.
If server performance wasn't an issue and we spent time ironing out bugs, there'd be no discernable difference between the fps games you play and ns2 once we increased the rates.
To drive this point home : if we mimicked quake live's original implementation of "unlagged" that engaged lag compensation beyond 80 ms, (iirc that's no longer the case?) which I presume is where you got this idea from... And this is all we changed.. You'd still have the same issues of receiving tons of damage before it registers on your client!
Now, if you wanted instant updates then you have to trust the client - something that has invited cheaters and ruined most games that have done this. Bf3 had to hire an entire 10 man team dedicated to battling these cheaters because of this setup.. And still that game had horrendous hit reg issues
high ping players can do more "surprise" damage than low ping players
it's supposed to be "balanced" because high ping players will also receive more "surprise" damage
but the game is asymmetrical so that "balance" doesn't really translate to anything objectively balanced
it's just an asymmetrical set of pros and cons
yeah. unlagged netcode will make it much harder (sometimes impossible) to react in time to stuff like that
if you play this scenario from the skulk's perspective, you can do really stupid things like move up to the marine in a straight line on the floor, except it's not that dangerous because you will land 2 bites before the marine's client reacts
the weird thing is 100-200 ping shouldn't result in so much timeshift between client & server.
you would expect that behavior from 400 ping maybe. that's why people say 100-200 ping in NS2 is like 300-500 ping in a normal game
in source engine you can make a script that switches your interp between 33 and 500, forcing enemy player models to freeze in time for the difference. it's pretty funny for when you're playing a hitscan class such as sniper or scout in tf2.
alias +interp "cl_interp_ratio 2; cl_interp .5"
alias -interp "cl_interp .033"
bind +interp <key>
for anybody who's looking for a lolarbears time. i doubt they've fixed it. edit: as soon as I clicked save comment I remembered that they made it so you can't change interp while inside of servers anymore, oh well.
i'm not comparing unlagged to NS2
that was a quake 3 mod which became obsolete once someone introduced lag compensation limits. a limit of 80 ms made its way into quake live in early beta
even if NS2 updated 120/sec (8 ms) instead of 30/sec (33 ms), it would only account for 25 ms of damage
compared to QL which uses 40/sec (25 ms), it's only 8 ms of damage
low numbers like that aren't even the issue when we're talking about multiple hundreds of ms
Quake live doesn't have interpolation AFAIK, so there's 100 ms of difference right there.
In quake live, the now cheat protected server update setting of cl_maxpackets is 125 (8 ms) .. compare that to NS2's 50 ms.
I am sure there is another 100 ms of delay somewhere (i recall matso breaking down all the delays once) but right there, that's an extra 140 ms of delay, not counting latency or differences in lag compensation.
Another way to look at it is compared to Quake live, NS2's update rates add a delay which is 70% of the average gamer's reaction time.