Multiplayer Servers

In general running a Yamagi Quake II server is the same as running a Vanilla Quake2 server, so the old guides should still apply.

One thing to keep in mind is that the server must be restarted at least every 49 days, because the Quake II network protocol represents the interal time as a 32 bit integer and after 49 days that integer overflows, leading to all kinds of trouble.

This problem has always existed in Quake II and is not fixable (at least not without breaking compatibility with the existing network protocol), but back in Win9x days this was less of a problem because Windows crashed frequently anyways and Win9x had the same bug and crashed after 49 days or so...

Apart from this, we'll only document changes/additions here.

Security considerations

Quake II was released in 1997 into a world where security didn't matter. The most important thing when connecting to random servers is: Quake II allows the server to do anything on the client! The server may execute any console command, it may overwrite any cvar, download any file to your computer and given the rather fragile state of the command parsers chances are high that there are remote code execution vulnerabilities. Only connect to trustworthy servers!

HTTP Downloads

Like r1q2 and some other Quake II source ports, we allow downloading game data for multiplayer via HTTP. This is a lot faster than the Quake II internal protocol that was used in the original client and Yamagi Quake II up to version 7.30.

As a client you don't have to do anything, just use a Yamagi Quake II version newer than 7.30 and if you build it yourself don't disable cURL support.

For servers the following must be done:

Put the game data on a http server

The directory structure on the server must be the same as in the game, so if you want to provide maps/foo.bsp and your server base path is http://example.com/q2data/, then you must put that map into http://example.com/q2data/maps/foo.bsp.

You can either just put the raw .bsp (and files the bsp needs, textures, modes and so on) on your HTTP server, or you can upload a whole .pak or .pk3 that contains the needed data. If you're using a .pak or .pk3 you need a file list that's hosted on your http server.

Map specific file lists

One way is to have one file list for each map that's running on your server. If your server is rotating between maps/foo.bsp and maps/bar.bsp, you'd have http://example.com/q2data/maps/foo.filelist and http://example.com/q2data/maps/bar.filelist.

A file list is a plain text file that lists one file path per line that's to be downloaded. Those paths are relative to the server base path and must not begin with a slash!

So if maps/bar.bsp needs bar.pak and textures.pak, your http://example.com/q2data/maps/bar.filelist would look like:

bar.pak
textures.pak

Global File List

Instead of map-specific file lists, you could have one global file list. All those files are downloaded when someone connects to your server, regardless of the currently running map.

This global file list must be at your server base path and must be called .filelist.

So in our example http://example.com/q2data/.filelist could look like:

bar.pak
foo.pak
textures.pak

maps/bar.bsp
maps/foo.bsp
textures/my_tex.wal

Configure the Quake II server to tell clients about the HTTP server

All you have to do is to set the sv_downloadserver CVar to your server base path, so in our example you could start your dedicated server with q2ded +set sv_downloadserver http://example.com/q2data/ (+ your other options).

This CVar will be set to connecting Multiplayer Clients and if they support HTTP downloading they will try to load missing game data from that server.

Map rotation

Map rotations are configured through the sv_maplist CVar added with Quake II patch 3.15. The map list must be enclosed in quotation marks and all maps must exist. Start the game with the first map.

For example: q2ded +set sv_maplist '"q2dm1 q2dm2 q2dm3"' +map q2dm1

4 KiB Raw Blame History