Network Protocols

From Quake Wiki

Revision as of 20:20, 8 November 2014 by Ericw (talk | contribs)

A Network Protocol defines how the Quake client and server communicate after the initial connection is established. Originally Quake only had one protocol, now called the Netquake Protocol. Later id Software released QuakeWorld, which included a major overhaul of the protocol designed to work well over higher-latency internet connections. Now that the source code is released, several custom engines have introduced their own network protocols to extend limits or add capabilities. When a client connects to a server, the server informs the client which protocol is being used, and the client will either adapt its behavior or disconnect if it does not recognize the protocol or cannot support it.

List of Protocols

metlslime added a To-Do; this list should be edited for accuracy, this was cobbled together from snippets of info.
Number Protocol Client Support Notes
15 Netquake Protocol quake.exe
Orignal Quake protocol
15 QUAKEDP LH: "darkplaces extended quake protocol (used by TomazQuake and others), backwards compatible as long as no extended features are used"
15 TOMAZ LH: "this unfortunately does not match up with the QUAKEDP protocol it claims to use, it has some different entity encodings, and it's not easy to fix this"
15 NEH15 almost same as 15, 8-12 byte transparency/fullbright data added on to entities. used by joequake, nehahra, and bjp (with sv_protocol 15)
28 Quakeworld Protocol qwcl.exe
id Software's improved protocol, optimized for netplay.
96 DARKPLACES1 LH: "uses EntityFrame entity snapshot encoder/decoder which is a QuakeWorld-like entity snapshot delta compression method"
97 DARKPLACES2 LH: "various changes"
250 NEHAHRAMOVIE LH: "Nehahra movie protocol, a big nasty hack dating back to early days of the Quake Standards Group (but only ever used by neh_gl.exe), this is potentially backwards compatible with quake protocol as long as no extended features are used (but in actuality the neh_gl.exe which wrote this protocol ALWAYS wrote the extended"
666 Fitzquake Protocol Fitzquake
Fitzquake protocol, introduced in version 0.85, supports more models, sounds, frames, edicts, adds entity alpha, high-precision client aim, and a few other things.
778 RMQ_MINUS2 DirectQ MH: "I'd been using DirectQ for protocol experiments at one point and unfortunately it got released. I'm pretty sure that the only difference between it and Fitz is that it uses floats for coords and angles everywhere. I'd say let it die; DirectQ itself is going back to 666 as the default. "
999 RMQ RMQ Engine
Remake Quake protocol, still in development and subject to ongoing changes. It is based on Fitzquake Protocol, but uses higher-precision coordinates and angles.
3500 DARKPLACES3 darkplaces LH: "uses EntityFrame4 entity snapshot encoder/decoder which is broken, this attempted to do partial snapshot updates on a QuakeWorld-like protocol, but it is broken and impossible to fix"
3501 DARKPLACES4 darkplaces LH: "various changes"
3502 DARKPLACES5 darkplaces LH: "uses EntityFrame5 entity snapshot encoder/decoder which is based on a Tribes networking article at [1]"
3503 DARKPLACES6 darkplaces LH: "various changes"
3504 DARKPLACES7 darkplaces LH: "added QuakeWorld-style movement protocol to allow more consistent prediction"
10000 NEHAHRABJP aglquake
LH: "same as NEH15 but with 16bit modelindex"
BJP: "Extended protocol (models > 256 etc), hopefully no conflict"
10001 NEHAHRABJP2 aglquake
LH: "same as NEHAHRABJP but with 16bit soundindex"
BJP: "Extended protocol (sounds > 256), problems with Marcher (Some progs (Marcher) send sound services)"
10002 NEHAHRABJP3 aglquake
LH: "same as NEHAHRABJP2 but with some changes"
BJP: "Extended protocol (sounds > 256), more compatible, but less functional"
10003 MH DirectQ MH: "Extended protocol, as 10002 but extends coords to full float"
1480938566('FTEX') 843404358('FTE2') FTE Protocol Extensions fteqw
Due to the use of a handshake, you will typically only see errors relating to these protocol numbers within demos. The exact featureset is expressed as a bitmask of separate extensions to an underlying protocol, typically QW but potentially Fitz/NQ protocols also.

Unsorted Pages