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 ...] 

Yes, the fix was done in v0.85.7:
http://quakespasm.svn.sourceforge.net/viewvc/quakespasm?view=revision&revision=633 

I'm pretty certain that code originated with me, but memory is hazy. The comment on the code you quoted is in my style anyway, and I'm in the habit of always initializing pointers to NULL, but I note that the current QS version is a little different (different comment, uninitialized FILE *f).

Anyway, TGAs and PCXs will fall through to the second condition as external texes use offset 0: "else if (glt->source_file[0] && !glt->source_offset)" - the "read the full PAK file into memory" problem should only happen with native textures inside BSPs or MDLs, where the offset is an offset into the BSP or MDL file, not into any PAK that may contain it (COM_FOpenFile will set up the file pointer correctly for the base file whether it's a loose file or a PAKed file, then we fseek from there).

There was a hack I did for DDS files where I added a SRC_DDS format and put the full file size into width, but with hindsight and in light of the above that wasn't even necessary.

Nowadays I'd probably be more inclined to glGetTexImage into an array of system memory buffers (malloc, not hunk) and delete each texture from GPU memory as it goes in. Then glTexImage from that array and free each buffer immediately after restart. Since textures are backed up by system memory copies anyway that wouldn't be any extra overhead that wasn't there to begin with. Would be much simpler and cleaner, and should also reload faster (no file I/O). 

Possible location of issue:

sv_main.c -> SV_ConnectClient ...

strcpy (client->name, "unconnected");
client->active = true;
client->spawned = false;
client->edict = ent;
client->message.data = client->msgbuf; <---- HERE
client->message.maxsize = sizeof(client->msgbuf);
client->message.allowoverflow = true;

Because ... server.h ...

byte msgbuf[MAX_MSGLEN];

And quakedef.h ...

#define MAX_MSGLEN 32000 // max length of a reliable message //johnfitz -- was 8000

And ...

sv_main.c SV_SendClientDatagram ...

qboolean SV_SendClientDatagram (client_t *client)
{
byte buf[MAX_DATAGRAM];
sizebuf_t msg;

msg.data = buf;
msg.maxsize = sizeof(buf); <--- Here

Because server.h

#define MAX_DATAGRAM 32000 // max length of unreliable message //johnfitz -- was 1024

Maybe ... not a sure thing but looks very likely right now. Not that anyone is going to be using GLQuake ...

I also kind of wonder if sv_protocol 15 demos will play back on GLQuake.

Knowledge pile +1 

Ok this is bloody wierd because I'm pretty sure it didn't happen before...

You know mods that replace start.bsp? (e.g. czg's czg07, or honey)

Well, I'm finding now that when running these mods it only ever loads the ID1 start.bsp

Anyone else had this problem? 

ignore the above I was being being a 'tard.