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
The server does not predict anything - only other players do so.
The warping you see is because the client moved in a different path than what other players predicted.
The server does however reset your position back to the last reported position in the event of packet loss to the server. This is also where you can see warping.
The server is the trusted party, every time.
I assume server prediction of every single player, or even trusting other players' prediction of that laggy player would be too strenuous on the already stressed server, not to mention has potential for exploiting. (trusting those other players too much)
About server load.. Idk why you're so doubtful? How familiar are you with this engine if you don't mind me asking?
You should run your own tests, but my own (terrible math) verified that the max data usage was 25/sec, aka 1.5 MB a minute per player, average was 15/sec, aka ~1 MB a minute per player.
Meaning a 24 player server can accrue a GB of network data in 40 minutes.
Compare that to counterstrike, and the same player count and time window yields ~115 MB... A tenth of the data...
The server does not predict anything - only other players do so.
The warping you see is because the client moved in a different path than what other players predicted.
The server does however reset your position back to the last reported position in the event of packet loss to the server. This is also where you can see warping.
The server is the trusted party, every time.
Good to know but in case of packet loss your position is not reset. In my tests I can run around and shoot as if there's no lag or packet loss at all. Others will see me heavily warping (forward) though.
About server load.. Idk why you're so doubtful? How familiar are you with this engine if you don't mind me asking?
You should run your own tests, but my own (terrible math) verified that the max data usage was 25/sec, aka 1.5 MB a minute per player, average was 15/sec, aka ~1 MB a minute per player.
Meaning a 24 player server can accrue a GB of network data in 40 minutes.
Compare that to counterstrike, and the same player count and time window yields ~115 MB... A tenth of the data...
I am not familiar with the Spark engine / ns2 network code per se, but 10x the data doesn't have to mean 10x more data is required to be transferred. (Gold)source has a lot of smart optimizations and compression..
Do those numbers mean that I could run a CS server with 240 players to get the same traffic as a 24 slot ns2 server? With the huge difference that all of those players would be running around changing the direction they look at and shooting at each other... while in ns2 cysts and clogs and other stuff is pretty much completely inactive most of the time.
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
There could be a threshold that needs to be reached in regards to packet loss.
Meaning a brief one results in you warping forward to others, while a longer one may result in warping back?
Entities are entities .. the server tracks their position and states, and updates to all players.
If you wipe all entities from the map, sure.. its a lot more like CS with class mods. (except all the game logic is still LUA, not just class based info)
ofc this is all coming from my own experience with this engine for the past 3.5 years - i am not a programmer.
What about collision? I am sure those things effect it one way or another.
I guess that happens client-side too. I can imagine a couple of inconsistencies resulting of that, especially in close combat between two players with different pings that collide into each other.
As for the packet loss, could potentionally simulate [on the server side] and see what happens, would need someone else to either play the victom or record it though.
Actually to be clearer, it can be simulated on the server from "both" sides, as in ingoing loss and outgoing loss, with any loss-rate disired.
I also really hope UWE allows changing of clientrate, since this alone adds some latency; I guess it's something like 30 would be significantly better (50ms vs 33ms)
Collision has always been pretty messed up. But I heard sewlek has good collision code changes coming? Or did he already do that.
That might have been reinforced. It got way better that patch (by way better I mean you sometimes collide with moving things while moving yourself now) I still think it is too soft for such a melee focused game though.
Meaning a 24 player server can accrue a GB of network data in 40 minutes.
Compare that to counterstrike, and the same player count and time window yields ~115 MB... A tenth of the data...
FIBER OPTICS FTW.
Anyways, this obviously has room for optimization. I assume most problems in NS2 is due to the fact it's coded in LUA, correct?
Lua doesnt make the game take more data per second, just the sheer amount of possible things that can happen, and possibly some other missing techniques (delta compression?). Many things could probably be optimized to use smaller fields for networking also, but thats many little changes to hopefully add up to something meaningful.
As for the packet loss, could potentionally simulate [on the server side] and see what happens, would need someone else to either play the victom or record it though.
Actually to be clearer, it can be simulated on the server from "both" sides, as in ingoing loss and outgoing loss, with any loss-rate disired.
I also really hope UWE allows changing of clientrate, since this alone adds some latency; I guess it's something like 30 would be significantly better (50ms vs 33ms)
Only automatically. Server and client agree on a rate by negotiation.
We've seen what result it can produce when player mess with it (or exploit).
As for the packet loss, could potentionally simulate [on the server side] and see what happens, would need someone else to either play the victom or record it though.
Actually to be clearer, it can be simulated on the server from "both" sides, as in ingoing loss and outgoing loss, with any loss-rate disired.
I also really hope UWE allows changing of clientrate, since this alone adds some latency; I guess it's something like 30 would be significantly better (50ms vs 33ms)
Only automatically. Server and client agree on a rate by negotiation.
We've seen what result it can produce when player mess with it (or exploit).
Since you're referring to the rate only, that's why source for example has server-side limits you can enforce on the upper and lower bounds of rate. If you desire, you can enforce a specific rate.
Allowing people to set rate is in source for example so that people with bad internet can actually play, since if your upload is too bad, you're usually not able to play with a high updaterate.
Actually, just had an idea that might work very well for this type of game; they could just use 2 different update rates, one for the high-precision data, and other for non-critical. I'd consider buildings or minimap updates not very time-critical, however player movements / shooting would be.#
Meaning a 24 player server can accrue a GB of network data in 40 minutes.
Compare that to counterstrike, and the same player count and time window yields ~115 MB... A tenth of the data...
FIBER OPTICS FTW.
Anyways, this obviously has room for optimization. I assume most problems in NS2 is due to the fact it's coded in LUA, correct?
Yes and no.
This is a very broad speculation you make here, infact lua reduces many problem sources and introduces others at the same time.
Performance is one of these problems, due to some limitations of their current implemention (and besides, an interpreted language will usually be slower then an compiled one). But don't forget that lua, much like other languages with higher abstraction, also reduce certain errors that you'd have to deal with in c++ besides providing higher development speed.
As for networking, I don't think lua is the cause here. More like the way it's done, and it's not too bad basically, but the kind of delay with the current implementation is just bad for an FPS. It's like playing with 300ms ping constantly.
g) Due to high interp, it's possible to go though tunnels/phase gates, but not actually appearing on the other side; you are resetting in position (i.e. still in tunnel or on the other phase gates)
And a big one:
h) Tickrate Variance
The server is suffering from tickrate variance, which make ticks take inconsistent time. In theory with a tickrate of 1/30 a tick should result in a time of 33.33 ms for each tick, however this is not the case.
Server has pretty high flunctuations in the tickrate:
Personal findings (with the lua data recording plugin made by Ghoul), on a 22-slot server that has a stable 30 tickrate. Recoded over ~40 mins of summit.
Legend (x = 1 tick per pixel, y = 1 ms per 10 pixels):
Green - Time taken to process the frame
Red line - "should be" processing time
Blue line - Standard deviation based of ideal value
Some other stats:
Avarage: 0.034s
STDDEV: 0.0132s
Max: 2.3769s (lagspike anyone?)
Min: 0.0035s
c) What you see is what you hit approach; marines can you shoot you if they see you on your screen, even if you aren't
I came to this thread only to confirm that feeling. I still find it a hard to believe choice for a competitive-wanabee game - even more so for a slightly faster than average one.
Did UWE acknowledge the issue?
Also, netcode has been a solved problem for 15 years now.
No, I don't think so but it's blatantly obvious. Just played a round of combat and got shot down around the corner ... MULTIPLE times. I had a ~50 ms ping, the other players from 30 - 120ms.
SamusDroidColoradoJoin Date: 2013-05-13Member: 185219Members, Forum Moderators, NS2 Developer, NS2 Playtester, Squad Five Gold, Subnautica Playtester, NS2 Community Developer, Pistachionauts
edited December 2013
I don't think you know just how much data the game sends. I've purposely made it so it prints out everyone it sends out a message, it's absurd. There are ways to reduce it yes, but it would require a lot more work. Something that could be possible is a "LAN" mode where all lag compensation is turned off.
AsranielJoin Date: 2002-06-03Member: 724Members, Playtest Lead, Forum Moderators, NS2 Playtester, Squad Five Blue, Reinforced - Shadow, WC 2013 - Shadow, Subnautica Playtester, Retired Community Developer
The choice to hit what you see on the screen and not to have to lag compensate is a delibarate choice and not an "issue". playing ns2 without that would be impossible because the alien lifeforms are so fast. it works in slower shooters because the players move so slowly, but ns2 would be unplayable with anything about 60 ping
I don't really see why that would be such a bad thing. Anyone in quake will tell you that playing over 30 ping is unplayable due to the delay on shots. So you play on local servers with low ping and have a good experience with no corner deaths.
AsranielJoin Date: 2002-06-03Member: 724Members, Playtest Lead, Forum Moderators, NS2 Playtester, Squad Five Blue, Reinforced - Shadow, WC 2013 - Shadow, Subnautica Playtester, Retired Community Developer
edited December 2013
Yes, but then good luck playing ns2, because of the playerbase. finding a server that has a ping in sub 60 is often impossible for me, and i live in central europe. its a choice to make and i think its the best one. i know no other game that plays so well with high pings. a lan option would of course be nice, but its not really something i'm concerned about ( i never play ns2 in lans)
The choice to hit what you see on the screen and not to have to lag compensate is a delibarate choice and not an "issue". playing ns2 without that would be impossible because the alien lifeforms are so fast. it works in slower shooters because the players move so slowly, but ns2 would be unplayable with anything about 60 ping
Hint: NS2 is a S L O W game. Quakeworld is insanely faster and is perfectly playable with 50ms ping.
I don't think you know just how much data the game sends. I've purposely made it so it prints out everyone it sends out a message, it's absurd. There are ways to reduce it yes, but it would require a lot more work. Something that could be possible is a "LAN" mode where all lag compensation is turned off.
I can't see any reason why so much more data would be sent compared to any other fps. I guess everything is sent asap or at a frequency not needed by anything but player pos and hit regs.
I don't really see why that would be such a bad thing. Anyone in quake will tell you that playing over 30 ping is unplayable due to the delay on shots. So you play on local servers with low ping and have a good experience with no corner deaths.
Q3 is playable under 80ms for most decent players. Pros can perform close to their best up to 120 (rat vs aph or pajuo anyone?)
NS2 has wonderfull ideas, so did NS1 and i do love both. Still on some crucial points, execution is lacking.
Comments
The warping you see is because the client moved in a different path than what other players predicted.
The server does however reset your position back to the last reported position in the event of packet loss to the server. This is also where you can see warping.
The server is the trusted party, every time.
I assume server prediction of every single player, or even trusting other players' prediction of that laggy player would be too strenuous on the already stressed server, not to mention has potential for exploiting. (trusting those other players too much)
About server load.. Idk why you're so doubtful? How familiar are you with this engine if you don't mind me asking?
You should run your own tests, but my own (terrible math) verified that the max data usage was 25/sec, aka 1.5 MB a minute per player, average was 15/sec, aka ~1 MB a minute per player.
Meaning a 24 player server can accrue a GB of network data in 40 minutes.
Compare that to counterstrike, and the same player count and time window yields ~115 MB... A tenth of the data...
I am not familiar with the Spark engine / ns2 network code per se, but 10x the data doesn't have to mean 10x more data is required to be transferred. (Gold)source has a lot of smart optimizations and compression..
Do those numbers mean that I could run a CS server with 240 players to get the same traffic as a 24 slot ns2 server? With the huge difference that all of those players would be running around changing the direction they look at and shooting at each other... while in ns2 cysts and clogs and other stuff is pretty much completely inactive most of the time.
Meaning a brief one results in you warping forward to others, while a longer one may result in warping back?
Entities are entities .. the server tracks their position and states, and updates to all players.
If you wipe all entities from the map, sure.. its a lot more like CS with class mods. (except all the game logic is still LUA, not just class based info)
ofc this is all coming from my own experience with this engine for the past 3.5 years - i am not a programmer.
I guess that happens client-side too. I can imagine a couple of inconsistencies resulting of that, especially in close combat between two players with different pings that collide into each other.
Actually to be clearer, it can be simulated on the server from "both" sides, as in ingoing loss and outgoing loss, with any loss-rate disired.
I also really hope UWE allows changing of clientrate, since this alone adds some latency; I guess it's something like 30 would be significantly better (50ms vs 33ms)
http://jagt.github.io/clumsy/index.html
That might have been reinforced. It got way better that patch (by way better I mean you sometimes collide with moving things while moving yourself now) I still think it is too soft for such a melee focused game though.
Warm.
@1dominator1
Colder.
FIBER OPTICS FTW.
Anyways, this obviously has room for optimization. I assume most problems in NS2 is due to the fact it's coded in LUA, correct?
Only automatically. Server and client agree on a rate by negotiation.
We've seen what result it can produce when player mess with it (or exploit).
Since you're referring to the rate only, that's why source for example has server-side limits you can enforce on the upper and lower bounds of rate. If you desire, you can enforce a specific rate.
Allowing people to set rate is in source for example so that people with bad internet can actually play, since if your upload is too bad, you're usually not able to play with a high updaterate.
Actually, just had an idea that might work very well for this type of game; they could just use 2 different update rates, one for the high-precision data, and other for non-critical. I'd consider buildings or minimap updates not very time-critical, however player movements / shooting would be.#
Yes and no.
This is a very broad speculation you make here, infact lua reduces many problem sources and introduces others at the same time.
Performance is one of these problems, due to some limitations of their current implemention (and besides, an interpreted language will usually be slower then an compiled one). But don't forget that lua, much like other languages with higher abstraction, also reduce certain errors that you'd have to deal with in c++ besides providing higher development speed.
As for networking, I don't think lua is the cause here. More like the way it's done, and it's not too bad basically, but the kind of delay with the current implementation is just bad for an FPS. It's like playing with 300ms ping constantly.
And a big one:
h) Tickrate Variance
The server is suffering from tickrate variance, which make ticks take inconsistent time. In theory with a tickrate of 1/30 a tick should result in a time of 33.33 ms for each tick, however this is not the case.
Server has pretty high flunctuations in the tickrate:
Personal findings (with the lua data recording plugin made by Ghoul), on a 22-slot server that has a stable 30 tickrate. Recoded over ~40 mins of summit.
(Large image - download suggested)
http://omegak2.net/tick.png
Legend (x = 1 tick per pixel, y = 1 ms per 10 pixels):
Green - Time taken to process the frame
Red line - "should be" processing time
Blue line - Standard deviation based of ideal value
Some other stats:
Avarage: 0.034s
STDDEV: 0.0132s
Max: 2.3769s (lagspike anyone?)
Min: 0.0035s
I came to this thread only to confirm that feeling. I still find it a hard to believe choice for a competitive-wanabee game - even more so for a slightly faster than average one.
Did UWE acknowledge the issue?
Also, netcode has been a solved problem for 15 years now.
Hint: NS2 is a S L O W game. Quakeworld is insanely faster and is perfectly playable with 50ms ping.
Netcode. It has it.
I can't see any reason why so much more data would be sent compared to any other fps. I guess everything is sent asap or at a frequency not needed by anything but player pos and hit regs.
Because other fps games are not syncing 1,000 entities between the server and 24 players. (and that's not an exaggeration)
Q3 is playable under 80ms for most decent players. Pros can perform close to their best up to 120 (rat vs aph or pajuo anyone?)
NS2 has wonderfull ideas, so did NS1 and i do love both. Still on some crucial points, execution is lacking.