ut2004.ini/ut2004-win64.ini
Code: Select all
[IpDrv.TcpNetDriver]
MaxClientRate=1000000
MaxInternetClientRate=1000000
Code: Select all
[Engine.PlayerController]
bDynamicNetSpeed=False
[Engine.Player]
ConfiguredInternetSpeed=1000000
ConfiguredLanSpeed=1000000
[XInterface.GUIController]
MaxSimultaneousPings=40
Unfortunately the networking in UT2004 was built around backwards compatibility with extremely slow connections. Now that it's 2023+ and most people have stable 1Mbit+ connections, we have to work around the cruft of hard-coded limits which have plagued us for the entirety of the game's life. This guide will try to undo the damage done by other guides that created a Pavlovian response to make players think "netspeed = uncap FPS command," resulting in players using netspeed 10001 to get around the 90 FPS cap while shooting themselves in the foot by dropping all data in excess of 10001 bytes/sec.
Firstly, the stat net command. It can also be accessed by pressing F6. It shows numerous network statistics, but what we're interested in are the bandwidths from and to the server, and netspeed.
By default, servers are capped to 15000 bytes/sec bandwidth to send per client, but if the server has more than 16 player slots, it will instead be capped to 10000B/s. 15000B/s is not a lot of data, especially on a server with a high tick rate and many players. Heavy game types like Assault, Invasion, or Onslaught will quickly pin the bandwidth limit even with fewer players and lower tick rate. For players, the cap is usually 9636 or less. This means you can only receive up to 9636B/s. If the server tries to send 20000B/s (or however much) while you are capped at 9636, your client will drop information.
The "In" bandwidth is responsible for how much data you receive from the server. If there is a lot going on, the bandwidth limit will quickly be reached and you will experience missing effects, delayed actions such as death/respawn, etc. At Omni the "In" bandwidth typically hovers at 15000-40000B/s depending on activity, which is >2x the standard 10000B/s limit that we had due to being a >16 slot server. That is a lot of data to drop.
The "Out" bandwidth is how much data you will send to the server. If it is too low, you will experience issues with movement, dropped inputs such as "Use", etc.
For players:
Netspeed = Command to change your bandwidth limit in bytes to/from the server. The server and your client will only use the necessary amount of bandwidth; netspeed in and of itself is only a limiter. Netspeed cannot be raised above MaxClientRate, so you must also increase MaxClientRate. Once you've done this, every time the server changes maps you must type in the console (`~ key) netspeed 1000000 to increase your netspeed (it resets on map switch). At Omni this is already done for you, and on many other servers that use UTComp. You can create a keybind by typing in the console: set input h netspeed 1000000 - every time you press "H" you will set netspeed to 1000000.
[IpDrv.TcpNetDriver]
MaxClientRate = Bandwidth limit, in bytes, of how high you can set your netspeed. Set this to 1000000. (This setting is located in ut2004.ini/ut2004-win64.ini, again on Omni this is already done for you).
And now for the explanation of FPS caps. For those unfamiliar with the "netspeed" command, it is closely intertwined with the online FPS cap. The practical use of netspeed until recently was to unlock the FPS cap, which is 90 by default. By changing netspeed>10000, the MaxClientFrameRate setting is used. This exists in ut2004.ini/ut2004-win64.ini for 64 bit:
Code: Select all
[Engine.LevelInfo]
MaxClientFrameRate=90
If you have a high refresh rate monitor, set your monitor's refresh rate to the FPS cap to ensure there is no stutter caused by a mismatch in FPS/Hz (e.g. use 250FPS / 250Hz). Otherwise, cap your FPS to a multiple of the monitor's refresh rate (if you have a 144Hz monitor then use 125Hz and 125 or 250 FPS depending on what your system can handle). You can also use variable refresh rate if your monitor supports it, but it adds latency depending on the monitor and GPU vendor (FreeSync has historically worse latency than G-Sync).
The game requests a timer resolution of 1.00ms, which the cap depends on. The FPS cap will not work properly unless the timer resolution is 1.00ms. On Windows 10+, the timer interrupt source was changed which broke the cap. Therefore you will see strange values, and the cap will not be stable. You must use Windows 7 or older if you want a properly working cap without having to use an external frame limiter which adds at least 1 frame of delay.
For server admins:
From webadmin (or from in-game, prepend "admin" to the command while logged in), you can paste the commands below and they will take effect after a map switch:
Code: Select all
set Engine.GameInfo MaxPlayers 16
set IpDrv.TcpNetDriver MaxClientRate 1000000
set IpDrv.TcpNetDriver MaxInternetClientRate 1000000
MaxInternetClientRate = Bandwidth limit, in bytes, of how much data the server can send to each client. As a server admin you must increase MaxInternetClientRate so the server can send more data to clients, otherwise information will be dropped once your server hits the default 10000 limit. Set it to 100000 and forget it unless you run a high tick rate, heavily populated server, in which case you will need to go above 100000. This setting takes effect after a map switch (via set command).
NetServerMaxTickRate = Server tick rate. The higher the tick rate, the lower the interval between server game state updates, which requires more bandwidth to relay information to clients. Increase MaxInternetClientRate accordingly to ensure data doesn't get dropped. Tick rate can be adjusted on the fly; instant effect (via set command). The max tick rate is 125 (120 on Linux/newer Windows). The higher the tick rate, the higher the CPU usage, but any modern CPU should be able to handle 40+ even with 32 players. Higher tick rate also obviously results in lower in-game ping (time between ticks decreases).
Code: Select all
set IpDrv.TcpNetDriver NetServerMaxTickRate #
Code: Select all
admin getcurrenttickrate
Code: Select all
[Engine.GameInfo]
MaxPlayers=16
Conclusion:
Once everything is properly configured on both the server's and clients' sides, the "In" and "Out" bandwidth in bytes shown in the image above should no longer be constrained to the default 10000 limit, which means no more bandwidth limit-related lag.