<div class="IPBDescription">Or how I learned to stop worrying and screw with my console</div>It's here folks, your one stop shop for console commands to improve, tweak, or generally screw with NS2.
<!--quoteo(post=1903860:date=Feb 16 2012, 03:26 PM:name=comp_)--><div class='quotetop'>QUOTE (comp_ @ Feb 16 2012, 03:26 PM) <a href="index.php?act=findpost&pid=1903860"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->r_stats and net_stats not working for me. Anyone else with this problem?<!--QuoteEnd--></div><!--QuoteEEnd-->
I cba to find the quote, but it was stated by a dev that these were accidentally removed and will be back in next patch.
I think it was a mistake to hold on so long to the all-LUA game idea.
I may not be knowing enough to say this, but I suspect that having so large parts of such a complex game like NS2 in LUA was a big mistake and the direction in that regard should have been changed years ago.
Look at NS2 1 year ago and today. The problem is nearly the same (personal assumption): LUA and the massive garbage collection eating up all the msecs. The really bad thing about this is that it is not a graphics issue (as it should be), but a CPU issue and since you cannot turn down the "quality" of the gamecode, it is not fixable from a user point of view.
If there is some way of converting your LUA code to another, compiled language without garbage collection - please do it now! I dont see the massive CPU hog going away just because you optimize some physics, some prediction or some shadow map generation routines.
Especially when thinking about servers, this is a disaster. How do you want to ever optimize the servers to run at a decent level with LUA code and garbage collection?
Please note, this is not a rant but a call to the devs to move away from un-compiled LUA for most of the game code.
Heh, a bit late for such a call. It would involve not so much copy-pasting (translating), but more-over a lot of re-writing, as one programming-language doesn't work the same as another, and each have different strengths and weaknesses (and demands redesigning a lot).
This is truly the only subject I have concern over, anything else (gameplay-mechanics wise) I don't care that much about as it can be mod-fixed afterwards, but this bloody terrible performance... What we're talking about is the necessicity of improvement of a factor 5-10x at least. It would be really interesting to hear how they intend to go about this. It demands something fundamental, and not patch-jobs (like caching and other tricks to reduce load).
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->Heh, a bit late for such a call.<!--QuoteEnd--></div><!--QuoteEEnd-->
Haha right! Still, if it is the only way to fix performance, it has to be done me thinks, even if that late.
It could be that Im totally wrong with my observation, but the Garbage Collector alone taking between 5 to 10 msec per frame is just horrible! Add to that the usual overhead any scripting language has and it's a clear problem in my eyes that cannot be optimized away when all the game code is in there.
<!--quoteo(post=1904042:date=Feb 16 2012, 10:05 PM:name=w0dk4)--><div class='quotetop'>QUOTE (w0dk4 @ Feb 16 2012, 10:05 PM) <a href="index.php?act=findpost&pid=1904042"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Haha right! Still, if it is the only way to fix performance, it has to be done me thinks, even if that late.
It could be that Im totally wrong with my observation, but the Garbage Collector alone taking between 5 to 10 msec per frame is just horrible! Add to that the usual overhead any scripting language has and it's a clear problem in my eyes that cannot be optimized away when all the game code is in there.<!--QuoteEnd--></div><!--QuoteEEnd--> I'm not sure you know what garbage collection or msec is. Either way the problem with LUA is not garbage collection, but that its not pre-compiled. And even if LUA is complied into binary data it still needs to be interpreted at run time and acts as another level before reaching the machine.
I get that LUA is desirable for easier coding, but really LUA should've been relegated to AI scripts/mapping scripts and balance configuration. The entire client/server architecture in LUA is crazy and I'm not even sure how feasible it is. The main question I ask is... why!? Surely anyone who wants to get into modding at a level where they are editing lower level client/server code can happily deal with C++ libraries? Is security the concern here? Take a look at Quake3's solution.
JIT is still very slow. Thats why you don't see games in Java.
Yeah but weren't there certain issues with LuaJIT that made it necessary to steer away from it? Also without looking into it "just in time" makes it sound as if the compiling is done at run time.
<!--quoteo(post=1904055:date=Feb 16 2012, 11:27 PM:name=NurEinMensch)--><div class='quotetop'>QUOTE (NurEinMensch @ Feb 16 2012, 11:27 PM) <a href="index.php?act=findpost&pid=1904055"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->There got to be a way to pre-compile all the LUA stuff.<!--QuoteEnd--></div><!--QuoteEEnd-->
well there would be if it wasn't an interpreted language
I think it'll be a hybrid. JIT essentially compiles from bytecode into native code (depending on the situation: individual functions, files, or whole-sale). But Lua is so dynamic and weak-typed, in order to maintain those features it puts severe restrictions in how far it can compile into machine-code.
<!--quoteo(post=0:date=:name=Clonesa)--><div class='quotetop'>QUOTE (Clonesa)</div><div class='quotemain'><!--quotec-->The main question I ask is... why!? Surely anyone who wants to get into modding at a level where they are editing lower level client/server code can happily deal with C++ libraries? Is security the concern here? Take a look at Quake3's solution.<!--QuoteEnd--></div><!--QuoteEEnd--> Yea I thought a server-side C++-SDK would've been ideal, you don't need to consider security on the host. As for the clients, you will need some kind of sandbox, and it is the second time I've seen Q3's VM mentioned, but I'm not so sure it can compete with Lua in this regard. I don't know how things are organized in Q3's scripts, but I guess the fact that UWE decided to write such very large portions of the game in scripts is the problem (it is in Lua, and probably would've been in QVM as well).
Remember that scripts are synchronized from server to client (or will be anyway), so an extremely safe sandbox is paramount for clients.
What I don't get is why framerate seems to be so heavily dependent on server performance (tickrate). Looking at net_stats and r_stats, the only correlation I find between when I am having great framerate and terrible framerate is when the server is running at a low tickrate, which generally happens when people go overboard with things like turrets and hydras. Its not that I am rendering more "stuff". In fact, I might be rendering much less in a given scene, but getting worse performance if the server is running poorly. You can really see the difference after the round resets and I start having fantastic framerate as the server starts running at a faster trickrate at the start of a fresh round.
Its like the client doesn't get the data it needs fast enough, so it drops frames instead of compensating with extrapolation. I cant think of any games that behave like this. Bad server performance should result it network players skipping around or having generally non-fluid movement. It shouldn't result in my client running slower. Heck, some games even continue running after you have lost complete connection to the server, other players just continue moving in whatever direction they were moving in when you lost connection (due to extrapolation).
It seems like this is the biggest performance issue they are having right now. When the servers are running great the game runs great, even with large player counts and lots of structures. My game runs the same no matter what graphics settings I select. This hints that the bottleneck isn't with my hardware, and that messing with console commands isn't going to help much.
twilitebluebug stalkerJoin Date: 2003-02-04Member: 13116Members, NS2 Playtester, Squad Five Blue
edited February 2012
I'm curious about the difference between server sent "update rate" and server "tick rate". Is there a reason why the server doesn't send one update per tick?
It's not too late to make this a Quake 4 mod is it :p
Edit: Nevermind. <a href="http://www.indiedb.com/engines/unreal-development-kit/games?sort=dateup-desc" target="_blank">UDK</a> looks much more promising. Just copy paste your models/textures and done!
Edit2: Wow, there are some <a href="http://www.renegade-x.com/site/" target="_blank">very</a> <a href="http://www.moddb.com/games/you-led-me-here" target="_blank">nice</a> <a href="http://www.moddb.com/games/old-town" target="_blank">games</a> made with UDK already. I could really see a NS2 competitor coming out of there within a year or so.
Comments
<a href="http://www.unknownworlds.com/ns2/wiki/index.php/Console_Commands" target="_blank">http://www.unknownworlds.com/ns2/wiki/inde...onsole_Commands</a></div>
Worked wonders for me. Seems alot smoother.
Because all those unnecessary GUI items like minimaps and health counters are hogging my valuable CPU cycles!
Thanks,
I cba to find the quote, but it was stated by a dev that these were accidentally removed and will be back in next patch.
I may not be knowing enough to say this, but I suspect that having so large parts of such a complex game like NS2 in LUA was a big mistake and the direction in that regard should have been changed years ago.
Look at NS2 1 year ago and today. The problem is nearly the same (personal assumption): LUA and the massive garbage collection eating up all the msecs. The really bad thing about this is that it is not a graphics issue (as it should be), but a CPU issue and since you cannot turn down the "quality" of the gamecode, it is not fixable from a user point of view.
If there is some way of converting your LUA code to another, compiled language without garbage collection - please do it now! I dont see the massive CPU hog going away just because you optimize some physics, some prediction or some shadow map generation routines.
Especially when thinking about servers, this is a disaster. How do you want to ever optimize the servers to run at a decent level with LUA code and garbage collection?
Please note, this is not a rant but a call to the devs to move away from un-compiled LUA for most of the game code.
This is truly the only subject I have concern over, anything else (gameplay-mechanics wise) I don't care that much about as it can be mod-fixed afterwards, but this bloody terrible performance... What we're talking about is the necessicity of improvement of a factor 5-10x at least. It would be really interesting to hear how they intend to go about this. It demands something fundamental, and not patch-jobs (like caching and other tricks to reduce load).
Haha right! Still, if it is the only way to fix performance, it has to be done me thinks, even if that late.
It could be that Im totally wrong with my observation, but the Garbage Collector alone taking between 5 to 10 msec per frame is just horrible! Add to that the usual overhead any scripting language has and it's a clear problem in my eyes that cannot be optimized away when all the game code is in there.
It could be that Im totally wrong with my observation, but the Garbage Collector alone taking between 5 to 10 msec per frame is just horrible! Add to that the usual overhead any scripting language has and it's a clear problem in my eyes that cannot be optimized away when all the game code is in there.<!--QuoteEnd--></div><!--QuoteEEnd-->
I'm not sure you know what garbage collection or msec is. Either way the problem with LUA is not garbage collection, but that its not pre-compiled. And even if LUA is complied into binary data it still needs to be interpreted at run time and acts as another level before reaching the machine.
I get that LUA is desirable for easier coding, but really LUA should've been relegated to AI scripts/mapping scripts and balance configuration. The entire client/server architecture in LUA is crazy and I'm not even sure how feasible it is. The main question I ask is... why!? Surely anyone who wants to get into modding at a level where they are editing lower level client/server code can happily deal with C++ libraries? Is security the concern here? Take a look at Quake3's solution.
JIT is still very slow. Thats why you don't see games in Java.
well there would be if it wasn't an interpreted language
<!--quoteo(post=0:date=:name=Clonesa)--><div class='quotetop'>QUOTE (Clonesa)</div><div class='quotemain'><!--quotec-->The main question I ask is... why!? Surely anyone who wants to get into modding at a level where they are editing lower level client/server code can happily deal with C++ libraries? Is security the concern here? Take a look at Quake3's solution.<!--QuoteEnd--></div><!--QuoteEEnd-->
Yea I thought a server-side C++-SDK would've been ideal, you don't need to consider security on the host. As for the clients, you will need some kind of sandbox, and it is the second time I've seen Q3's VM mentioned, but I'm not so sure it can compete with Lua in this regard. I don't know how things are organized in Q3's scripts, but I guess the fact that UWE decided to write such very large portions of the game in scripts is the problem (it is in Lua, and probably would've been in QVM as well).
Remember that scripts are synchronized from server to client (or will be anyway), so an extremely safe sandbox is paramount for clients.
Its like the client doesn't get the data it needs fast enough, so it drops frames instead of compensating with extrapolation. I cant think of any games that behave like this. Bad server performance should result it network players skipping around or having generally non-fluid movement. It shouldn't result in my client running slower. Heck, some games even continue running after you have lost complete connection to the server, other players just continue moving in whatever direction they were moving in when you lost connection (due to extrapolation).
It seems like this is the biggest performance issue they are having right now. When the servers are running great the game runs great, even with large player counts and lots of structures. My game runs the same no matter what graphics settings I select. This hints that the bottleneck isn't with my hardware, and that messing with console commands isn't going to help much.
Specs:
Processor: AMD Phenom II X4 965 Processor (4 CPUs), ~3.4GHz
Memory: 8192MB RAM
Hard Drive: OCZ Agility 3 120GB SSD
Graphics Card: NVIDIA GeForce GTX 470
Edit:
Nevermind. <a href="http://www.indiedb.com/engines/unreal-development-kit/games?sort=dateup-desc" target="_blank">UDK</a> looks much more promising. Just copy paste your models/textures and done!
Edit2:
Wow, there are some <a href="http://www.renegade-x.com/site/" target="_blank">very</a> <a href="http://www.moddb.com/games/you-led-me-here" target="_blank">nice</a> <a href="http://www.moddb.com/games/old-town" target="_blank">games</a> made with UDK already. I could really see a NS2 competitor coming out of there within a year or so.