By Raffi_B
Part 1: The basics.
"Newnet" is the altered netcode introduced by the competitive mutator UTComp in versions 1.6 and later. Newnet was designed to simulate as accurately as possible a ping-free environment in which you could shoot players where they are on your screen instead of leading them.
Naturally this ping-free environment would have some problems, otherwise the developers would have thought of it and implemented it.
The main problem that most people are vocal about is the persistence of "dud" hitscan shots, or shots with a hitscan (instant hit like the shock rifle or lightning gun) weapon that appear to hit on your screen but don't actually do damage.
In order to explain this problem and minimize it, we must first understand how net-play works in the Unreal-engine in general (both newnet on and off).
There are certain things that a simple mutator cannot modify. These things are located on the engine level, which users cannot access without paying for the engine license. Net-play in the Unreal-engine, like almost all first-person-shooter engines, works with a client/server system. Basically, clients send data to the server, the server interprets the data, then the server distributes the data to the clients. This is a seamless process in most games and is barely noticable. With this system, the server has full control of the gameplay at all times. A client cannot force the gameplay to be a certain way without first sending that action to the server and having the server interpret it. The advantages to such a system are that all clients should be relatively synchronized (seeing the same gameplay) and that if a client crashes or disconnects, the gameplay can continue without interruption. This system is also far more secure.
Regardless, one disadvantage to this system is that overall bandwidth usage is increased. The Unreal-engine, however, does a remarkable job at minimizing bandwidth consumption. One way in which it achieves this goal is by using active client-side interpolation/prediction. What that phrase means is that even when there is no data being sent to a client, the client attemps to predict what is going on in the game.
An example of this is something we've all experienced: lagging out. When you lag out, everyone starts running in straight lines then colliding with walls or falling off the edge of a cliff. What is happening here is that your computer is calculating player locations and velocities based on the last data that was sent to you from the server.
The main purpose of this client-side interpolation system is that data can be sent from the server to the clients less often, since the end result will appear nearly the same on the client's screen. However, with this system a few glitches become apparent. If the client-side interpolation predicts incorrectly, player locations will suddenly jump when the server sends new data. Imagine playing on a server that sent data to you once per second. You would receive new data at the beginning of every second, then for the rest of that second the players will move in a constant direction and velocity based on that data.
Basically, as the data is sent more often from the server to the clients, the negative effects of this client-side interpolation are minimized, but of course bandidth usage is increased.
There is a technical term for how often the server calculates and distrubutes data. This term is "tickrate". The default tickrate for UT2004 servers is 20. This means that once every 50 ms, the server receives, processes, and distributes data. Therefore, increasing tickrate greatly improves responsiveness and smoothness of a server, but it also increases CPU usage.
A few visual examples of this, along with more information about tickrate and netspeed, can be seen in TNSe's guide to tickrate and netspeed.
Another facet of net-play we have to understand is that the internet isn't perfect. In ideal conditions (zero packet loss), the server and the client are fully synchronized. This means that at any given time, if you were to pause the game on both machines, you would receive the same data. Packet loss refers to the actual loss of some of the data being sent to you from the server (or visa versa). This loss can occur for many reasons. If the internet connection on either end of the client/server exchange is poor, then loss will occur. If the server has a high CPU load, certain data will be clogged in a massive queue and loss will occur. If you have your netspeed set to low (or if the server has a low max client netspeed) then the game will automatically drop certain packets in order to meet that quota. Packet loss is actually quite common in UT2004, but in normal gameplay it is barely noticable because of that client-side interpolation. You might notice a slight jerk when the server occasionally corrects player locations, but that's about it.
Part 2: How the basics relate to newnet.
During normal (newnet off) gameplay, packet loss does not affect hitscan in the same way it does when newnet is on. In either case, your fire trace data is processed by the server as soon as it is received. This means that even in a LAN environment, if the tickrate were set really low you would notice that your shots would appear to be lagging because the data is being processed very infrequently. An advantage of this system is that even if packet loss occurs, the server and client would simply pick up from where they left off and the fire data would be processed at the next tick.
How does newnet fit into this equation?
For the purposes of this article, let's only talk about how newnet affects hitscan weapons, since that is what most people care about. When you press the fire button, the effect of your weapon fire is drawn instantly. All this means is that if you're holding a lightning gun, for example, the lightning beam will be drawn on your screen as if you were playing offline. However, the shot data obviously cannot be sent instantly to the server.
One thing that is absolutely critical when understanding how newnet works is how it differs in handling client-side interpolation. If newnet is on, if you get even a minor spike of packet loss, the client-side prediction will take over briefly and you'll see the player moving across your screen. If you press the fire button at this time and the enemy is under your crosshair, your computer will draw the fire effect and calculate the collision of that effect (all client side). This means that your lightning beam may appear to hit your enemy's hit box.
However, one thing we discussed earlier is that everything in the Unreal-engine is divided into ticks. This interpolation that you experienced was not actual data sent to you by the server. It is simply something your computer made up in order to fill the gap of packet loss. Since what you saw on your screen may not have occured on the server, your shot may not count.
In other words, whenever you fire at an opponent when his location is being predicted and altered by the client-side interpolation mechanism, that player's location may not be his actual location on the server.
In order to simulate the ping-free environment, newnet checks player locations at the time of your shot based on a certain number of ticks ago, and not interpolation. If newnet checks the server's record of player locations at the tick when you fired your shot and your shot was a miss, it will not do damage, regardless of whether or not your client calculated the shot to be a hit or a miss.
Since when newnet is off, the game does not draw any effects client side, all player location and effect data is received from the server and the server fully decides if your shot was a hit or a miss. When newnet is on, the server still has full control over deciding hits and misses, but you may be shooting at something that isn't really there.
If data for a few ticks undergoes packet loss, if you shoot during that period of time you may not be seeing the enemy in the correct location. If the shot appeared to land on your computer but it didn't really hit the player on the server, you will get a dreaded dud hitscan shot.
"False positives" occur based on the same concept. The player appears to be somewhere on your screen but in reality (reality = the server) the player is somewhere else. This occurs because of the same reasons as dud hitscan shots. When the client misses a few ticks of data, client-side interpolation takes over and the enemy moves on the screen. If you shoot and your client calculates a miss but the server calculates a hit, all this means is that the enemy was truly hit by the shot but it just didn't appear this way on your screen because you missed that data.
Part 3: Minimizing the effects.
One way to minimize the affected time in which dud hitscan shots can occur is to increase the server's tickrate. The more frequently the data is sent to and from clients, the less likely it is that the player will be shooting at the client-side interpolated position of the enemy rather than the actual position of the enemy. Since data is sent once per tick, if that data is lost, client-side interpolation takes over for that tick, causing a temporary desynchronization between the client and the server. The following graph demonstrates this. Packetloss is highlighted in red, and corrupt ticks that cause client-side interpolation are highlighted in blue.
Increasing the tickrate, as mentioned before, does use significantly more of the server's CPU time and also uses more bandwidth, so be sure to contact your server host before altering tickrate at all.
To summarize:
Newnet is very sensitive to even minor packet loss or a low tickrate. Since newnet cannot interpolate in the same manner as your client, this creates temporary periods of desynchronization. Play on a server with minimal packet loss and a high tickrate in order to get a more accurate judgement of how newnet works. Joining a 32-player ONS with newnet on wouldn't yield accurate results, whereas joining a 1v1 server would. When the server is performing optimally with minimal packet loss on that end of the client/server exchange, newnet's false positives and dud hitscan shots will greatly decrease.