Quake protocal history
Quake protocal history
Probably the item I know the least about is the protocal...are there any online guides anyone knows of ? Also, are packets sent and rcvd pretty much like standard email / http / tcp packets ? Is it possible to compress packets to reduce BW or do they already do that?
Re: Quake protocal history
DarkPlaces uses DPP7 protocol by default (includes prediction, better data handling and better data in general from what I heard ... like sends info in float-point precision, but delta compressed). Very optimized. Quakeworld uses Quakeworld protocol which is very optimized (delta compressed; lossy ... like I think it will send 64 entities MAX in pure original Quakeworld!). NetQuake doesn't compress anything or make any efforts to reduce size.Cobalt wrote:Probably the item I know the least about is the protocal...are there any online guides anyone knows of ? Also, are packets sent and rcvd pretty much like standard email / http / tcp packets ? Is it possible to compress packets to reduce BW or do they already do that?
In NetQuake the client sends "user intentions" to the server plus commands. Like what direction they want to move in the form of pitch, yaw, roll and the wanted speed plus what buttons are down plus any special command impulses or literal commands "god" and so forth. This is not very big, but it happens too often. If you run at 500 FPS on the client and are getting 500 FPS, you are sending it 500 times. And the server does not need it hardly that many times per second.
In NetQuake the server sends all visible entities (slightly flawed, which is why anti-wallhack is desired to improve this), any sounds and particles (sounds and particles are not visibility tested or anything) and applicable fields for those entities (xyz origin coords, angles for x y z) flags and stuff. Plus status bar infos.
But basically when you record a demo in NetQuake that is what the server is sending and it is unnecessarily big.
That's my rough description from what I know +/- maybe a little of detail error, but basically correct I believe.
Google for Quake protocol #1 hit = http://www.gamers.org/dEngine/quake/QDP/qnp.html
The night is young. How else can I annoy the world before sunsrise? 
Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..Re: Quake protocal history
Thanks Baker, interesting.
From what LH tells me, the old packet overflow from too many entities wherby the entities start blinking on the screen is eliminated with DP7 protocal. I had wondered because I saw it happen way back, but I had de-selected DP7 because I wanted to keep my mod open for older clients to
still connect with. I think he also said that unless an entity's data changes during mp, its not transmitted as part of the packet, sort of in effect it becomes a 'static' entity for lack of a better description......alais my terminology may need better selection there.
Also, is a demo pretty much a file representation of the corresponding network transmission as if it were broadcasted in mp?
From what LH tells me, the old packet overflow from too many entities wherby the entities start blinking on the screen is eliminated with DP7 protocal. I had wondered because I saw it happen way back, but I had de-selected DP7 because I wanted to keep my mod open for older clients to
still connect with. I think he also said that unless an entity's data changes during mp, its not transmitted as part of the packet, sort of in effect it becomes a 'static' entity for lack of a better description......alais my terminology may need better selection there.
Also, is a demo pretty much a file representation of the corresponding network transmission as if it were broadcasted in mp?
Re: Quake protocal history
a demo is basically a collection of the packets received by the client as well as the timings, yes.
qwd demos also contain the outgoing movement commands, so you properly see predicted positions as the original player did.
mvd demos have no pvs checks, with masks describing which client was sent directed commands (like stuffcmds/centerprints etc) which are conditionally read, and stats for all players which are always read but updated for the player they were 'directed' to.
you can still get packet overflows with any protocol if the mod spams eg particle() builtin calls. You just won't get them from 30000 entities visible all at once.
QuakeWorld and DP5+ protocols do not need to resend motionless unchanged entities to keep it present in the client. Note however that these protocols will still send the entity as it leaves/enters pvs.
I'm unsure about earlier DP-specific protocols.
But the vanilla NetQuake protocol (as well as 'QUAKEDP', fitzquake, etc) requires network traffic to 'refresh' the entity in every (unreliable) packet. Each entity will be resent from its baseline. An entity which exactly matches its baseline will consume 2 or 3 bytes per packet, but if its moved, rotated, etc then it will take more space up to a maximum of 17 bytes (with vanilla) in every single packet.
qwd demos also contain the outgoing movement commands, so you properly see predicted positions as the original player did.
mvd demos have no pvs checks, with masks describing which client was sent directed commands (like stuffcmds/centerprints etc) which are conditionally read, and stats for all players which are always read but updated for the player they were 'directed' to.
you can still get packet overflows with any protocol if the mod spams eg particle() builtin calls. You just won't get them from 30000 entities visible all at once.
QuakeWorld and DP5+ protocols do not need to resend motionless unchanged entities to keep it present in the client. Note however that these protocols will still send the entity as it leaves/enters pvs.
I'm unsure about earlier DP-specific protocols.
But the vanilla NetQuake protocol (as well as 'QUAKEDP', fitzquake, etc) requires network traffic to 'refresh' the entity in every (unreliable) packet. Each entity will be resent from its baseline. An entity which exactly matches its baseline will consume 2 or 3 bytes per packet, but if its moved, rotated, etc then it will take more space up to a maximum of 17 bytes (with vanilla) in every single packet.