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
Not that I know of, no. And that'd probably produce feelings of inconsistency.
"I can hit things fine until there's 5 people on screen!" Etc
A huge part why modern online gaming has moved to lag compensation was precisely for consistency. You don't have to know your enemy's latency at that moment in order to determine how far ahead to lead your shots.
You can just aim at them and fire.
Dynamic rates might make it so you can't safely determine or learn when to exit the room alive.
I think the most annoying situations with instant or around the corner deaths are due to laggy servers when you get an instant great amount of damage from rifles/pistols.
I observed not once playing fade/lerk as my hps dropped instantly but not gradually from marines with rifles.
There's a situation, when I fly into the room with marines. They shoot, but I am not observing hits, I continue flying. The next moment I get -200 hps at ones. It's too late to leave the room.
There also moments when I got > 100 hp from one pistol, not gradual 33+33+33.
I'm doing maximum 6 clicks per second. Maybe there's phenomenal men like Wob with 10 clicks per second.
3 shots > 300 msec
That means, that I have more than 300 msec interval between updates from server.
20 send rate = 50 msec. WTF?
I think there were situations when It passed ~1 sec from leaving to death, not 100 msec, as you write there.
100 msec * 15 u/sec = 1.5 unit. It's ok. I don't pay attention to 1 unit around a corner deaths.
HandschuhJoin Date: 2005-03-08Member: 44338Members, NS2 Playtester, NS2 Community Developer
I agree about the lag compensation... with 3G which was instable, I once killed a fade with a full rifleclip.. he didn't even hear 1 bullet come out.. when he was already far away, he was instantly dead.. thats really bullshit, since packages which are to late should not be accepted.. in a smaller scale thats what annoys most ppl about laggers.. in ns1 these packages would not have been accepted and that was fine like that @IronHorse, show you QA quality
Lag compensation wasn't touched, but the hitreg/netcode was slightly, by more thoroughly checking that hits that landed actually did.
Essentially it was just additional checking at the cost of server performance, as well as fixing some underlying problems.
I'm sure there's more details that Matso could give about it, but that was my nutshell understanding of it.
The obvious cases like the meatshot missing against a fast moving fade and still producing green blood etc, should be fixed from 279 onward. (we at least cannot reproduce tests that once produced the issue)
But there were still outliers and edge cases though after 279, (like the last inch of the top/back of a fast moving skulk) and most of those have been solved by utilizing a larger hitbox that's also calculated differently.
I've ran tests using the new hitbox calculation method mixed with the old hitboxes, and there were still the occasional issues even if it was improved.
@Handschuh
I concur that lag compensation should end at ~200 latency. Past that point you'll have to lead the target, and so will he/she.
But personally I feel like the teleporting players from packet loss are much more common than your 300+ latency player, and much more of an issue to engage with. This solution was once developed and tested.. and even though it solved the problem beautifully (see the vids!), it created massive side effects for high latency players connecting from other continents - namely, freezing in place or stuttering only on their screen - and as such it was sadly shelved.
A stable 60 sendrate with proportionally lower interp setting, lag compensation ending at ~200 latency and null move insertion is my personal pie in the sky netcode wishlist that may be somewhat out of reach.
But boy would all that make engagements feel better.
HandschuhJoin Date: 2005-03-08Member: 44338Members, NS2 Playtester, NS2 Community Developer
@IronHorse I'm not talking about players from Australia, but me living in Ger, playing on aa Ger Server with under 100ms latency, having a lagspike about 300-3000+ms for example in a groupfight and killing a lifeform because the other side has no chance to estimate his incoming rifledamage, because it willl come when he is long gone...
Of course you should be able to configure it, considering what clientel is playing on your server.. but still.. these days it looks like there is no cap at all for late packages...
You really shouldn't be playing on a server with 200 ping.
That doesn't really work for small game communities like us. We still have a big enough community where we can mostly do this. I have had to play in EU many times because that was the only server available.
@IronHorse I'm not talking about players from Australia, but me living in Ger, playing on aa Ger Server with under 100ms latency, having a lagspike about 300-3000+ms
You really shouldn't be playing on a server with 200 ping.
That doesn't really work for small game communities like us. We still have a big enough community where we can mostly do this. I have had to play in EU many times because that was the only server available.
You really shouldn't be playing on a server with 200 ping.
That doesn't really work for small game communities like us. We still have a big enough community where we can mostly do this. I have had to play in EU many times because that was the only server available.
There are plenty of servers. Most people refuse to seed. When I play NS2 I try to seed often.
You really shouldn't be playing on a server with 200 ping.
That doesn't really work for small game communities like us. We still have a big enough community where we can mostly do this. I have had to play in EU many times because that was the only server available.
IDEALLY the cutoff point would be 100. With NS2's current state, I think it should be 150.
Is latency compensation server configurable? Maybe that would be something to consider? Cus there's plenty of european players, we don't necessarily need a lot lag compensation for the european servers. And it might also work for competitive to lower that compensation.
Is latency compensation server configurable? Maybe that would be something to consider? Cus there's plenty of european players, we don't necessarily need a lot lag compensation for the european servers. And it might also work for competitive to lower that compensation.
That also sounds like it'd creative an inconsistent environment.
So much of netcode for the individual player is learned timings.. knowing when to get out of the room or knowing how to aim in relation to the enemy.
If any server op could set what they'd want, you'd definitely see some server Op do something foolish and set it to 50ms, and then everyone would be complaining on here or in discord how bad the hitreg is.
It'd be much better to just have a standard that everyone can learn and get used to that is a reasonable number.
Is latency compensation server configurable? Maybe that would be something to consider? Cus there's plenty of european players, we don't necessarily need a lot lag compensation for the european servers. And it might also work for competitive to lower that compensation.
That also sounds like it'd creative an inconsistent environment.
So much of netcode for the individual player is learned timings.. knowing when to get out of the room or knowing how to aim in relation to the enemy.
If any server op could set what they'd want, you'd definitely see some server Op do something foolish and set it to 50ms, and then everyone would be complaining on here or in discord how bad the hitreg is.
It'd be much better to just have a standard that everyone can learn and get used to that is a reasonable number.
Good point, however, what about a compromise here. Allow a few preset options, like: low, medium, high latency compensation, or perhaps just two options? And adjust the serverbrowser so it informs players about this.
I'm perfectly fine with having it server-configurable, as long as it is advertised in some sort of way (either by the server name or the server browser).
dePARAJoin Date: 2011-04-29Member: 96321Members, Squad Five Blue
edited March 2017
Occlusion Culling, Netcode and the way how frames get rendered are the real issues in NS2.
Im pretty sure that a FCAT benchmark would atleast prove my "something is wrong with the frametimes" feeling.
And netcode?
Here are samples how tripleA titles deal with netcode issues:
From my point of view the net rates are way to low for a game where you have to shoot small fast moving targets.
I'm perfectly fine with having it server-configurable, as long as it is advertised in some sort of way (either by the server name or the server browser).
The server browser already tells you that the rates are not default if you join a modificated server.
Problem is you see only a generic info but no details about what rates have changed.
You can disable this little warning and people tend to forget that a server is maybe running on lower rates. (or higher? who knows)
DC_DarklingJoin Date: 2003-07-10Member: 18068Members, Constellation, Squad Five Blue, Squad Five Silver
Technically you can change all those rates right now.
Its just that many server ops did it horribly horribly wrong in the past.
Or picked rates their server can not remotely maintain.
Or lowered interp on a server running inter-continent matches.
Combine that with players throwing around wrong info (blaming x when its y) and rates is a whole big of mess, most server ops (should) stear clear off.
As for frame, well. I have seen weird framespike hitches in plogs plenty of times. One of the best things to do with that is to keep spamming uwe with plogs. (Considering his role I would throw them at ironhorse.)
Make his inbox explode with plogs.
dePARAJoin Date: 2011-04-29Member: 96321Members, Squad Five Blue
I really hope they working on real dx11 implementation and might find the issues with the frametimes.
Im not talking about fps here.
Like i said: Steady 130fps in NS2 just feel different than steady 130fps in Battlefield4.
And cause there is something wrong with the frametimes the whole game feels unresponsive.
Compared to BF it feels like there is some sort of delay when you move your mouse.
I really hope they working on real dx11 implementation and might find the issues with the frametimes.
Im not talking about fps here.
Like i said: Steady 130fps in NS2 just feel different than steady 130fps in Battlefield4.
And cause there is something wrong with the frametimes the whole game feels unresponsive.
Compared to BF it feels like there is some sort of delay when you move your mouse.
Instead of saying what's wrong, maybe you can also add ETA when it's going to be fixed? Or there's no plan of develop and increase the send rate?
It's not as simple as a bug that can be "fixed".
AFAIK it would require significant rewrites and optimizations to the server, networking layer, and refactoring for more LuaJIT. And that's all before we get to the actual part where said changes create whole swaths of new bugs that actually do need fixing. Last time we tested a sendrate of 50 internally, even on a beefy 5 ghz server it was causing all sorts of worldupdate oddities.
So there's no ETA currently because that's just not occurring yet, as there are other priorities in the works right now.
That being said, increasing the send rate has been a target and a desire for the team for a long while now... it's just a lot of work, that's competing with low hanging fruit priorities.
You'll probably see a trello card pop up when /if it starts being worked on.
Instead of saying what's wrong, maybe you can also add ETA when it's going to be fixed? Or there's no plan of develop and increase the send rate?
It's not as simple as a bug that can be "fixed".
AFAIK it would require significant rewrites and optimizations to the server, networking layer, and refactoring for more LuaJIT. And that's all before we get to the actual part where said changes create whole swaths of new bugs that actually do need fixing. Last time we tested a sendrate of 50 internally, even on a beefy 5 ghz server it was causing all sorts of worldupdate oddities.
So there's no ETA currently because that's just not occurring yet, as there are other priorities in the works right now.
That being said, increasing the send rate has been a target and a desire for the team for a long while now... it's just a lot of work, that's competing with low hanging fruit priorities.
You'll probably see a trello card pop up when /if it starts being worked on.
I understand it's nothing you can fix within a few hours, all i'm asking.. If you know that the game would drasticly change in the feeling in terms of hitreg/netcode/smoothness for players. Why isnt this a priority? To be frank i'm baffled over the priorities.. People dont care much about visuals anyway considering it's impossible to maintain a High FPS 144+ with ALL the visuals on if you're not running on a atleast Sandy Bridge with 4.8+ GHz on the 2 first cores.
If i were a developer, i would've want to have the fundemental work done in the game... As performance would be my no.1 priority. (Performance is a fundemental layer that needs to be worked with all the time)
That's why i dont understand why PERFORMANCE is not a priority over at UWE...Doesnt subnautica also suffer from performance issues? (random frame drops)
You say you've tried 5GHz, so i guess there is some kind of logs? Why not start with them?
UWE Department totally gives the vibe "Well, some people still like to play 60fps on a 60hz screen" but no.. the biggest majority i think is currently on 144hz and kinda demands 144fps with semi-average computers these days on the lowest settings.
Hey Ironhorse, how about we bring back clientside rating? make it reset each time you join a server to default ns2 recommended, allow clients to increase sendrate/moverate/bwlimit/interp allow clients to increase based on how much power the server will allow them without negatively impacting server performance... one can dream
I think it is very simple why UWE is not focusing on performance. It is a massive amount of work that would take a very long time with an uncertain amount of gain.
In the meantime UWE is working on this stuff from their road map, which is easier to accomplish, and with a more certain amount of gain. X64 NS2 opens up a lot of doors for UWE. Match seeding and whatever matchmaking UWE implements could have fairly large returns. Fixing curl issues will help servers quite a bit. I see some more rookie retention features, one of the area's NS2 has the most room to grow.
At this point in development, everything UWE does will have marginal improvements. They are working on a game played by about 12,000-16,000 unique players every 2 weeks, or about an average 200 daily core community members. The game is a mature product. From my perspective it looks like UWE is trying to create a lot of marginal improvements, with semi-regular updates, that should result in a fairly large improvement. To focus solely on performance would take more time, with very few updates, resulting in hopefully a fairly large improvement.
This is my opinion on what I think UWE is doing. There are things I wish they would focus on that are not on their trello boards. I could see how some players might not care about most things on the roadmap. They might only want better performance. That doesn't mean that is what is best for NS2.
Comments
"I can hit things fine until there's 5 people on screen!" Etc
A huge part why modern online gaming has moved to lag compensation was precisely for consistency. You don't have to know your enemy's latency at that moment in order to determine how far ahead to lead your shots.
You can just aim at them and fire.
Dynamic rates might make it so you can't safely determine or learn when to exit the room alive.
I observed not once playing fade/lerk as my hps dropped instantly but not gradually from marines with rifles.
There's a situation, when I fly into the room with marines. They shoot, but I am not observing hits, I continue flying. The next moment I get -200 hps at ones. It's too late to leave the room.
There also moments when I got > 100 hp from one pistol, not gradual 33+33+33.
I'm doing maximum 6 clicks per second. Maybe there's phenomenal men like Wob with 10 clicks per second.
3 shots > 300 msec
That means, that I have more than 300 msec interval between updates from server.
20 send rate = 50 msec. WTF?
I think there were situations when It passed ~1 sec from leaving to death, not 100 msec, as you write there.
100 msec * 15 u/sec = 1.5 unit. It's ok. I don't pay attention to 1 unit around a corner deaths.
@IronHorse, show you QA quality
Lag compensation wasn't touched, but the hitreg/netcode was slightly, by more thoroughly checking that hits that landed actually did.
Essentially it was just additional checking at the cost of server performance, as well as fixing some underlying problems.
I'm sure there's more details that Matso could give about it, but that was my nutshell understanding of it.
The obvious cases like the meatshot missing against a fast moving fade and still producing green blood etc, should be fixed from 279 onward. (we at least cannot reproduce tests that once produced the issue)
But there were still outliers and edge cases though after 279, (like the last inch of the top/back of a fast moving skulk) and most of those have been solved by utilizing a larger hitbox that's also calculated differently.
I've ran tests using the new hitbox calculation method mixed with the old hitboxes, and there were still the occasional issues even if it was improved.
@Handschuh
I concur that lag compensation should end at ~200 latency. Past that point you'll have to lead the target, and so will he/she.
But personally I feel like the teleporting players from packet loss are much more common than your 300+ latency player, and much more of an issue to engage with.
This solution was once developed and tested.. and even though it solved the problem beautifully (see the vids!), it created massive side effects for high latency players connecting from other continents - namely, freezing in place or stuttering only on their screen - and as such it was sadly shelved.
A stable 60 sendrate with proportionally lower interp setting, lag compensation ending at ~200 latency and null move insertion is my personal pie in the sky netcode wishlist that may be somewhat out of reach.
But boy would all that make engagements feel better.
Of course you should be able to configure it, considering what clientel is playing on your server.. but still.. these days it looks like there is no cap at all for late packages...
That doesn't really work for small game communities like us. We still have a big enough community where we can mostly do this. I have had to play in EU many times because that was the only server available.
There are plenty of servers. Most people refuse to seed. When I play NS2 I try to seed often.
IDEALLY the cutoff point would be 100. With NS2's current state, I think it should be 150.
That also sounds like it'd creative an inconsistent environment.
So much of netcode for the individual player is learned timings.. knowing when to get out of the room or knowing how to aim in relation to the enemy.
If any server op could set what they'd want, you'd definitely see some server Op do something foolish and set it to 50ms, and then everyone would be complaining on here or in discord how bad the hitreg is.
It'd be much better to just have a standard that everyone can learn and get used to that is a reasonable number.
Good point, however, what about a compromise here. Allow a few preset options, like: low, medium, high latency compensation, or perhaps just two options? And adjust the serverbrowser so it informs players about this.
Im pretty sure that a FCAT benchmark would atleast prove my "something is wrong with the frametimes" feeling.
And netcode?
Here are samples how tripleA titles deal with netcode issues:
From my point of view the net rates are way to low for a game where you have to shoot small fast moving targets.
The server browser already tells you that the rates are not default if you join a modificated server.
Problem is you see only a generic info but no details about what rates have changed.
You can disable this little warning and people tend to forget that a server is maybe running on lower rates. (or higher? who knows)
Its just that many server ops did it horribly horribly wrong in the past.
Or picked rates their server can not remotely maintain.
Or lowered interp on a server running inter-continent matches.
Combine that with players throwing around wrong info (blaming x when its y) and rates is a whole big of mess, most server ops (should) stear clear off.
As for frame, well. I have seen weird framespike hitches in plogs plenty of times. One of the best things to do with that is to keep spamming uwe with plogs. (Considering his role I would throw them at ironhorse.)
Make his inbox explode with plogs.
Im not talking about fps here.
Like i said: Steady 130fps in NS2 just feel different than steady 130fps in Battlefield4.
And cause there is something wrong with the frametimes the whole game feels unresponsive.
Compared to BF it feels like there is some sort of delay when you move your mouse.
Instead of saying what's wrong, maybe you can also add ETA when it's going to be fixed? Or there's no plan of develop and increase the send rate?
And let me guess, there's no way in this world where Spark can utilize multiple-cores even on SteamCMD?
AFAIK it would require significant rewrites and optimizations to the server, networking layer, and refactoring for more LuaJIT. And that's all before we get to the actual part where said changes create whole swaths of new bugs that actually do need fixing. Last time we tested a sendrate of 50 internally, even on a beefy 5 ghz server it was causing all sorts of worldupdate oddities.
So there's no ETA currently because that's just not occurring yet, as there are other priorities in the works right now.
That being said, increasing the send rate has been a target and a desire for the team for a long while now... it's just a lot of work, that's competing with low hanging fruit priorities.
You'll probably see a trello card pop up when /if it starts being worked on.
I understand it's nothing you can fix within a few hours, all i'm asking.. If you know that the game would drasticly change in the feeling in terms of hitreg/netcode/smoothness for players. Why isnt this a priority? To be frank i'm baffled over the priorities.. People dont care much about visuals anyway considering it's impossible to maintain a High FPS 144+ with ALL the visuals on if you're not running on a atleast Sandy Bridge with 4.8+ GHz on the 2 first cores.
If i were a developer, i would've want to have the fundemental work done in the game... As performance would be my no.1 priority. (Performance is a fundemental layer that needs to be worked with all the time)
That's why i dont understand why PERFORMANCE is not a priority over at UWE...Doesnt subnautica also suffer from performance issues? (random frame drops)
You say you've tried 5GHz, so i guess there is some kind of logs? Why not start with them?
UWE Department totally gives the vibe "Well, some people still like to play 60fps on a 60hz screen" but no.. the biggest majority i think is currently on 144hz and kinda demands 144fps with semi-average computers these days on the lowest settings.
Where's my 101/101/20000 lanrates m8
mine in ns2 would be like 65/100/9999999
In the meantime UWE is working on this stuff from their road map, which is easier to accomplish, and with a more certain amount of gain. X64 NS2 opens up a lot of doors for UWE. Match seeding and whatever matchmaking UWE implements could have fairly large returns. Fixing curl issues will help servers quite a bit. I see some more rookie retention features, one of the area's NS2 has the most room to grow.
At this point in development, everything UWE does will have marginal improvements. They are working on a game played by about 12,000-16,000 unique players every 2 weeks, or about an average 200 daily core community members. The game is a mature product. From my perspective it looks like UWE is trying to create a lot of marginal improvements, with semi-regular updates, that should result in a fairly large improvement. To focus solely on performance would take more time, with very few updates, resulting in hopefully a fairly large improvement.
This is my opinion on what I think UWE is doing. There are things I wish they would focus on that are not on their trello boards. I could see how some players might not care about most things on the roadmap. They might only want better performance. That doesn't mean that is what is best for NS2.