Hi,

I'm looking for a description of the QuakeWorld protocol. Especially the challenge/response addition that was added later on.

found this http://www.gamers.org/dEngine/quake/QDP/qnp.html
and this http://en.wikipedia.org/wiki/Quake#QuakeWorld
hope it's ok, also where does your interest in this origin from?

Thanks but I'm afraid that the first one describes the original quake network protocol, not the one of quakeworld.


I found the sourcecode of a bot which does the older version of quakeworld (without the challenge/response handling). And since I run the modern quakeworld server at home I would like to adapt the code (server keetweej.vanheusden.com with most of the time the maps I made myself).

It's very simple, actually and works as follows.


protocol, qport and challenge are all integers.
userinfo is list of (key, value) pairs enclosed in double quotes.

http://www.quakebrasil.com.br/specs/qwspec11.html

http://www.quakebrasil.com.br/specs/qwPackets.html

http://www.quakebrasil.com.br/specs/quakeworld.html

http://www.quakebrasil.com.br/specs/qwprotocol.html

Thanks a lot!

Now before I find it out myself :-) what is qport? I did an strace/tcpdump on ezquake and qport is not the portnumber from which the client talks to the server, or is it and mvdsv just ignores it?

Hmmm, it looks (analyzing the ezquake code and reading comments) that it is just an other ip/port matcher. E.g. if a NAT router changes the real portnumber then quake will still be able to match the session using that number.

Ok, got a little further; the bot connects and starts talking to the server.
Now if I enable some debugging the bot, I see:

opcode <0x09>, Stufftext: `packet 192.168.64.1:27500 "ip 0 1084880358"

so it sends a msg with opcode 0x09 (which according to the botsource expects things like fullserverinfo, skins, changing, bf, reconnect) and with a payload of:
`packet 192.168.64.1:27500 "ip 0 1084880358"
what should I do with that? 192.168.64.1:27500 is indeed my server

something is definately going wrong as the server (mvdsv) logs this:
SZ_GetSpace: overflow: cur = 1446, len = 195, max = 1450
bot overflowed
WARNING: reliable overflow for bot
Client bot removed

svc_stufftext means to 'chuck this string on the console command buffer'.

'packet IP PAYLOAD' means to send PAYLOAD prefixed with \xff\xff\xff\xff to IP.
Its not really required, just pick a decent server that doesn't have realip enabled. Feel free to spoof your response IP and get other people banned instead. Its worth a laugh.

For the most part, svc_stufftext strings can be ignored when you don't recognise them.
cmd XXX (without this you won't connect)
fullserverinfo (gives \hostname\blah etc, not vital, no response required)
reconnect (treat as 'cmd new')
skins (treat as 'cmd begin %i' where %i is the servercount in the svc_serverdata)
setinfo (treat as 'cmd setinfo %s %s', propogating the two string arguments)
packet (send an out of band packet to wherever as mentioned above)

Those are the commands that need to be implemented. For TeamFortress, you may find that you need:
team
color
name
To be implemented too. These are just variants on setinfo.

Each of these strings are terminated by a new line, and not the end of the actual stufftext (which is of course terminated by a null). Just buffer and don't parse.

I've no idea what's up with mvdsv. looks like you're failing to respond to reliables properly thus overflowing your reliable buffer on the server.
But the server is meant to backbuffer it (and due to certain design issues, mvdsv has a whole lot of backbuffers...). So I really have no idea whats up with that.
Make sure you're sending clc_clientcommand with 'soundlist %i 0' when you read svc_serverdata, 'begin %i' when you read skins, 'modellist %i 0', when the soundlist is done ('soundlist %i %d' when it isn't yet, %d being the 'continue at' value), 'prespawn %i 0 %d' when the modellist is done (modellist like with soundlist when not, %d on prespawn is only used when arg2 is 0, and should be the xored-32bit-md5 of the bsp).
The rest is pretty much just sucking up data until you're connected... There's a lot of state, and you ought to store it all. But yeah, anything else doesn't need a response.
Oh yeah, due to some sort of bug in mvdsv, you need to send clc_clientmove every single packet, even if you're not even connected yet. This is only with mvdsv, no other server cares if you do or not.
And you're meant to send client packets at a rate of between 10 and 72 packets per second, although read the serverinfo for the real max.


The qport is a random number to uniquely identify the client. This is an alternative to the port. If either match, the client is considered the same by the server. This is a workaround for buggy routers that maintain NAT state for only 3 mins or other such stupid things.
Each time you attempt to connect to a new server, pick a new random one. Try and make sure it doesn't conflict with other clients on the same ip, of course. Use the process id, rand() and current time or something. Its 16bit.

Good luck with it.

Thinking about it, you've probably got multiple 'cmd new' packets being sent by your client. Or multiple modellists/soundlists.
That's probably why mvdsv is overflowing.

Your netchan layer is most likely buggy.

One can follow the progress of the port of bottim to quakeworld at:
http://keetweej.vanheusden.com/~folkert/bottim-quakeworld-fvh.tgz

All help & suggestions are welcome.