nice two-person reply, mh wins for better formatting.

The only good thing about the original bug is, if you save, quit, load, and manage to beat the level without dying, svs.serverflags will get updated and everything will be fine after that. 

Just done some more testing, and I think that the bug where you still have the rune is the lesser of the two.

It only affects maps which have runes so it doesn't falsely give you runes you shouldn't.

The rune can still be picked up.

And losing them when you die gets fixed.

So it's a toss-up between having a rune which you're going to get later in the map anyway (and which doesn't otherwise affect gameplay) versus losing all runes to date.

The only thing I can think of against it is maps which use runes as keys as well as for cross-level info, which doesn't affect ID1. 

I guess the 'ideal' solution is to reload the saved game instead of restarting.
might need to cache the save in case someone overwrites it though.
possibly more useful in other situations too.

as mh suggested, I'd just go with giving the player a freebe rune, it won't break anything or confer any advantage, it'll just look a little buggy on the hud. you need to grab the rune to open barriers infront of the exit on each map anyway.
if you want to hack some kind of (hud) fix, you could just scan for an item_sigil entity and clear out any serverflags that match the spawnflags. thanks to the qc clearing out the rune's classname, this should work even if you save after grabbing the rune.

or you can change the saved game format (possibly just add some //comment at the end of the file, ala dp). 

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