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. 

Fixed in the quakespasm svn, rev. 694
http://quakespasm.svn.sourceforge.net/viewvc/quakespasm?view=revision&revision=694 

Good catch on the "dlightbits[(MAX_DLIGHTS + 31) >> 5];" part - I'd missed that. 

I keep getting this error when reload my map, it is not always happening but I am not sure why. I have searched for any solution but could not find any. Using Fitz 0.85 engine, I have not generated any coloured lighting and not using a LIT file.

TexMgr_ReloadImage: can't colormap a non SRC_INDEXED texture: lightmap027
TexMgr_ReloadImage: can't colormap a non SRC_INDEXED texture: lightmap027

When I wander around the map, certain parts (always random as far as I can tell) seem to be missing all colour information and look greyscale. If I reload the map again, it often goes away or just moves around to another texture.
Any clues what this is? 

sounds like a code bug; somewhere the pointers are getting messed up i think. I don't think there is anyway for data to cause that error.

FYI: what's happening is it is trying to set up the player texture (which has swappable colors i.e. "colormapping") but the data pointer is referencing a lightmap instead. 

I initially thought it affected only certain textures (X/Y) sizes, but it happened on a 64x64 pixel texture last night. I was using a fast compiled map to do some testing, so I did a full compile and still got the problem, just not as frequent as before. It also gets worse the more times I use quick save/load. It does not affect the game besides being a visual glitch that goes away if I reload the map.

My config settings are mostly standard, I have 2048 edicts but the rest is default. (well as far as I know!) I don't use extra heapsize, zones or any extra command line parameters besides -game and +map. The BSP I am using breaks a couple of standard limits and produces warning, marksurfaces are above 32k and I am using 98 textures. 

it's probably heapsize then. You should use at least 128000 but i use 256000 in my quake batch file to just save myself the trouble.

I was getting odd corrupted textures until I upped heapsize. 

in the gl_texmgr.c where it reloads the entire file that a texture was found in.

In a lot of cases, a texture is in the map or model. And many times, the .mdl or .bsp in a .pak.

So in that case, it is going to load the entire .pak into memory. So, for instance, to reload a grunt's skin, it will load the entire pak0.pak into memory (17MB). For a Quoth Pyro, it will load the entire quoth/pak1.pak into memory (81 MB).

It will do this on any video mode change. I'm not sure if this how/why the described issue is happening, but this mean you need a substantial -heapsize allocation (probably at least 128 MB).

One way to test if this is the likely origin of the problem would be if Quakespasm/RMQ engine/Fitz Mark V don't have the issue [Quakespasm fixed it, fix was inherited to the other 2]. If you don't have the issue, this could have something to do with the problem. 

hmm, strange that it's loading source files onto the heap when normally textures are loaded with a file pointer. I guess I'm using the wrong method to re-open files in that case. I was not aware of this bug; do you know which quakespasm version introduced the fix? 

is it this?

Changes in 0.85.7
...
Reduced memory usage during reloading of textures 

and the Quakespasm changelog I think this falls under "video bug fixes" so maybe 0.85.5?

The fix is simple and mostly goes like this ...

FILE *f = NULL;
int datasize;
COM_FOpenFile (glt->source_file, &f);

if (!f) goto invalid;

datasize = glt->source_width * glt->source_height;
if (glt->source_format == SRC_RGBA)
datasize *= 4;

data = Hunk_Alloc (datasize);

// need SEEK_CUR for PAKs and WADs
fseek (f, glt->source_offset, SEEK_CUR);
fread (data, datasize, 1, f)

Where the above instead of loading the whole file, does an fseek to the right source_offset and loads <width x height x appropriate bpp> bytes.

You know ... looking at the above code, I'm not convinced offhand that is going to work right for a .tga or .pcx in a pak file.

[Then again, maybe it does for reasons that aren't immediately obvious to me ...] 

I'm thinking the fix isn't 100%

PCX data is generally (always?) compressed and TGA data can be RLE compressed or might be 8-bit expanded and then expanded to 32 bit.

Then again, I might not be seeing in the code where that is addressed.

[+1 to list of things to check out ...]