Would freebie rune affect Cthton? You have to pick the rune up to trigger Cthton to attack.

[If he kills you and you still have rune, cannot complete E1M7.] 

Ah, I get it.

Save game doesn't know what you arrived on the level with.

How the heck do you keep carry-over weapons? Or do you? 

Most of the stuff you arrive on the level with is in spawn_parms. Sigils ain't, and that's the root of the bug. 

when the player is looking up when on a moving elevator, the screen sometimes 'stutters'/character seems to sink into the elevator

QS 0.90 

When the moving down & up certain ramps/convex geometry, the player gets stuck/stops and can't move forward 

make sure the host_maxfps cvar is set to 72, having it above 72 will cause both of those symptoms 

When dead players respawn, their corpse's colors revert to the default colors (yellow shirt/orange pants). This does not happen in any other Quake engine I can think of 

isn't that a bug with the original game? 

Yeah pretty sure that's a GLQuake thing. Not sure if any of the modern GL engines have addressed it. 

Don't have bug:
WinQuake
Quakeworld (any GLQuakeWorld, FTEQW, ezQuake, ...)
DarkPlaces
DirectQ + Remake Quake (pretty sure)
Mark V
Modern ProQuake (although I've seen a bug)

It is a pain to address because to do it right, you have to keep track of the color map for all entities (scoreboard) and then if a player color changes you have to recolor any skin or texture (it might not be player.mdl -- the player could have been gibbed. Some mods support more than 1 skin. Some mods support more than 1 model.). Then you have the problem that if the engine supports external 24-bit textures, then how do you even know what parts of the image are shirt or pants color (so DarkPlaces, for example, has _shirt and _pants support. ezQuake has something similar).

WinQuake doesn't care, it is a palette based renderer so when it paints color it can seamlessly substitute a slightly different palette -- it doesn't need to repaint a texture.

Stock Quakeworld including ezQuake just do it for the player skin. FTEQW from what I recall Spike saying, does it correctly for everything.

It isn't easy to address in code, you have to check changes in entities and changes in the player color too and rework the texture manager. It isn't fun. 

If a player does not change their color or model, could the corpse then still use the live player's already recolored texture in memory? Players changing models or colors is so rare that it would be a lot less jarring to revert when that happens than always upon respawning 

even when you do it 'properly' you still have weirdness when people disconnect or change teams (TF spies... grr, or worse: TF's animated+coloured teleport pads). 

could the corpse then still use the live player's already recolored texture in memory

You still have to keep track of what corpses go with what player. What if a player disconnects? What if a player grabs an invisibility ring? And if you ignore those, you still have to actively monitor any entity to be a corpse and change stuff in the texture manager. And there can be models with invalid skin numbers.

Doing it poorly isn't much easier than doing it right. Even doing it poorly is hard.

There aren't any easy answers for this one, but one of the older Mark V source codes has the changes marked in a straightforward manner. 

i've found that assigning a corpse's colormap to the player to work.

if ((gl_color_deadbodies.value) && (ent->model->modhint == MOD_PLAYER))
{
if (ent->colormap > 0)
{
texture = (playertextures) + ((ent->colormap - 1));//Colored Dead Bodies
fb_texture = fb_skins[(ent->colormap - 1)];
}
else
{
texture = (playertextures);
fb_texture = fb_skins[0];
}

Though, i'm getting black skins when someone is culled via cullentities...but the corpse suddenly 'color corrects' itself when the owner of the corpse comes into view.

And for 24bit skins i use ent->pantscolor ent->shirtcolor and run a pass twice over the model for shirt and pants; which DOESNT have any issues at all. 

edit:

in world.qc in the bodyque
we already have
bodyque_head.colormap = ent.colormap;

so we are already 'tracking' the color of the owner in quakec. 

here's how im assigning the shirt & pants in cl_parse

if ((i > 0 && i <= cl.maxclients) && (ent->model) && (ent->model->modhint == MOD_PLAYER))
{
ent->shirtcolor = (cl.scores[i - 1].colors & 0xf0) >> 4;
ent->pantscolor = (cl.scores[i - 1].colors & 15);
ent->colormap = i;
} 

I have linked an image comparison of three views of jam5_hypnos.bsp.

http://i.imgur.com/WIAAvmL.png

It shows how the fog looks in Darkplaces versus Quakespasm 0.90. You will see that if I look across the grimy water in QS the fog colors all of its surface light blue even near me. However, if I walk right to the edge and look down, the liquid texture appears in place of the fog color. In other words, the direction I am looking affects how the liquid surface looks, which is weird.

I'm not sure what is going on here. Could I be using some odd fog setting accidentally that makes it work this way? Does anyone else see this, or does it look more like the Darkplaces screenshot to you in Quakespasm too? 

The rendering effect I described above happens when I have r_oldwater set to 0. If I enter r_oldwater 1 in the console, the scene looks similar to the DP screenshot.

So if you try to reproduce, see if the two different r_oldwater settings have the same effect for you. 

Hmm, thanks for the report. At first glance I can't reproduce that, with QS 0.90.0 r_oldwater 0/1 look the same (except the slight difference in water quality). Here's r_oldwater 0:
https://www.dropbox.com/s/z4n1kibgu13qr2i/primal1.jpg?dl=0

I have a guess at what's happening from you screenshot - with "r_oldwater 0" the water texture gets drawn on the screen between frames and copied back to a texture, it looks like it's picking up the fog there.

Would you mind checking whether you get the same issue with fitzquake 085? http://www.celephais.net/fitzquake/

Also, what's your graphics card? 

I ran fitzquake with Wine and got the same result when I set r_oldwater to 0 in the console. Same thing with the water texture coming out when looking downwards too.

I have 64-bit Ubuntu on my laptop with an integrated gfx card. Here are some lines from my glxinfo.

OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile
OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.3.2
OpenGL core profile shading language version string: 3.30 

There are like 3 or 4 different fog implementations in engines and that sucks. 

Here is a little bit of video that shows how looking down changes the appearance of the slime.

I'd like to add that I can simply set r_oldwater to 1 and not worry about this glitch at all. So please don't spend too much time on this as long as it is just my system which has this problem.

http://i.imgur.com/7EhYPvi.gifv

(I should know by now how to record windows without including the header bit, but I forgot to do it right again while making this one. Derp.) 

I will have a look, I should be able to fire up ubuntu on a Haswell laptop. 

happens for me too, Ubuntu 14.10,
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile
OpenGL core profile version string: 3.0 Mesa 10.3.0

Will poke around a bit more 

The problem seems to be mesa is choosing to use vertex fog, which it is allowed to do in OpenGL. I tried adding glHint(GL_FOG_HINT, GL_NICEST) but still get vertex fog.

The other half of the problem is, there's a water textured func_illusionary stretching across the whole map; water doesn't get cut up by qbsp, so there are two giant triangles. Since the corners of the triangles are so far away they get fogged to solid white. You can see the issue if you do r_drawworld 0, r_oldwater 0, r_showtris 1, and noclip up above the map. "r_oldwater 1" avoids the issue because it chops up the water surface into smaller triangles that look ok with vertex fog.

So there's not much we can really do... I was thinking of upgrading the fitzquake "r_oldwater 0" effect to glsl at some point, and that would fix the problem since we can force per-pixel fog in the shader.