"Quake 2" vs Other Quakes's Netcodes!

[Lejionator]

hi, folks!

I would like to know how works the quake's netcode. The explanation need not be as technically deep, but something that laymen can understand well. I an explanation of the q2's netcode vs other quakes and its advantages over each other. I remember that the q3's netcode is unlagged q3, as well as of the quakelive, and q1 is not based on tpc/ip. Or am I wrong? Please, this is all very important to me!

Thanks very much in advance, veterans! 

[haunted]

the tick rate in q2 is 10hz, opposed to q3 being 30hz.. this relates with the delay it takes for inputs to be recognized, and the hert is a measurement of time basically since it equates to seconds^-1 or 1/seconds. So, the shorter one obviously takes longer. this is why you have to lead with rg in q2 a bit even on lan. it makes q2 less aim-based, although there is an art to aiming well in q2 prominently involving prediction. additionally, due to the lack of emphasis on aim in q2, as well as the movement/aerial physics in q2 which are more extensive than other quakes, this in turn puts a greater emphasis on movement in q2.

[reaper]

quake 2 also has the double jump and gaining speed from slopes which makes the movement better.

I don't know much about quake 2 netcode, but I imagine they're all UDP which is contained within the IP packet.  UDP doesn't guarantee transmissions, it just sends or recieves and the application handles what to do.  UDP is used because you want to send and receive the information right away without retransmitting it.

I've never really noticed a problem with it unless there's packet loss, and packet loss is the problem.  probably a lot of problems went away after people moved of dialup, and switched to r1q2

[VaeVictis]

to dumb it down significantly

q2 and qw help you with movement, but not aim, so aim ahead of your target to compensate for delay (q1 even had delay in movement, not sure, never played netquake)

quake3 had some cool unlagged code that was much improved by cpma but takes some tweaking to work great, same goes quakelive

while quakelive is much better than q3 and takes less configuration than cpma, all 3 tend to make you aim BEHIND your target to land shots perfectly (you heard me), i usually use negative time nudge to push it more to even or where im used to aiming in q2 (though not as drastic)

quake4 is kind of like the q3 netcode... but just plays different, not sure what is so different about it, but it aint bad once you get used to it


with the older quakes, quake2 specifically, you dont get any bullshit shots... if a rail hits, its obvious to see it hit, in the later games you can get some rails that to your visuals go right through, but as far as the server is concerned can be hitting air... this makes some people happier, where they can actually see what is happening as far as the server is concerned

[quadz]

There's an excellent series of articles delving into DOOM/Q1/Q2/Q3/DOOM3 architecture

The Q2 article doesn't cover netcode in depth:
http://fabiensanglard.net/quake2/index.php

However, Q1 netcode is similar to Q2 if you're looking for an overview:
http://fabiensanglard.net/quakeSource/quakeSourceNetWork.php

Q3 netcode changed quite a bit:
http://fabiensanglard.net/quake3/network.php

[Jay Dolan]

Nice, quadz. I hadn't seen these before!

[Lejionator]

the tick rate in q2 is 10hz, opposed to q3 being 30hz.. this relates with the delay it takes for inputs to be recognized, and the hert is a measurement of time basically since it equates to seconds^-1 or 1/seconds. So, the shorter one obviously takes longer. this is why you have to lead with rg in q2 a bit even on lan...

You said that because of the default "low tickrate" of q2, everything in the q2 ambient takes a a bit delay, then I need always have, for example, to lead my railshots even in lan.
The tickrate is not configurable in q2, as in Counter-Strike? You mean q2 will always tickrate 10Hz unalterable. The snapshot is the  tickrate of q3, am I right?

...but I imagine they're all UDP which is contained within the IP packet.  UDP doesn't guarantee transmissions, it just sends or recieves and the application handles what to do.  UDP is used because you want to send and receive the information right away without retransmitting it.

I've never really noticed a problem with it unless there's packet loss, and packet loss is the problem.  probably a lot of problems went away after people moved of dialup, and switched to r1q2

