Easier LAN coop play of classic Quake

[Baker]

[Spike]

Make your network socket broadcast capable, send a CCREQ_SERVER_INFO message to 255.255.255.255:26000, and see who replies. No need to send to every node individually (routers and isps will automatically restrict broadcasts to be site-local).

Do you really need a new distinct protocol? Can you not hide the difference within a stringcmd? Possibly one with a leading // ?

[Baker]

[Spike]

stuffcmd(self, "//gamedir \"MYMAGICGAMEDIR\"\n");

clients that understand '//gamedir' stuffcmds will change gamedir. clients that do not will silently discard it. its like a hidden svc.
so things won't break just because you added a hint.
The // is optional of course. omiting it means it'll work in existing clients that support a gamedir console command, but will be spammy. But hey, maybe that extra line of spam will give the motivation required for more engine authors to add support.
You'll of course need to ensure that its sent before the (nq) svc_serverinfo message, to ensure that its present before the precaches are seen.

If you want something more complex, you can try adding a handshake. You can mimic fte and do:
stuffcmd(self, "cmd pext\n");
and have the client translate that to:
localcmdf("cmd pext \"%#x\" \"%#x\" \"%#x\" \"%#x\"\n", e1_vendorid, e1_flags, e2_vendorid, e2_flags);
then have the serverdata mention the activated vendorid+flags in the serverdata just before the normal version (with the base protocol version acting as a terminator), so the client knows what's actually in use by the server too.
Which is how fte negotiates its protocol extensions when using NQ protocols.
If the client doesn't understand it, the server still sees a 'pext' clientcommand with no arguments, so no extensions, and if the client does support stuff, the server can read the argument pairs to see the vendor+flags info and pull out the things that it does know.
Yeah, okay, with this handshake demos will probably need a matching client for playback, but hey, you'd need that if the server was using some forced extension too.

worldspawn keys can be prefixed with a _ in order to silence them, a // prefix won't work there.

[Baker]

Tried out your trick. Now of course you know it worked too, otherwise you wouldn't have suggested it.

Very nice trickery there. With the "//" it doesn't even print bad command but CL_Parse sure can look through it.

[Baker]

[Spike]

copy-pastaing from quakeworld?
things to look out for:
nextdl is reliable and syncronous. this requires round-trips.
dltype_t is a little bit evil.
dp's download protocol might be slightly more supported amongst NQ clients, and is indeed detected using some stufftext hack.

package-at-a-time is generally prefered over file-at-a-time, yes. You probably don't want the engine to recognise .zip files, only .pak and .pk3 files.
note that if you connect to an fte qw server, the server will send a few package names and hashes. the client can then download/load the named packages. because the hashes are known to the client, the client can avoid infecting games when playing on other servers, plus has a mechanism to cope with serverside mod upgrades, but you do have to write code to cope with paks potentially being loaded/purged between maps.

of course, many mods simply don't provide paks, or engines already downloaded a file-at-a-time, so you typically won't really get a choice.

[Baker]

[Spike]

if you want speed, the easiest way is to just make the server act as an http server too.
quakeworld's downloads are syncronous, so slow.
dp downloads are pretty fast, but if you get packetloss it'll reset to an earlier point with lots of wasted bandwidth (mitigated by conservative rate settings, this isn't a real issue, but those rate settings will slow things down).
fte's downloads also lack a slow-start bandwidth estimation (this is more a client-side omission rather than a protocol issue). It doesn't care too much about packetloss, but can easily ping you off the net if your (d)rate is too high.
Set up a basic http 1.0 server, get the client to download from that. No demo bloat, proper flow control, fork a thread on your data connection (once the file has been opened on the main thread) and it'll just fly over the (inter?)net with no framerate/quake limitations. But does unfortunatly require another port to be opened, and is thus more likely to be unusable than a udp-based download. Your choice really.

[Baker]

[frag.machine]

[Baker]

[Spike]

a basic http server is not fantastically hard.
create a listening socket. bind it to a port. call listen.
periodically call accept on it to see if anyone tried to connect. this gives you a new socket.
wait for the client to send 'GET /resource HTTP/1.X\n\n'. ignore any extra lines between the 1 and the new line.
open the file. create a new thread. send "HTTP/1.0 200 OK\nContent-Length: %i\nConnection: close\n\n$FILE" close the socket, close the file, terminate the thread.

connection: close is optional. without it the client is free to send a second request after the first, which while otherwise desirable, results in sync requirements with the main thread.
add Content-Encoding: gzip if the contents are gzipped, and the receiver is meant to un-gzip it before use.
new lines (in http's headers) should ALWAYS be \r\n. I'm lazy in my descriptions. Be prepared to accept just \n too, but don't generate it. an empty line demotes the end of the http 1 headers.

or just grab fte's httpserver.c file (with curl or fte's httpclient.c file for the clientside part).
by all means use some other server, or directly use a simple tcp connection with no http semantics (ie: origional http...) but I do recommend making sure the server parts are automagic, and have the same file/copyright access restrictions as other quake servers (ie: no access to pak*.pak or its (map?) contents, and no access to root directory or configs directory, etc). in-process is imho the easiest to configure.

if you really want to get creative, look out for websocket connections too, and allow people to actually play via them.

[Baker]

[Baker]

Dissecting and friends ()...