I reproduced it this way:
"map e1m7", grab the rune, then "changelevel e1m1". save. get killed. click to respawn, you will still have the rune.
Restart the engine. Load the save, you will still have the rune. Get killed, click to respawn: this time the rune is gone.

I think this is the same bug mh was talking about, pretty sure there's a fix on inside3d, so I'll have a look at integrating that. 

Almost certainly it's the same bug.

I've personally only observed it with the "kill" command (and have a hacky workaround for it there) but that doesn't mean that it doesn't occur elsewhere or have a different source. 

svn'd up, working fine here on my OpenBSD box, and gamma works, thx! 

Have you lads had a taste of HRTF? Aka binaural audio. In case you're unaware, it's a form of surround sound which can be played through any standard ear/headphones and soundcard. It's available in zdoom/gzdoom, where it's rather amazing to hear. There is a version available in the form of openal soft. Any chance of integrating that into quakespasm? 

I will have to try that in gzdoom. yquake2 also has an openal backend: https://github.com/yquake2/yquake2

Can't promise it will happen; the Quake sound code is a pain to work with so it might be a fairly substantial project. Also, I've found it's important to mix all the sfx at 11025Hz, otherwise you lose the "classic" sound (the Quake sfx clip a lot when mixed, but it sounds ok if the clipping is at 11025Hz). But it could be an optional backend of course. 

above was me.

re: the runes bug, I looked in to it, and the background is, there are two pieces of information about each rune: 1. does the player have it, 2. has the player beaten a level while holding it. #2 determines whether you get to keep the rune after dying. The problem is the savegame format doesn't keep both of those pieces of information, I think it only saves and restores #1. IMO it's best to just live with it as an "old gameplay bug". 

While you are still thinking about, can you describe in more detail the specifics?

The documentation of this problem is essentially non-existent and I know I'd like to "once and for all" at least know what is going on.

[And opens the opportunity for someone other than yourself to maybe even solve it.] 

I had a soundcard that did that way back. Gave me a huge advantage in multiplayer games because I could easily tell when sounds were behind me vs in front.

As far as I know, it was a hardware thing, don't know what software has to do to support it. 

The two variables are:
pr_global_struct->serverflags stores whether you are currently holding the runes.
svs.serverflags stores the "permanent" state of each rune: whether you completed a level holding the rune, so you would get to keep it after dying.

So when you grab the rune in e1m7, pr_global_struct->serverflags has a bit set to 1, while in svs.serverflags it's 0, so if you die in that level, you lose the rune and have to grab it again.

When you beat the level, Host_Changelevel_f calls SV_SaveSpawnparms, which copies the rune status into svs.serverflags making it permanent. If you die in another level, you spawn with the rune again. (In SV_SpawnServer, there is
pr_global_struct->serverflags = svs.serverflags which means you currently have the rune if you previously had it permanently.)

The issue is, saving only saves pr_global_struct->serverflags (via ED_WriteGlobals), and loading only restores pr_global_struct->serverflags. If you don't quit the engine, svs.serverflags will stay however it was, but if you quit it gets reset to 0. So the info on whether you had a rune "permanently" is not kept in the savegames.

mankrip on i3d also investigated it and I agree with his take on it:
http://forums.inside3d.com/viewtopic.php?f=3&t=4875&p=44571&hilit=runes#p44558

He points out that if you try to work around this using methods like "copy pr_global_struct->serverflags into svs.serverflags when loading a savegame", it creates this bug: grab the rune in e1m7, save/load, die in the lava -> you should lose the rune, but you don't. 

Runes are stored in the QC in the "serverflags" global, which corresponds to pr_global_struct->serverflags in the C code. That's the "does the player have it" part.

They're also stored in svs.serverflags which is the "has the player beaten a level while holding it" part.

svs.serverflags is 0 when the engine starts and is only ever set to any other value during a "changelevel" (see below).

When issuing a "map" command svs.serverflags is set to 0, then SV_SpawnServer runs.

When issuing a "changelevel" command SV_SaveSpawnparms runs which first copies pr_global_struct->serverflags to svs.serverflags, then SV_SpawnServer runs.

During SV_SpawnServer the progs are loaded which sets all QC globals to their defaults, then copies svs.serverflags to pr_global_struct->serverflags so that it's updated from whichever value was stored - either 0 ("map") or it's previous value ("changelevel").

The savegame format only stores pr_global_struct->serverflags, not svs.serverflags.

So the value of svs.serverflags needs to be valid in order for runes to be properly restored.

Steps to reproduce.

Grab a couple of runes (cheat if you like).
Save the game.
Exit Quake.
Restart Quake.
Load the game.
Die.

Runes are gone; it doesn't matter if you die by the "kill" command, by jumping in lava or by getting too close to a Shambler.

Cause

svs.serverflags has lost it's stored value during the exit Quake/restart Quake cycle, so when SV_SpawnServer runs after you die, it restores them to 0.

Fix

In Host_Loadgame_f, after restoring all of the values of "svs.clients->spawn_parms" and before calling CL_EstablishConnection, add a "svs.serverflags = pr_global_struct->serverflags;" line.

I think that should do it. 

Now that I've read ericw's post, yup, that's a problem... 

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