[T:V] Netcode and issues with lag

tribes has always had an excellent net code, i don't expect anything less from it

it would be nice to make the ping in the server browser around the same as what you get ingame, in T1 the ping in the browser is usually pretty close, however i can ping 8 to servers in the browser and 60+ ingame which annoys me in t2

Network code is a strange beast. Your average "out-of-game" ICMP ping could measure 10ms, but T2's ingame ping would indicate 40-50ms. This is due to the processing overhead if any operating system's internals and also the need for a simulation on the server to run at a fixed speed.

Example: T2 servers would run at as high a simulation (tick) speed as the OS's internal clock would allow. This, on the average PC is around 18ms, at minimum. This means that tribes2.exe (in server mode) could have received your packet within 10ms, but it still has to wait for a "tick" before it can process the packet (since tribes2.exe is a single-threaded program).

This means that after 10+18ms, your packet gets processed. If you're lucky, a response gets shipped off immediately, making for a 10+18+10ms round-trip time. THEN, your tribes2.exe on your PC still has to process the response, adding probably about another 7-10ms.

So in the end for a simple "tribes2" ping, it could take between 40-50ms before you actually got a response to your ping. This is much different from an ICMP ping, which typically gets handled at a "kernel" level on machines, hence a snappy response time.

Games, on the other hand, run in "user" space, and are at the mercy of the system's multitasking, and timer allocation. They have no control over when they will receive control.

Dynamix attempted to optimize this by using an alternate timer method on Windows machines, but unfortunately due to windows's bugginess the alternate timer method worked like crap on Hyperthreading, and Dual CPU machines. The ideal would be for game servers to install a device driver, with ring0/kernel access that could generate a fixed, predicatble timer whilst hosting a server, or a client.

This is pretty advanced programming tho, and can lead to who knows many support issues.

Tribes2's netcode was an enhancement, and extension of T1's netcode. Together with interpolation, prediction, and the various reliable/nonreliable delivery methods of data it is one of the most awesome game networking stacks in history. Go read up on the unreal network code's methodology, and you will see REMARKABLE similarities between it and Mark Frohnmayer's original document about the T1 netcode circa 1998.

Everything the Unreal engine learnt/does with netcode was done by T1, back in the day, and enhanced in T2. Of course, the implementation these concepts in Unreal leave much to be desired. In fact, Ut2004 uses the original Unreal netcode, instead of the the UT2003 netcode, as it was more suitable to the vehicles in UT2004.

Torque (T2's) netcode is now available as an open-source library called the Torque Network Library, at http://www.opentnl.org/ and is still being maintained and enhanced by the people at GarageGames.

Viva le Dynamix: Mark Frohnmayer, Jeff Tunnel, Tim Gift, Rick Overman. These are the guys that defined FPS netcode for games the scale of T1 and T2.

nice... is it possible for IG to implement a torque-based netcode? or does the engine have no bearing on it?

Noo. Netcode is typically _extremely_ integrated in the engine and it's entire methodology. Unfortunately it isn't just a "plug out-plug-in" thing. The engine is rather tied to it. Only reason Epic could switch back to UT1 netcode was because the engine originally came from there, so it was a reasonable doable hack.

Damn.. ut netcode is horrible, I hope IG can make it tribes-worthy.

Network code is a strange beast. Your average "out-of-game" ICMP ping could measure 10ms, but T2's ingame ping would indicate 40-50ms. This is due to the processing overhead if any operating system's internals and also the need for a simulation on the server to run at a fixed speed.

Example: T2 servers would run at as high a simulation (tick) speed as the OS's internal clock would allow. This, on the average PC is around 18ms, at minimum. This means that tribes2.exe (in server mode) could have received your packet within 10ms, but it still has to wait for a "tick" before it can process the packet (since tribes2.exe is a single-threaded program).

This means that after 10+18ms, your packet gets processed. If you're lucky, a response gets shipped off immediately, making for a 10+18+10ms round-trip time. THEN, your tribes2.exe on your PC still has to process the response, adding probably about another 7-10ms.

So in the end for a simple "tribes2" ping, it could take between 40-50ms before you actually got a response to your ping. This is much different from an ICMP ping, which typically gets handled at a "kernel" level on machines, hence a snappy response time.

Games, on the other hand, run in "user" space, and are at the mercy of the system's multitasking, and timer allocation. They have no control over when they will receive control.

Dynamix attempted to optimize this by using an alternate timer method on Windows machines, but unfortunately due to windows's bugginess the alternate timer method worked like crap on Hyperthreading, and Dual CPU machines. The ideal would be for game servers to install a device driver, with ring0/kernel access that could generate a fixed, predicatble timer whilst hosting a server, or a client.

This is pretty advanced programming tho, and can lead to who knows many support issues.

Tribes2's netcode was an enhancement, and extension of T1's netcode. Together with interpolation, prediction, and the various reliable/nonreliable delivery methods of data it is one of the most awesome game networking stacks in history. Go read up on the unreal network code's methodology, and you will see REMARKABLE similarities between it and Mark Frohnmayer's original document about the T1 netcode circa 1998.

Everything the Unreal engine learnt/does with netcode was done by T1, back in the day, and enhanced in T2. Of course, the implementation these concepts in Unreal leave much to be desired. In fact, Ut2004 uses the original Unreal netcode, instead of the the UT2003 netcode, as it was more suitable to the vehicles in UT2004.

Torque (T2's) netcode is now available as an open-source library called the Torque Network Library, at http://www.opentnl.org/ and is still being maintained and enhanced by the people at GarageGames.

Viva le Dynamix: Mark Frohnmayer, Jeff Tunnel, Tim Gift, Rick Overman. These are the guys that defined FPS netcode for games the scale of T1 and T2.


Very cool explanation. Thanks! I had no idea that processing a ping (for games) required as much.

I havent seen any interviews/faqs of them mentioning anything about netcode..so pretty much expect T:V to have the exact same sucky netcode (btw unreal 1 had like the worst netcode of a fps ever made when it was first released). I hope T:V atleast manages to get full interpolation on all the animation/movement etc unlike the unreal games.

was hoping TheRoDent would explain T2's netcode again :)

I havent seen any interviews/faqs of them mentioning anything about netcode..so pretty much expect T:V to have the exact same sucky netcode

There was a post by KP way back in the fall that implied they were working on it to try to make 32 player server feasible, but that they weren't there yet.

We should consider that it was apparently playable for the Aussies on the E3 server, so that's a good sign that things don't completely fall apart at high ping.

Nice explanation Rodent :).

Noo. Netcode is typically _extremely_ integrated in the engine and it's entire methodology. Unfortunately it isn't just a "plug out-plug-in" thing. The engine is rather tied to it. Only reason Epic could switch back to UT1 netcode was because the engine originally came from there, so it was a reasonable doable hack.
I take it it's impossible then for the game to use the old fashioned (i.e. T1) netcode on normal machines and an enchanced version on those that have problems running it... :hrm: