incidentally, you can make your own custom music by making music files track13 and up, then just using the sounds field in worldspawn or the builtin SVC for cd playing in the qc. 

Spiffy! Thank you. 

many engines support arbitrary filenames so for custom tracks please avoid numbers but use distinct unique filenames Instead. 

numbers are better because you can use the builtin qc function to start music as well as the worldspawn key, which, if the engine integrates the mp3 playing PROPERLY should redirect to the mp3 reliably as opposed to stuffcmd'ing console commands that may vary between engines. 

engines should support any filenames for both of these options. the "cd play" command should be fully transparent/oblivious. 

"cd play 5" should play the 5th file in the list - easy as that. No need for requiring any track naming convention at all. 

5th file in the list.... the list being all music files located in the id1 music dir + mod's music dir? So if someone adds "aaa.mp3" to their id1 dir, then every other level you own will now play a different track? 

cd play 5 must play the cd track 5 or the equivalent external files which is track005 or track05 or something like that. 

"cd play 5" playing the 5th file in the list is unreliable and also is against the purpose of the cd command which is "playing track 5 of the cdrom in the drive" and nothing else.

The reliable solution is using a unique filename for every different music which what hexen2 did 15 years ago: see svc_midi_name of hexen2. In uHexen2, I further extended its use for music files other than midi such as ogg, mp3, wav. (Of course the drawback of the server message is that it dictates a new protocol.) 

How somebody adding an extra file to the directory is any way different to somebody popping in a different CD. Other problems arise. What if somebody puts both track01.mp3 and track01.ogg into the directory for an engine that supports both mp3 and ogg formats? What if somebody deletes one of the files? What if the author of another popular engine decides to use a different naming convention because they feel that it's somehow superior? There's only so far you can go to protect against this kind of thing before it becomes counter-productive. Ultimately I favour the approach that is most pragmatic and that offers the least surprise and least unexpected behaviour to the player - not the engine coder, not the mapper/modder - the player. If the player puts an extra music file in there, what do you think the player's expected behaviour is going to be? So code to that. 

since everyone has their own protocols anyway, i'd rather see a new builtin svc. 

What's wrong with testing in the following order:

cd play X
First attempts to find a file exactly called x
If that fails, but X is numeric, try to load a file called track0X.wav, then track0X.ogg, then track0X.mp3 (in decending order of *likely* quality).

Finally if none of those files exist then play track X on the cd in the drive

This lets you play extra files and is consistent with previous behaviour, except where players have intentionally put new trackXX files in the music directory. You can even do fallbacks: play gorkypark.mp3 if it exists (and the engine supports it), otherwise play track 4 from the CD, through the commands
cd play 4
cd play gorkypark.mp3
You can replace the first one with the SVC command from qc as well, stuffcmd only the custom one. I wouldn't worry about the overhead of a stuffcmd, because you aren't going to change the music on a frame by frame basis (the drive wouldn't even have spun up) 

your method makes a lot of sense for the use case of "user puts 10 audio tracks in a folder and expects the game to use those instead of the phyical CD in the drive."

The other use case, where modders want to include music with their levels, seems problematic to me. To correctly specify the music track, they can't use a number (since they don't know what else the user has installed, they don't know where their track falls in the order.) So they could use a name instead, and we could say that is the standard for modders including music. But, then we need a new mechanism for the server telling the client what track to play, since svc_cdtrack only allows a single byte.

However, the presence of mod music in id1 would screw up the user's music, since now there are extra tracks inserted in arbitrary order between the original 10 installed by the user. 

Should a mod even be putting music in id1? If a mod messed with id1 content to this kind of extent I would think it's overstepping bounds.

Maps are OK, but other kinds of content? That's the beginning of a slippery slope.

I appreciate the desire to play nice with what a modder might want, but the ultimate arbiter of everything is the player. If a mod shows disrespect to the player's desires, then the player will just not use that mod.

That's where I'm trying to come from here - what is the behaviour that the player expects? I'm not particularly religious about this - if it turns out that the player's expected behaviuour is something different to the way I've done it, then fine. I'll change. But it's the player's expected behaviour that calls the shots, not the modder or the engine coder. 

The naming convention for tracks benefits players, because it lets them selectively replace tracks and keep the CD for others. It's a side benefit that it opens the door for custom track playing in mods. 

agree that putting mods in id1 is not ideal, but in practice people do it when the mod is only adding files and not replacing them -- for example a map that comes with a custom skybox might just get installed in id1, the skybox won't hurt any other map by its presence. Or maps that have custom mapmodels as external bsp files -- those get installed in id1 also. 

Or maps that have custom mapmodels as external bsp files -- those get installed in id1 also.

you don't have to do this though. unless you mean replacement items? 

GLQuake or WinQuake cannot actually connect to FitzQuake 0.85 running protocol 15.

You get "CL_ReadFromServer: lost server connection".

If I revert MAX_DATAGRAM from 32000 to 1024, it works. I made an effort to track down exactly where as a server this is failing, but the "cascading dependency tree of this constant" is rather staggering and I'm not quite sure how to plan how to catch this problem.

For all practical purposes, it isn't really "a problem" except that this issue breaks the intended design that it should be backwards compatible to GLQuake (which no one is using).

I made a few attempts to pin down the cirumstances, but that MAX_DATAGRAM constant gets reused in the form of other constants (#define NET_DATAGRAMSIZE (MAX_DATAGRAM + NET_HEADERSIZE)) and a the number of "> sizeof(something)" statements in the client, server and network code is no small count.

Recording here for the sake of doing so. I discovered this issue a year ago. I had preferred the idea of posting the problem with a the solution as well. 

R_Novis_f sets variable "vis_changed = true"

The vis_changed variable doesn't get reset to false in R_Marksurfaces. 

MAX_DLIGHTS is 64 but dlightbits is still a single int. What is the result of "surf->dlightbits |= (1 << num)" where num > 31? 

Looks like FitzQuake isn't the only engine with the dlights issue.

I do see that Qrack doesn't have that issue, it is commented "//MH: robust support for increased dynamic lights" 

Oh boy, that's a nice one. What is the solution? changing dlightbits to long long type? 

int dlightbits[MAX_DLIGHTS >> 5];

if (!(surf->dlightbits[lnum >> 5] & (1 << (lnum & 31)))) continue;

surf->dlightbits[num >> 5] |= 1 << (num & 31);

Exact same code is as used for vis; that should work for everything. 

I see. and the int should possibly be changed to unsigned, too.