So the default q2 netcode uses the system "send/receive UDP packets". I think the UDP system is old and is no longer used in moderns FPS games of today, right? If the netcode of r1q2 is different, so what is the system used by it?

q2 and qw help you with movement, but not aim, so aim ahead of your target to compensate for delay (q1 even had delay in movement, not sure, never played netquake)

quake3 had some cool unlagged code that was much improved by cpma but takes some tweaking to work great, same goes quakelive

while quakelive is much better than q3 and takes less configuration than cpma, all 3 tend to make you aim BEHIND your target to land shots perfectly (you heard me), i usually use negative time nudge to push it more to even or where im used to aiming in q2 (though not as drastic)...

The "unlagged code" emerged with default q3, right? Theoretically you do not need to aim ahead to hit, but RIGHT IN THE MODEL. But it is frustrating because sometimes you don't hit! I've had these experiences (I'm a hpb also in quakelive)! As theoretically "unllaged codes" works differently of UDP packets system?

There's an excellent series of articles delving into DOOM/Q1/Q2/Q3/DOOM3 architecture

The Q2 article doesn't cover netcode in depth:
http://fabiensanglard.net/quake2/index.php

However, Q1 netcode is similar to Q2 if you're looking for an overview:
http://fabiensanglard.net/quakeSource/quakeSourceNetWork.php

Q3 netcode changed quite a bit:
http://fabiensanglard.net/quake3/network.php

Thank you, Quadz! This was cool, but NOW I need translate it all! 

Thank you for your attention, friends! 

[VaeVictis]

most games still use UDP, very few use TCP instead

UDP has much less overhead, making it the better choice

when a UDP packet gets dropped, you basically just miss the data and skip a little, when a TCP packet gets dropped, the data is resent and so it can behave funky for real time applications

[haunted]

the tick rate in q2 is 10hz, opposed to q3 being 30hz.. this relates with the delay it takes for inputs to be recognized, and the hert is a measurement of time basically since it equates to seconds^-1 or 1/seconds. So, the shorter one obviously takes longer. this is why you have to lead with rg in q2 a bit even on lan...

You said that because of the default "low tickrate" of q2, everything in the q2 ambient takes a a bit delay, then I need always have, for example, to lead my railshots even in lan.
The tickrate is not configurable in q2, as in Counter-Strike? You mean q2 will always tickrate 10Hz unalterable. The snapshot is the  tickrate of q3, am I right?

Q2's tickrate is 10hz, q3's 30hz, and relatively(relative to these games) newer games you can customize it. So no, you cannot configure it in quake 2. Unfortunately, due to how q2 was actually built, it would be a severe pain in the ass(impractical) to attempt to make it configurable client side.

But, QL for example, I think it's set on q3's 30hz by default yet can go up to 120, if I recall correectly.

[Jay Dolan]

Not really. Quake2World's network protocol is still mostly based on Quake2, and I've added a configurable tick rate (default 30, but 10-120 are valid). It actually doesn't take that much work at all:

• Update server's sleep loop
• Add the tickrate to the svc_server_info / connect handshake
• Fix a few odd occurrences in the game code where 100ms frames are assumed (most of the game code is good about explicitly asking for 100ms intervals)
• Track the time at which key frames change per entity, because you can't simply interpolate from n-1 anymore (you'll end up with really fast, goofy looking player/flag animations)

I think I did all of that in one rainy Saturday. 

[haunted]

I was honestly just trying to recall what you told me jay, thanks for the clarification.

[Jay Dolan]

No worries. I just figured I'd chime in since, of the things I've wrestled with in making Quake2 a little more flexible, this was one of the easier ones.

R1CH was also working on a configurable Hz extension for Protocol 35 and OpenTDM. I know he had it working-ish, but I'm not sure he ever released it.

[haunted]

Yeah I remember testing that for him.. DaHanG thought it was still fairly glitchy in comparison to Q4/QL(if QL was out at that time.. close).