Can we have an increase of client update rate?
male_fatalities
ausns2.org Join Date: 2004-03-06 Member: 27185Members, Constellation
ausns2.org Join Date: 2004-03-06 Member: 27185Members, Constellation
In Australia, we are running DAK mod which increases MR and sets interp to 0.06 from 0.1. However when pushing lower then this, people are teleporting because the game is hardcoded to 20 update rate. With these small changes, marines feels much more crisp and responsive in terms of damage feedback.
Can we please unlock the following:
Client update rate - currently max is 20
Server tick rate - currently max is 30
Can we please unlock the following:
Client update rate - currently max is 20
Server tick rate - currently max is 30
Comments
Fixed.
Please.
This is like Microsoft when they didnt let people set custom wallpapers for the tiles screen in Windows 8 because "it might look bad".
It doesn't make any sense. A fast fps with 20 updates/sec and 30 moves/sec. In 2013. L O L.
LOL
Doing so HAS made for bad experiences / first impressions before.
Remember the user made servers on launch week? *shudders* Tickrates were insanely low because someone was hosting 24 player servers on a core 2 duo, so users were reporting in the forums thinking it was the game.
SO.. as long as there's some sort of feedback to the end user, like a warning, i think it can be done. Otherwise, i wouldn't want to experience scenarios like that again.
In fact, this should have been the case for 20+ player servers as this has probably done a lot of damage to the game's reputation in terms of performance due to the prevalence of 24 player servers with low ticks. But that boat has sailed.
Or, just a message describing that playing on non-official servers is not necessarily the optimal NS2 experience or something. Let the modders mod! :>
The implementation depends on UWE; however the answer is easy... Since the performance patch, servers can easily support an increased tick rate & higher client update rate. I had better damage feedback in beta when client update rate were a 1:1 ratio with fps instead of locked at 20. Being shot by a marine when his back is facing you only started occuring when the locked client update rate to 20.
A major issue here is that client update rate and server tick rate interfers with each other. Clients are only updated after each server tick, which means that actual client update intervals are actually 33,66,33,66,33,66 ms - so if you lower interp to 60ms, you WILL get some extrapolation of client state (which is the cause of teleporting). To avoid teleporting you need the interp to cover longest client update interval + expected network variation, so 60ms interp would actually be pretty much optimal IF the server actually updated clients every 50ms. I'd say 75ms would be minimum with the current setup.
Reported a couple of months ago.
This of course means that you need client update rate to be a multiple of server tick rate. Server tick rate turns out not to matter much in NS2 (smoothness of player movement is controlled by move rate and client update rate, server tick rate basically controls interaction with non-player units such as medpacks, armories etc), so a reasonable way to run it would be 25 server tick rate and 25 client update rate, which should allow an interp at 50 (40 from the update rate + 10ms net variation).
Increasing move rate to 40 would also be good (and possible now that LuaJit has increased server performance)
Higher update rate means higher bandwidth at a factor of about 0.6 or so (so doubling update rate means using 60% more bandwidth) - a 25% higher update rate would increase bandwidth usage with about 15%.
A request to move server tick rate and update rate from hardcoded to server configurable was made a couple of months ago.
Unfortunately, Max is kinda busy with the new render pipeline stuff, and there does not seem to be anyone else that feels comfortable playing around with this stuff.
(and no, I don't have engine access any longer, so I can't fix it).
They should give you access to the engine so that you can fix it if max is occupied with other tasks.
LOL
@xDragon
tell him what you did to your server
Increasing the client update rate would be ideal, however I do know that there are some major bandwidth constraints within Spark currently. I dont know if the maximum data per second could also be unlocked at the same time, but I think on default servers any increase in bandwidth usage could prove problematic - I still see choke in larger pubs.