The Quake3 engine used a 50ms interp equivalent in order to have two server updates to interpolate between (that's why its called interp), as Q3 servers by default sent 20 updates per second, same as NS2 does now. NS2 follows the Source lead and adds another 50ms in order to avoid problems with packet loss and latency variations.
So the major difference between Q3 and NS2 is an extra 50ms interp, which translates to about 0.4-0.8m distance at the speed of lerks or fades.
Is it possible for the devs to allow server operators to modify the updaterate, maxsendrate and tickrate?
It would be good to at-least match the Q3 if not surpass it. Q3 was made with 56k/ISDN/early ADSL as the common internet benchmark at the time.
In fact only recently did valve allow you to change the max send rate to 100,000 in goldsrc games.
I know it might bring in the server owner claims of "1000fps 100tick" into the titles of some servers but the advantages for competitive play where every ms has the potential to change a game greatly outweighs that.
I think the reason they are not variable right now is because of the poor (not the best anyway) optimisation of the network code, meaning if they let people lower the interp variable a lot more connection problems like packet loss could pop up.
Not entirely sure about anything I just said so don't quote me on it, just what I recall reading somewhere.
I have a question - given that internet connections have improved significantly year on year (in all terms, bandwidth, latency & packet loss/jitter all improving) why are UWE adding more interp than in previous FPS engines to NS2?
It honestly is the most annoying aspect of this game by a large margin for me. You can die as a skulk almost the exact moment a player appears on your screen if you aren't moving. But moving attracts their attention, so you either don't move and instantly die if they spot you, or move and ruin your chance at an ambush. It makes doing evasive movement a guessing game rather than a skill game. You jump around trying to just be as awkward as possible, rather then trying to stay out of their cone of fire. Because the model doesn't even have to be facing you to be taking damage. I cannot even begin to imagine how damaging this is on a competitive LAN environment where pings will be <10ms in reality, then interped upto 100ms - this is madness?!
I do not understand why you have set the default levels so high. I regularly ping 12-30ms to UK servers. I rarely see people above 50ms. So they are all suffering from an assumption that we are all still on ISDN or good 56k modems (120ms pings)
I have a question - given that internet connections have improved significantly year on year (in all terms, bandwidth, latency & packet loss/jitter all improving) why are UWE adding more interp than in previous FPS engines to NS2?
Internet connections haven't improved significantly in latency, which is the only thing that matters. The speed of light has been an obstacle since like 2003.
As for previous engines, in the general case, its important to remember that at the moment, Spark is basically a melee combat engine. The difference between ray/object collisions and object/object collisions really can't be understated, and is something that will probably never be able to be done perfectly.
As to why gldsrc might have been able to do it in a superior fashion. I'm not entirely sure that's true. Either way, the massively increased complexity of the game should be enough of a reason as to why its no longer as simple as that.
When HL1 was released, most people were on 56k or ISDN if they were lucky. The netcode for that felt far superior and induced less interp than the NS2 engine does now. ADSL and Cable have significantly higher penetration than they used to. Bandwidth is massively up in most area's. Obviously there are still out layers, there always will be. But this seems like a huge step backwards to me.
I honestly do not understand how a melee combat engine differs from an ranged one, it's still all hit detection cone of fire calculations, just ranged weapons with a short maximum range to imitate melee, or melee weapons with an infinite range to imitate ranged. since all of the previous engines also had melee weapons that were used frequently.
As for significantly more complicated, the only part of NS2 which I can see as being more complicated is the cyst mechanic and power calculations, please explain to me this complexity which forces us all to have a 100ms penalty.
It's still an FPS game, it might be sending more data, but due to aforementioned increase in bandwidth that shouldn't be holding us all hostage to such a huge latency assumption. Something else is going on here.
But right now it just feels bad to play, no matter what your ping. In previous games, lower ping = felt better. In NS2 everyone is tarred with the equality brush of it feels sluggish compared to every twitch fps game I've played in the last 10 years
You will have to explain in simpler terms why ray-object/object object collision are not understood and are a problem here. I'm pretty sure engines and netcode have been dealing with hit detection and model collision for a very long time to say its not understood doesn't add any weight to your point of complexity or explain why the netcode in NS2 feels so poor in comparison to other many other games games which have extremely similar play
NB: I'm in no way trying to lay into UWE on this, I cannot even begin to appreciate the complexity that creating a game, and a whole game engine involves, and they have done an amazing job. However, I believe this is valid criticism and holding your game back. Dying around a corner so frequently, and being unable to react to a player coming around a corner because you already died on their screen so you die on yours after you flinch is NOT fun. It lowers the skill ceiling to "always be flinching" rather than tactically moving in response to stimulus. Right now you can fade in behind someone, swipe while on your screen they aren't looking at you and take full shot gun blast to the face. If there is a valid reason why you cannot lower these assumed latencies in your engine please explain to us why. If not please tell us you are working on it. Because right now frankly, it's horribly frustrating and a painful experience, and as players get better at aiming and moving. They are only going to notice it more and more.
it doesn't matter even if your interp is at 0. if someone else has theirs set to 100ms, then they will still shoot your 'server ghost' all the same.
in this first-person clip of tf2 my interp is 33ms:
everyone should have the same interp to maintain consistency, and unless i'm mistaken there's a server setting to change that.
it doesn't really improve hit reg either. i've experimented with many different interp values in tf2 over ~2800 hours and the only solid improvement of lower interp is visual syncronisation - the consistency is still exactly the same. tf2 hitreg is an utter joke, perfectly aimed sniper rifle/scatter gun shots tend to inexplicably miss about 30% of the time - i don't fancy mimicking that rubbish in ns2.
i would like to try a universal 50ms interp, making projectiles more responsive and dodging melee attacks a lot easier. but like i said - consistency is the most important factor.
I honestly do not understand how a melee combat engine differs from an ranged one, it's still all hit detection cone of fire calculations, just ranged weapons with a short maximum range to imitate melee, or melee weapons with an infinite range to imitate ranged. since all of the previous engines also had melee weapons that were used frequently.
You run into the problem all the time, excuse the pun. Have you ever noticed how, even in games with pretty meager 50ms+- pings, when "physically" running into other actual players you tend to do what looks like rubber banding. This is because other player controlled entities are essentially like probability clouds, rather than concrete objects. They could be anywhere.
Sure, the game shows them as being where you currently see them, and this works fine from a distance. The problem arises when you need to interact with them directly. Your client will perform its client side compensation, which works well for static objects like walls and crates, and will say "you bumped into the player when you tried to go through position X". The server will then receive the information and be like "no no no, the player wasn't even at X, and besides you were totally at Y, so now I'm going to send you to Z". Then the client gets this information, for a scenario it has already played out, and its all like "oh".
For hit trace weapons, which are aproximated with nothing more than a line, no player is aware of the collision entity. There's no big line flying across the stage, and you don't really know where the other person was aiming, so you accept what happens. This is also true for very fast moving projectiles, like bullets in BF3. However, when you start having to interact with very slow moving things, like players, and even spit, things start to get weird.
As for gldsrc's apparent superiority with regards to this. I'm not completely sold. I know for a fact that I remember a lot of NS1 being far better than it actually was.
unless i'm mistaken there's a server setting to change that.
There is no option at the moment, because like I stated earlier, the current network engine would have bad results (often but not always, or at least frequently enough) with any less interp than it is set at now.
Arguing the semantics of how hit-reg and interpolation with conjecture and not evidence is a waste of time. Anyone can say they "felt" hit-reg was better with low/high interp or on a completely different engine.
No one except for the devs can say with any actual evidence if tweaking the updaterate, interp or maxrate will improve or degrade anything so it's a wasted discussion.
At least in Source and GoldSrc games Valve were kind enough to allow server operators and players the ability to tweak and experiment those key values away from the default to find something more responsive.
I only ask that UWE give us the ability to do the same in NS2 so that the competitive scene can further refine the default NS2 experience for it's needs.
it doesn't matter even if your interp is at 0. if someone else has theirs set to 100ms, then they will still shoot your 'server ghost' all the same.
I would like to try a universal 50ms interp, making projectiles more responsive and dodging melee attacks a lot easier. but like i said - consistency is the most important factor.
I know it depends on the other players, and your final point is something I would like as well. Allow it's not even about hit-reg to me, it's about response to stimuli. I don't have the choice to respond to being shot, because I've already taken 11 bullets by the time I am informed about the first one hitting me. This isn't a hit reg issue. It's a notification delay issue. Hence reduce the forced interp down from 50/50 to 25/25 or 50/25 or 25/50, just change/fix something as right now its just crazy
I do NOT want this to be a user-changable setting, as that opens a whole can of worms of people abusing it (welcome to gldsrc) but right now it's to far the other way, it's set to high and its disruptive to fun imo.
I honestly do not understand how a melee combat engine differs from an ranged one, it's still all hit detection cone of fire calculations, just ranged weapons with a short maximum range to imitate melee, or melee weapons with an infinite range to imitate ranged. since all of the previous engines also had melee weapons that were used frequently.
You run into the problem all the time, excuse the pun. Have you ever noticed how, even in games with pretty meager 50ms+- pings, when "physically" running into other actual players you tend to do what looks like rubber banding. This is because other player controlled entities are essentially like probability clouds, rather than concrete objects. They could be anywhere.
Sure, the game shows them as being where you currently see them, and this works fine from a distance. The problem arises when you need to interact with them directly. Your client will perform its client side compensation, which works well for static objects like walls and crates, and will say "you bumped into the player when you tried to go through position X". The server will then receive the information and be like "no no no, the player wasn't even at X, and besides you were totally at Y, so now I'm going to send you to Z". Then the client gets this information, for a scenario it has already played out, and its all like "oh".
For hit trace weapons, which are aproximated with nothing more than a line, no player is aware of the collision entity. There's no big line flying across the stage, and you don't really know where the other person was aiming, so you accept what happens. This is also true for very fast moving projectiles, like bullets in BF3. However, when you start having to interact with very slow moving things, like players, and even spit, things start to get weird.
As for gldsrc's apparent superiority with regards to this. I'm not completely sold. I know for a fact that I remember a lot of NS1 being far better than it actually was.
These are all known issues which have been dealt with for along time in game engines. This doesn't make NS2 any more or less complicated than other online games with collision. I'd rather rubberband a tiny bit more, and have some hope of responding to being shot before I'm already dead, or when a Marine isn't even facing in my direction than the current situation.
it doesn't matter even if your interp is at 0. if someone else has theirs set to 100ms, then they will still shoot your 'server ghost' all the same.
I would like to try a universal 50ms interp, making projectiles more responsive and dodging melee attacks a lot easier. but like i said - consistency is the most important factor.
I know it depends on the other players, and your final point is something I would like as well. Allow it's not even about hit-reg to me, it's about response to stimuli. I don't have the choice to respond to being shot, because I've already taken 11 bullets by the time I am informed about the first one hitting me. This isn't a hit reg issue. It's a notification delay issue. Hence reduce the forced interp down from 50/50 to 25/25 or 50/25 or 25/50, just change/fix something as right now its just crazy
I do NOT want this to be a user-changable setting, as that opens a whole can of worms of people abusing it (welcome to gldsrc) but right now it's to far the other way, it's set to high and its disruptive to fun imo.
erm... why not adjust your stimuli to when a marine is looking at you, instead of waiting for him to shoot you?
if anything it's marines who suffer most of all from 100ms interp, because with 100ms you have to pre-emptively dodge all melee attacks. juking skulks as marine would be much easier, as you could more accurately react to the skulk jump/position instead of 100% prediction jukes.
erm... why not adjust your stimuli to when a marine is looking at you, instead of waiting for him to shoot you?
Forgive my ignorance, but isn't the answer to this that you can't adjust to something that hasn't happened on your screen yet? Compounded by the fact that they started shooting more than 0.2 seconds ago by the time you get the information. Being killed by someone looking the other way is infuriating, and it *does* happen a lot in NS2. Now I've never been a player for setting up ambushes, and I wonder if part of that is simply that you tend to stay alive better on pubs if you never, ever stop moving, even if that means you can be heard (another reason I love silence).
erm... why not adjust your stimuli to when a marine is looking at you, instead of waiting for him to shoot you?
if anything it's marines who suffer most of all from 100ms interp, because with 100ms you have to pre-emptively dodge all melee attacks. juking skulks as marine would be much easier, as you could more accurately react to the skulk jump/position instead of 100% prediction jukes.
Because you don't even get time for that, if you are stationary, a marine can round a corner, and put enough bullets into you that you are dead before you have time to react because his frame of reference in this instance (moving from around a corner to view you and fire) counts just as much as yours (seeing him come around a corner) except his is deadly and yours is passive evasion which you are unable to perform due to him already killing you.
erm... why not adjust your stimuli to when a marine is looking at you, instead of waiting for him to shoot you?
Forgive my ignorance, but isn't the answer to this that you can't adjust to something that hasn't happened on your screen yet? Compounded by the fact that they started shooting more than 0.2 seconds ago by the time you get the information. Being killed by someone looking the other way is infuriating, and it *does* happen a lot in NS2. Now I've never been a player for setting up ambushes, and I wonder if part of that is simply that you tend to stay alive better on pubs if you never, ever stop moving, even if that means you can be heard (another reason I love silence).
I agree it does make silence extremely important/powerful but that doesn't address the issue of movement - movement attracts the human eye, we are designed to pick it out extremely quickly from a static scene. Staying still is a valid form of camo if you are in the shadows but if you aren't moving in NS2, you are already dead. So you cannot setup an ambush using shadows because you cannot respond to the player turning around to look at you, because by the time his model starts turning, he's already turned, by the time you think he's looking at you, you are already dead.
No one except for the devs can say with any actual evidence if tweaking the updaterate, interp or maxrate will improve or degrade anything so it's a wasted discussion.
At least in Source and GoldSrc games Valve were kind enough to allow server operators and players the ability to tweak and experiment those key values away from the default to find something more responsive.
I only ask that UWE give us the ability to do the same in NS2 so that the competitive scene can further refine the default NS2 experience for it's needs.
This is what I've been saying all along. UWE wants to be friendly to Americans and Europeans, they want to be friendly to competetive and casual and they want to be mod friendly.
If they truly want to strive for this, making interp a server side setting is imo a given choice.
Hell, they could just include the options to switch between 100, 75 and 50. That would be good enough for me! Just let us try it out.
I fully understand why it shouldn't be a client/player setting though and I would not support that at all.
Matso wrote:
"The Quake3 engine used a 50ms interp equivalent in order to have two server updates to interpolate between (that's why its called interp), as Q3 servers by default sent 20 updates per second, same as NS2 does now. NS2 follows the Source lead and adds another 50ms in order to avoid problems with packet loss and latency variations.
So the major difference between Q3 and NS2 is an extra 50ms interp, which translates to about 0.4-0.8m distance at the speed of lerks or fades."
Packet loss? This is 2013! The only people suffering from packet loss have really, really awful ISPs which most people don't have anymore. Latency variations? This is voluntary. Yes, yes I know there are for example south americans who can only play north american servers or asians who can only play on australian servers. Here's the thing though; if it's a setting, you can both please those guys with having 100ms or even higher interpt on those servers and let the europeans and north americans that consistently play with around or below 50 ping actually play at that ping. The game is being advertized as an old school shooter but having this kind of heavy interp will scare away players who come from quake, UT, cs 1.6, hldm - the old school shooters!
I don't see where all this worry for packet loss and latency variations comes from. Let us, the players and server admins worry about that. Please. In my eyes this is something you, UWE, would want to do as well since it would greatly benefit competetive play without harming public play. Pub servers would most likely not lower the interp because of the varied crowd.
If you tried it like I suggested, to include the options between 100, 75 and 50 interp - it wouldn't be messed with too much either.
I honestly do not understand how a melee combat engine differs from an ranged one, it's still all hit detection cone of fire calculations, just ranged weapons with a short maximum range to imitate melee, or melee weapons with an infinite range to imitate ranged. since all of the previous engines also had melee weapons that were used frequently.
You run into the problem all the time, excuse the pun. Have you ever noticed how, even in games with pretty meager 50ms+- pings, when "physically" running into other actual players you tend to do what looks like rubber banding. This is because other player controlled entities are essentially like probability clouds, rather than concrete objects. They could be anywhere.
Sure, the game shows them as being where you currently see them, and this works fine from a distance. The problem arises when you need to interact with them directly. Your client will perform its client side compensation, which works well for static objects like walls and crates, and will say "you bumped into the player when you tried to go through position X". The server will then receive the information and be like "no no no, the player wasn't even at X, and besides you were totally at Y, so now I'm going to send you to Z". Then the client gets this information, for a scenario it has already played out, and its all like "oh".
For hit trace weapons, which are aproximated with nothing more than a line, no player is aware of the collision entity. There's no big line flying across the stage, and you don't really know where the other person was aiming, so you accept what happens. This is also true for very fast moving projectiles, like bullets in BF3. However, when you start having to interact with very slow moving things, like players, and even spit, things start to get weird.
As for gldsrc's apparent superiority with regards to this. I'm not completely sold. I know for a fact that I remember a lot of NS1 being far better than it actually was.
These are all known issues which have been dealt with for along time in game engines. This doesn't make NS2 any more or less complicated than other online games with collision. I'd rather rubberband a tiny bit more, and have some hope of responding to being shot before I'm already dead, or when a Marine isn't even facing in my direction than the current situation.
If what I said is even the reason for the extra interp, then its not quite as simple as a little bit of rubber banding. The entire game revolves around player/player collisions. Every bite or slash or gore is just a player collision by proxy. In my opinion, the current situation where dead accurate bites are considered glancing is quite bad. It has the potential to become much, much worse.
Also, 33 ms is still a lot of interp, setting it to the engine limit (14.9-15.2 ms) for 66 or 67 your choice tic would make it so shooting the models is a better option for you. The server could have been dropping ticrates right there and you wouldn't even know, especially if it goes above the source engines limit of 24 players. Not to mention you could have been dropping packets as well
Mhh... I agree, that the server should be able to change the value.
In Germany, the average ping is really only 30-50. Thats because the Internet-infrastructure is very good and the country is smaller. I can understand that the USA average ping is higher. But to cater to both groups, a server-changeable value would be better.
I know, that netcode in games is a huge bunch of magic. Starting by interpolation over estimating where players will be, to trying to create the illusion of real time. It is a little miracle that all those tricks work to get you the illusion of playing in the same world with the other players. (And I have read Valves approach and many other information that gets into the OSI layers and even how you implement it with C++ and C#) But laws of physics prohibit real real-time on a server and so we will always have this "shot around corner"-problem. The question is: Can we mitigate it.
Another approach could be, to dump the "attacker advantage". Why having hitscan weapons anyway? It's even more realistic when you have to aim ahead a moving target. Laws of physics and stuff! So if you see him closing in to a corner you know you can't hit him anymore, because you would need to lead the target and where you would have to shoot is a wall right now. This would be more fair in this cases. But sadly it's no solution for NS2. First because of melee-battle (that needs to be hitscan, there is no bullet-travel time) and second because a change of having to lead targets is way to late and would be a huge changeover for all players.
Allowing client side configuration of rates and interp might be worth looking into. Add it into option settings with the highest rates and lowest interp as a slide bar, with a note saying optimal performance/internet connection (or 40 ping) and vice versa. Would have to test the max rate and lowest interp allowed on LAN setting with good comps, and set the min rate and highest interp allowable to something that works on less than optimal computers and internet connections. Maybe even chain the two slide bars together. Avoiding abuse can be handled by constraining the min and max of the variables.
*But this is just brainstorming, as I'm sure there are better ways of handling this. Knowing that interp is set high will definitely affect games on LAN with everyone's ping being that low. It won't affect much, but interp will be the largest factor of disparity.
It is frustrating to get glancing bites when you are behind them and they are not responding. Being unable to dodge melee attacks with even jetpacks. Or the worst is, when your shotgun goes off but no damage is dealt. <-- That happens a great deal and really captures in a nut shell the disparity. Older games in HL1 didn't have that problem. Something has to give.
erm... why not adjust your stimuli to when a marine is looking at you, instead of waiting for him to shoot you?
Forgive my ignorance, but isn't the answer to this that you can't adjust to something that hasn't happened on your screen yet? Compounded by the fact that they started shooting more than 0.2 seconds ago by the time you get the information. Being killed by someone looking the other way is infuriating, and it *does* happen a lot in NS2. Now I've never been a player for setting up ambushes, and I wonder if part of that is simply that you tend to stay alive better on pubs if you never, ever stop moving, even if that means you can be heard (another reason I love silence).
it's not difficult, imagine a scenario where you're attacking an RT:
you should expect that a marine will be approaching*, and you should also expect that he pre-emptively knows you're going to be taking cover behind the RT. therefore you should expect he knows that he can shoot your leg through the base of the RT. your adjustment should be to listen out for footsteps, and when they get close your offensive options are either deciding to remain behind the RT strafing side to side to prevent him getting a free shot and draw him closer; or use shift to silently move into an ambush position.
also, an ambush position doesn't necessarily mean you sit motionless and wait for him to step on the X-spot. your adjustment here is to use intuition** to hop down and bite him before he can target you on his screen. in addition, your choice of tactic should be applied based on whether he's a good player or not (how many good players are in the server and their general map location is information you need to know to be at your most effective)
*if you kill a marine in the vicinity of that RT before attacking it (alerting the marines), you can usually assume that he will be the first to respond - and you can 'count' that in your head when you expect him to arrive. if there are multiple marines in the area, you should know this already and be prepared to scarper - and you probably picked the wrong RT to harrass.
**for an example, look at a common melee tactic that medics use in high level comp tf2 (probably the most effective general melee tactic to know actually). they retreat through a door/around a corner out of sight, this suckers people into chasing the 'harmless' medic. while out of sight, the medic switches to melee and does a u-turn running back towards the enemy. knowing that server latency will inhibit even the fastest reaction time - it's an incredibly effective tactic. the precise timing and planning of this tactic, i would call down to intuition.
it's kinda like a fighting game. the good players always have to think what the opponent is going to do - and the opponent is usually going to do whatever is smart in response to what you did/can do. if you play street fighter, you're never going to be very good if you always wait for the opponent to take an action before you 'adjust'.
Interp will contribute to the time gap between what clients and the server sees, but interp should be set based on the frequency updates are received from the server and the variance of those intervals. Interp is a buffer so the client has two snapshots of the server's gamestate to interpolate between. The alternative is the client makes its best guess on how the everything is going to look next update then correct any mistakes when it actually receives the next update, which is decidedly inferior to interp.
What I don't understand is why UW decided to set their interp at 100 ms (Is this still accurate?). The target server update rate is 30 updates a second, or every 33.3 ms, so they've decided they need to buffer 3 updates. Even accounting for the server unable to maintain a stable update rate and hiccups in the connection, this is more than necessary.
@tarquinbb that is if you can hear anything over your loud chomping and stopping to bite to listen could mean the difference between downing the rt and not.
erm... why not adjust your stimuli to when a marine is looking at you, instead of waiting for him to shoot you?
Forgive my ignorance, but isn't the answer to this that you can't adjust to something that hasn't happened on your screen yet? Compounded by the fact that they started shooting more than 0.2 seconds ago by the time you get the information. Being killed by someone looking the other way is infuriating, and it *does* happen a lot in NS2. Now I've never been a player for setting up ambushes, and I wonder if part of that is simply that you tend to stay alive better on pubs if you never, ever stop moving, even if that means you can be heard (another reason I love silence).
it's not difficult, imagine a scenario where you're attacking an RT:
you should expect that a marine will be approaching*, and you should also expect that he pre-emptively knows you're going to be taking cover behind the RT. therefore you should expect he knows that he can shoot your leg through the base of the RT. your adjustment should be to listen out for footsteps, and when they get close your offensive options are either deciding to remain behind the RT strafing side to side to prevent him getting a free shot and draw him closer; or use shift to silently move into an ambush position.
also, an ambush position doesn't necessarily mean you sit motionless and wait for him to step on the X-spot. your adjustment here is to use intuition** to hop down and bite him before he can target you on his screen. in addition, your choice of tactic should be applied based on whether he's a good player or not (how many good players are in the server and their general map location is information you need to know to be at your most effective)
*if you kill a marine in the vicinity of that RT before attacking it (alerting the marines), you can usually assume that he will be the first to respond - and you can 'count' that in your head when you expect him to arrive. if there are multiple marines in the area, you should know this already and be prepared to scarper - and you probably picked the wrong RT to harrass.
**for an example, look at a common melee tactic that medics use in high level comp tf2 (probably the most effective general melee tactic to know actually). they retreat through a door/around a corner out of sight, this suckers people into chasing the 'harmless' medic. while out of sight, the medic switches to melee and does a u-turn running back towards the enemy. knowing that server latency will inhibit even the fastest reaction time - it's an incredibly effective tactic. the precise timing and planning of this tactic, i would call down to intuition.
it's kinda like a fighting game. the good players always have to think what the opponent is going to do - and the opponent is usually going to do whatever is smart in response to what you did/can do. if you play street fighter, you're never going to be very good if you always wait for the opponent to take an action before you 'adjust'.
We've played together, tarquin, we both know that's all about game sense!
If we take this back a step to the newbie level: skulk is sat above a doorway. Marine comes through door, looks up and starts shooting. The skulk hasn't moved before it's dead on the marine screen, whereas on the skulk's screen, he saw the marine coming, started jumping in to bite, and then died as though he hadn't done anything.
I absolutely agree that this flies in the face of what you and I would do in this situation, but I use it purely as an example to highlight the fundamental physical aspect of this discussion. Knowing what we do about the game, and about how to game in general, of course prediction is an absolutely essential skill, but the argument being made here is purely about networking: can the current implementation be improved such that the temporal delay between clients can be minimised in a way that maintains 'gaming integrity', however you should wish to define that.
Can the theoretical newbie skulk/marine situation I described be improved so that what the skulk sees and what the marine sees are both closer to what the server dictates actually happened?
The knock-on effect (I would argue the whole purpose!) would be to reduce instances of deaths around corners, of missed/partial bites, and so on in the real world, where we're using game sense, predicting, and trying to guess when to stay to fight and when to run. At the minute, you have to run away far before you might in another game (in my opinion). Now okay, knowing this, I do it. But many players, especially new players, don't - we see a HUGE number of dead lerks and fades and skulks as a result of this, most of which comes down to game sense, but a not-insignificant portion, I would wager, can be attributed at least in part to net performance.
@roobubba i appreciate that, and i'm not trying to claim that the current system is flawless.
however, everyone has the same issue - the difference is that the scrubs blame their suckiness on 'crappy netcode' and the good players actually adapt.
personally, i find that winning the mind games in FPS's is the most rewarding part. there's no greater domination than getting inside your opponents head and knowing what they're going to pull before they know. it's crucial in all decent competitive games; aim is secondary. (although i guess it could be argued that game sense requires so much practice that it's almost impossible for your aim to lack)
In NS2 the interp, the mechanism that tries to put everyone on an even playing field, is set at 100ms. That means that in practice everyone below 100(ms) ping should have the same visuals. This is all well and good apart from one thing. Most players don't play at 100 ping.
It seems that you (and a few other people posting in this thread) have a faulty understanding of what "interp" actually is. Interp has nothing to do with "evening the playing field" and it is certainly not about making all players with less than 100 ms ping get the same visuals at the same time.
Interp is short for interpolation, which, in layman's terms, means to fill in the gaps between 2 points.
In NS2, the rate at which the server sends update messages to clients is 20 messages per second (or one message every 50 milliseconds). If the game did not do interpolation, all the other players in your view would appear to jitter around at 20 FPS even if your graphics card was rendering a nice, smooth 100 FPS.
In order for the movement of other players to appear smooth, the game needs to interpolate between 2 update messages. Unfortunately, that means that the game can't immediately display the game state according to the most recent update message that it received. In order for the game to always have 2 update messages to work with, it needs to hold them in a buffer that is long enough to contain at least 2 update messages.
Given that update messages are received every 50 ms, the theoretical minimum buffer length is 50 ms. However, this would only work in an ideal world where every message can be expected to arrive perfectly on time with zero ping fluctuation. In the event that an update message was late, the game would have to start guessing in the mean time. By using a 100 ms buffer, you can be sure that there will always be 2 update messages in the buffer and, in super-ideal cases, there might even be 3.
In order to reduce the interpolation buffer length, UWE would first have to increase the rate at which update messages are sent. I don't know what the implications for that might be (in terms of server or client performance, bandwidth usage, etc.)
Comments
Is it possible for the devs to allow server operators to modify the updaterate, maxsendrate and tickrate?
It would be good to at-least match the Q3 if not surpass it. Q3 was made with 56k/ISDN/early ADSL as the common internet benchmark at the time.
In fact only recently did valve allow you to change the max send rate to 100,000 in goldsrc games.
I know it might bring in the server owner claims of "1000fps 100tick" into the titles of some servers but the advantages for competitive play where every ms has the potential to change a game greatly outweighs that.
Not entirely sure about anything I just said so don't quote me on it, just what I recall reading somewhere.
It honestly is the most annoying aspect of this game by a large margin for me. You can die as a skulk almost the exact moment a player appears on your screen if you aren't moving. But moving attracts their attention, so you either don't move and instantly die if they spot you, or move and ruin your chance at an ambush. It makes doing evasive movement a guessing game rather than a skill game. You jump around trying to just be as awkward as possible, rather then trying to stay out of their cone of fire. Because the model doesn't even have to be facing you to be taking damage. I cannot even begin to imagine how damaging this is on a competitive LAN environment where pings will be <10ms in reality, then interped upto 100ms - this is madness?!
I do not understand why you have set the default levels so high. I regularly ping 12-30ms to UK servers. I rarely see people above 50ms. So they are all suffering from an assumption that we are all still on ISDN or good 56k modems (120ms pings)
Internet connections haven't improved significantly in latency, which is the only thing that matters. The speed of light has been an obstacle since like 2003.
As for previous engines, in the general case, its important to remember that at the moment, Spark is basically a melee combat engine. The difference between ray/object collisions and object/object collisions really can't be understated, and is something that will probably never be able to be done perfectly.
As to why gldsrc might have been able to do it in a superior fashion. I'm not entirely sure that's true. Either way, the massively increased complexity of the game should be enough of a reason as to why its no longer as simple as that.
I honestly do not understand how a melee combat engine differs from an ranged one, it's still all hit detection cone of fire calculations, just ranged weapons with a short maximum range to imitate melee, or melee weapons with an infinite range to imitate ranged. since all of the previous engines also had melee weapons that were used frequently.
As for significantly more complicated, the only part of NS2 which I can see as being more complicated is the cyst mechanic and power calculations, please explain to me this complexity which forces us all to have a 100ms penalty.
It's still an FPS game, it might be sending more data, but due to aforementioned increase in bandwidth that shouldn't be holding us all hostage to such a huge latency assumption. Something else is going on here.
But right now it just feels bad to play, no matter what your ping. In previous games, lower ping = felt better. In NS2 everyone is tarred with the equality brush of it feels sluggish compared to every twitch fps game I've played in the last 10 years
You will have to explain in simpler terms why ray-object/object object collision are not understood and are a problem here. I'm pretty sure engines and netcode have been dealing with hit detection and model collision for a very long time to say its not understood doesn't add any weight to your point of complexity or explain why the netcode in NS2 feels so poor in comparison to other many other games games which have extremely similar play
NB: I'm in no way trying to lay into UWE on this, I cannot even begin to appreciate the complexity that creating a game, and a whole game engine involves, and they have done an amazing job. However, I believe this is valid criticism and holding your game back. Dying around a corner so frequently, and being unable to react to a player coming around a corner because you already died on their screen so you die on yours after you flinch is NOT fun. It lowers the skill ceiling to "always be flinching" rather than tactically moving in response to stimulus. Right now you can fade in behind someone, swipe while on your screen they aren't looking at you and take full shot gun blast to the face. If there is a valid reason why you cannot lower these assumed latencies in your engine please explain to us why. If not please tell us you are working on it. Because right now frankly, it's horribly frustrating and a painful experience, and as players get better at aiming and moving. They are only going to notice it more and more.
in this first-person clip of tf2 my interp is 33ms:
everyone should have the same interp to maintain consistency, and unless i'm mistaken there's a server setting to change that.
it doesn't really improve hit reg either. i've experimented with many different interp values in tf2 over ~2800 hours and the only solid improvement of lower interp is visual syncronisation - the consistency is still exactly the same. tf2 hitreg is an utter joke, perfectly aimed sniper rifle/scatter gun shots tend to inexplicably miss about 30% of the time - i don't fancy mimicking that rubbish in ns2.
i would like to try a universal 50ms interp, making projectiles more responsive and dodging melee attacks a lot easier. but like i said - consistency is the most important factor.
You run into the problem all the time, excuse the pun. Have you ever noticed how, even in games with pretty meager 50ms+- pings, when "physically" running into other actual players you tend to do what looks like rubber banding. This is because other player controlled entities are essentially like probability clouds, rather than concrete objects. They could be anywhere.
Sure, the game shows them as being where you currently see them, and this works fine from a distance. The problem arises when you need to interact with them directly. Your client will perform its client side compensation, which works well for static objects like walls and crates, and will say "you bumped into the player when you tried to go through position X". The server will then receive the information and be like "no no no, the player wasn't even at X, and besides you were totally at Y, so now I'm going to send you to Z". Then the client gets this information, for a scenario it has already played out, and its all like "oh".
For hit trace weapons, which are aproximated with nothing more than a line, no player is aware of the collision entity. There's no big line flying across the stage, and you don't really know where the other person was aiming, so you accept what happens. This is also true for very fast moving projectiles, like bullets in BF3. However, when you start having to interact with very slow moving things, like players, and even spit, things start to get weird.
As for gldsrc's apparent superiority with regards to this. I'm not completely sold. I know for a fact that I remember a lot of NS1 being far better than it actually was.
There is no option at the moment, because like I stated earlier, the current network engine would have bad results (often but not always, or at least frequently enough) with any less interp than it is set at now.
No one except for the devs can say with any actual evidence if tweaking the updaterate, interp or maxrate will improve or degrade anything so it's a wasted discussion.
At least in Source and GoldSrc games Valve were kind enough to allow server operators and players the ability to tweak and experiment those key values away from the default to find something more responsive.
I only ask that UWE give us the ability to do the same in NS2 so that the competitive scene can further refine the default NS2 experience for it's needs.
I know it depends on the other players, and your final point is something I would like as well. Allow it's not even about hit-reg to me, it's about response to stimuli. I don't have the choice to respond to being shot, because I've already taken 11 bullets by the time I am informed about the first one hitting me. This isn't a hit reg issue. It's a notification delay issue. Hence reduce the forced interp down from 50/50 to 25/25 or 50/25 or 25/50, just change/fix something as right now its just crazy
I do NOT want this to be a user-changable setting, as that opens a whole can of worms of people abusing it (welcome to gldsrc) but right now it's to far the other way, it's set to high and its disruptive to fun imo.
These are all known issues which have been dealt with for along time in game engines. This doesn't make NS2 any more or less complicated than other online games with collision. I'd rather rubberband a tiny bit more, and have some hope of responding to being shot before I'm already dead, or when a Marine isn't even facing in my direction than the current situation.
erm... why not adjust your stimuli to when a marine is looking at you, instead of waiting for him to shoot you?
if anything it's marines who suffer most of all from 100ms interp, because with 100ms you have to pre-emptively dodge all melee attacks. juking skulks as marine would be much easier, as you could more accurately react to the skulk jump/position instead of 100% prediction jukes.
Forgive my ignorance, but isn't the answer to this that you can't adjust to something that hasn't happened on your screen yet? Compounded by the fact that they started shooting more than 0.2 seconds ago by the time you get the information. Being killed by someone looking the other way is infuriating, and it *does* happen a lot in NS2. Now I've never been a player for setting up ambushes, and I wonder if part of that is simply that you tend to stay alive better on pubs if you never, ever stop moving, even if that means you can be heard (another reason I love silence).
Because you don't even get time for that, if you are stationary, a marine can round a corner, and put enough bullets into you that you are dead before you have time to react because his frame of reference in this instance (moving from around a corner to view you and fire) counts just as much as yours (seeing him come around a corner) except his is deadly and yours is passive evasion which you are unable to perform due to him already killing you.
I agree it does make silence extremely important/powerful but that doesn't address the issue of movement - movement attracts the human eye, we are designed to pick it out extremely quickly from a static scene. Staying still is a valid form of camo if you are in the shadows but if you aren't moving in NS2, you are already dead. So you cannot setup an ambush using shadows because you cannot respond to the player turning around to look at you, because by the time his model starts turning, he's already turned, by the time you think he's looking at you, you are already dead.
If they truly want to strive for this, making interp a server side setting is imo a given choice.
Hell, they could just include the options to switch between 100, 75 and 50. That would be good enough for me! Just let us try it out.
I fully understand why it shouldn't be a client/player setting though and I would not support that at all.
Matso wrote:
"The Quake3 engine used a 50ms interp equivalent in order to have two server updates to interpolate between (that's why its called interp), as Q3 servers by default sent 20 updates per second, same as NS2 does now. NS2 follows the Source lead and adds another 50ms in order to avoid problems with packet loss and latency variations.
So the major difference between Q3 and NS2 is an extra 50ms interp, which translates to about 0.4-0.8m distance at the speed of lerks or fades."
Packet loss? This is 2013! The only people suffering from packet loss have really, really awful ISPs which most people don't have anymore. Latency variations? This is voluntary. Yes, yes I know there are for example south americans who can only play north american servers or asians who can only play on australian servers. Here's the thing though; if it's a setting, you can both please those guys with having 100ms or even higher interpt on those servers and let the europeans and north americans that consistently play with around or below 50 ping actually play at that ping. The game is being advertized as an old school shooter but having this kind of heavy interp will scare away players who come from quake, UT, cs 1.6, hldm - the old school shooters!
I don't see where all this worry for packet loss and latency variations comes from. Let us, the players and server admins worry about that. Please. In my eyes this is something you, UWE, would want to do as well since it would greatly benefit competetive play without harming public play. Pub servers would most likely not lower the interp because of the varied crowd.
If you tried it like I suggested, to include the options between 100, 75 and 50 interp - it wouldn't be messed with too much either.
If what I said is even the reason for the extra interp, then its not quite as simple as a little bit of rubber banding. The entire game revolves around player/player collisions. Every bite or slash or gore is just a player collision by proxy. In my opinion, the current situation where dead accurate bites are considered glancing is quite bad. It has the potential to become much, much worse.
We need netgraph open to see anything
Also, 33 ms is still a lot of interp, setting it to the engine limit (14.9-15.2 ms) for 66 or 67 your choice tic would make it so shooting the models is a better option for you. The server could have been dropping ticrates right there and you wouldn't even know, especially if it goes above the source engines limit of 24 players. Not to mention you could have been dropping packets as well
*But this is just brainstorming, as I'm sure there are better ways of handling this. Knowing that interp is set high will definitely affect games on LAN with everyone's ping being that low. It won't affect much, but interp will be the largest factor of disparity.
It is frustrating to get glancing bites when you are behind them and they are not responding. Being unable to dodge melee attacks with even jetpacks. Or the worst is, when your shotgun goes off but no damage is dealt. <-- That happens a great deal and really captures in a nut shell the disparity. Older games in HL1 didn't have that problem. Something has to give.
some one remembers those?
it's not difficult, imagine a scenario where you're attacking an RT:
you should expect that a marine will be approaching*, and you should also expect that he pre-emptively knows you're going to be taking cover behind the RT. therefore you should expect he knows that he can shoot your leg through the base of the RT. your adjustment should be to listen out for footsteps, and when they get close your offensive options are either deciding to remain behind the RT strafing side to side to prevent him getting a free shot and draw him closer; or use shift to silently move into an ambush position.
also, an ambush position doesn't necessarily mean you sit motionless and wait for him to step on the X-spot. your adjustment here is to use intuition** to hop down and bite him before he can target you on his screen. in addition, your choice of tactic should be applied based on whether he's a good player or not (how many good players are in the server and their general map location is information you need to know to be at your most effective)
*if you kill a marine in the vicinity of that RT before attacking it (alerting the marines), you can usually assume that he will be the first to respond - and you can 'count' that in your head when you expect him to arrive. if there are multiple marines in the area, you should know this already and be prepared to scarper - and you probably picked the wrong RT to harrass.
**for an example, look at a common melee tactic that medics use in high level comp tf2 (probably the most effective general melee tactic to know actually). they retreat through a door/around a corner out of sight, this suckers people into chasing the 'harmless' medic. while out of sight, the medic switches to melee and does a u-turn running back towards the enemy. knowing that server latency will inhibit even the fastest reaction time - it's an incredibly effective tactic. the precise timing and planning of this tactic, i would call down to intuition.
it's kinda like a fighting game. the good players always have to think what the opponent is going to do - and the opponent is usually going to do whatever is smart in response to what you did/can do. if you play street fighter, you're never going to be very good if you always wait for the opponent to take an action before you 'adjust'.
What I don't understand is why UW decided to set their interp at 100 ms (Is this still accurate?). The target server update rate is 30 updates a second, or every 33.3 ms, so they've decided they need to buffer 3 updates. Even accounting for the server unable to maintain a stable update rate and hiccups in the connection, this is more than necessary.
Most of the time we really don't need compensation for more than 50 Ping.
rate 25000 was for dial-up, you can use rates of like 10476578 or something now, but yes :P
sv_clockcorrection 0 as well, turns it off server side, then you turn it off client side!
We've played together, tarquin, we both know that's all about game sense!
If we take this back a step to the newbie level: skulk is sat above a doorway. Marine comes through door, looks up and starts shooting. The skulk hasn't moved before it's dead on the marine screen, whereas on the skulk's screen, he saw the marine coming, started jumping in to bite, and then died as though he hadn't done anything.
I absolutely agree that this flies in the face of what you and I would do in this situation, but I use it purely as an example to highlight the fundamental physical aspect of this discussion. Knowing what we do about the game, and about how to game in general, of course prediction is an absolutely essential skill, but the argument being made here is purely about networking: can the current implementation be improved such that the temporal delay between clients can be minimised in a way that maintains 'gaming integrity', however you should wish to define that.
Can the theoretical newbie skulk/marine situation I described be improved so that what the skulk sees and what the marine sees are both closer to what the server dictates actually happened?
The knock-on effect (I would argue the whole purpose!) would be to reduce instances of deaths around corners, of missed/partial bites, and so on in the real world, where we're using game sense, predicting, and trying to guess when to stay to fight and when to run. At the minute, you have to run away far before you might in another game (in my opinion). Now okay, knowing this, I do it. But many players, especially new players, don't - we see a HUGE number of dead lerks and fades and skulks as a result of this, most of which comes down to game sense, but a not-insignificant portion, I would wager, can be attributed at least in part to net performance.
however, everyone has the same issue - the difference is that the scrubs blame their suckiness on 'crappy netcode' and the good players actually adapt.
personally, i find that winning the mind games in FPS's is the most rewarding part. there's no greater domination than getting inside your opponents head and knowing what they're going to pull before they know. it's crucial in all decent competitive games; aim is secondary. (although i guess it could be argued that game sense requires so much practice that it's almost impossible for your aim to lack)
It seems that you (and a few other people posting in this thread) have a faulty understanding of what "interp" actually is. Interp has nothing to do with "evening the playing field" and it is certainly not about making all players with less than 100 ms ping get the same visuals at the same time.
Interp is short for interpolation, which, in layman's terms, means to fill in the gaps between 2 points.
In NS2, the rate at which the server sends update messages to clients is 20 messages per second (or one message every 50 milliseconds). If the game did not do interpolation, all the other players in your view would appear to jitter around at 20 FPS even if your graphics card was rendering a nice, smooth 100 FPS.
In order for the movement of other players to appear smooth, the game needs to interpolate between 2 update messages. Unfortunately, that means that the game can't immediately display the game state according to the most recent update message that it received. In order for the game to always have 2 update messages to work with, it needs to hold them in a buffer that is long enough to contain at least 2 update messages.
Given that update messages are received every 50 ms, the theoretical minimum buffer length is 50 ms. However, this would only work in an ideal world where every message can be expected to arrive perfectly on time with zero ping fluctuation. In the event that an update message was late, the game would have to start guessing in the mean time. By using a 100 ms buffer, you can be sure that there will always be 2 update messages in the buffer and, in super-ideal cases, there might even be 3.
In order to reduce the interpolation buffer length, UWE would first have to increase the rate at which update messages are sent. I don't know what the implications for that might be (in terms of server or client performance, bandwidth usage, etc.)