My concern for this patch isn't how awesome the configurable update rate and move rate can be, but what servers will actually be capable of a sizable increase without crippling performance problems. Multiplay servers already struggle without any changes. Aus net won't permit servers put up by community members with meaty enough machines, I want to try this!
a while back dragon was able to get a moverate of 50 i think, and it didn't cripple his server in 6v6 setting
Every server running the NSL mod is at 70 interp, 50 moverate. We've been playing with these settings for a good while.
Also, the performance indicator in the server browser is now an average so it reflects better the performance of the server over a bigger period of time instead of what it did which is the performance when you queried it. So any servers that are dying from inappropriate settings will be easy to spot.
Just to help the general confusion a little, a 500 tickrate server would make absolutely no sense. anything above 30 reall makes not much sense (at least not above 60, but 30 is totally fine).
The tickrate in ns2 is the rate at which AI units, like drifters, whips etc are updated. Yes, you will have slightly more reactive whips, but thats not what you are looking for. What you are looking for are faster update rates, on the one hand the update rate at which the client sends his updates (the current mr (movement rate) command) and on the other hand how often the server sends updates to a client (which is a fixed 20 updates per second right now). This will have a much bigger effect. Of course it will increase the serverload pretty much linearly (if you double those rates, you double the cpu used), so until further optimizations are done, this will only be an option for comp play (small playercount) or very costly servers. But unlocking is the first step before optimization.
It would be awesome if someone with a deep understanding of the NS2 netcode could do one of these great posts on that topic. Not as much to clear up confusion around the subject but because I would really enjoy reading it.
Since it seems the network code is said to be very similar to Source, perhaps this page from Valve would be a good start and pretty much list how NS2 is different. https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
I compiled a list of the information I could find on NS2 networking below:
I play on source a lot, and I can tell you the latest source engine is the worst one yet in terms of hitreg and consistency, valve really messed up and I think it has to do with the left 4 dead engine being used in a 'pinpoint' shooter instead of being made from the ground up
matsoMaster of PatchesJoin Date: 2002-11-05Member: 7000Members, Forum Moderators, NS2 Developer, Constellation, NS2 Playtester, Squad Five Blue, Squad Five Silver, Squad Five Gold, Reinforced - Shadow, NS2 Community Developer
Every move from a player is immediately processed and changes the state of the world. So the network updates being sent out to a player actually reflects the state of the server at the moment the update is sent - and as the world is being continously updated pretty much every ms, every network packet contains the freshest information at that moment.
Sure, the state of the AI units will be either one or two updates old, but who cares how AI units move anyhow... it's just players that matters.
There was a bit of a bug there (fixed in 267) where the world time (which reflects the latest time a move or update was processed) was used for AI units, whose position actually reflected the last time they were updated (same thing for all players; they are also timestamped with when they were updated last). This resulted in quite a lot jerkiness for moving AI units, which was quite annoying (well, for 266 players ... _is_ ... but not for much longer!)
The NS2 interpolation code actually searches for state snapshots for each individual players timestamp to find the best snapshot data for each one. Just to keep it smooth.
Oh, and to shut up Toothy, who was the first one to point out that there was something wrong with how players moved. He insisted that they shuddered even though people found it annoying (the performance of the engine back then was ... not good ... which made it hard to see). Fortunately, with the right logging, he was proved right and that's when Max fixed the individual timestamps for each player fix.
Also, the performance indicator in the server browser is now an average so it reflects better the performance of the server over a bigger period of time instead of what it did which is the performance when you queried it. So any servers that are dying from inappropriate settings will be easy to spot.
It's about fucking time. Hopefully those servers will fucking die or better yet actually improve their shit since people may stop joining because of their poor performance.
t's about fucking time. Hopefully those servers will fucking die or better yet actually improve their shit since people may stop joining because of their poor performance.
Nah, people will still join the 42 player server because it's easier for the new players since they're less likely to be singled out and yelled at like in low population servers.
Comments
Every server running the NSL mod is at 70 interp, 50 moverate. We've been playing with these settings for a good while.
Also, the performance indicator in the server browser is now an average so it reflects better the performance of the server over a bigger period of time instead of what it did which is the performance when you queried it. So any servers that are dying from inappropriate settings will be easy to spot.
It would be awesome if someone with a deep understanding of the NS2 netcode could do one of these great posts on that topic. Not as much to clear up confusion around the subject but because I would really enjoy reading it.
Since it seems the network code is said to be very similar to Source, perhaps this page from Valve would be a good start and pretty much list how NS2 is different.
https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
I compiled a list of the information I could find on NS2 networking below:
Previous work the netcode builds on:
http://forums.unknownworlds.com/discussion/comment/1729670#Comment_1729670
http://forums.unknownworlds.com/discussion/comment/1891393#Comment_1891393
Past network performance issues and changes due to them:
http://forums.unknownworlds.com/discussion/comment/1906233#Comment_1906233
http://forums.unknownworlds.com/discussion/122189/224-tech-changes-part-1
http://forums.unknownworlds.com/discussion/122210/224-tech-changes-part-2
http://forums.unknownworlds.com/discussion/comment/2118854#Comment_2118854
Other:
http://forums.unknownworlds.com/discussion/comment/2062853#Comment_2062853 (lag compensation is like Source, or any other shooter with working networking code)
http://forums.unknownworlds.com/discussion/comment/1902681#Comment_1902681 (projectiles are predicted in Spark, which is interesting because they're not in Source)
http://forums.unknownworlds.com/discussion/comment/2197738#Comment_2197738 (on spectating)
http://forums.unknownworlds.com/discussion/comment/2126146#Comment_2126146 (on rates and interp)
Every move from a player is immediately processed and changes the state of the world. So the network updates being sent out to a player actually reflects the state of the server at the moment the update is sent - and as the world is being continously updated pretty much every ms, every network packet contains the freshest information at that moment.
Sure, the state of the AI units will be either one or two updates old, but who cares how AI units move anyhow... it's just players that matters.
There was a bit of a bug there (fixed in 267) where the world time (which reflects the latest time a move or update was processed) was used for AI units, whose position actually reflected the last time they were updated (same thing for all players; they are also timestamped with when they were updated last). This resulted in quite a lot jerkiness for moving AI units, which was quite annoying (well, for 266 players ... _is_ ... but not for much longer!)
The NS2 interpolation code actually searches for state snapshots for each individual players timestamp to find the best snapshot data for each one. Just to keep it smooth.
Oh, and to shut up Toothy, who was the first one to point out that there was something wrong with how players moved. He insisted that they shuddered even though people found it annoying (the performance of the engine back then was ... not good ... which made it hard to see). Fortunately, with the right logging, he was proved right and that's when Max fixed the individual timestamps for each player fix.
Nah, people will still join the 42 player server because it's easier for the new players since they're less likely to be singled out and yelled at like in low population servers.