Thank you very much for your help. 

What about multiple instances of the same sound getting pre-cached? 

Also please would you be able to explain why the bug only happens when loading a save game? 

My experience with playing DarkPlaces is that it is a mod that is heavily transformed into its own behaviour. So although it uses the original ID1 code as source most related calls go to the DarkPlaces subdirectory, which has its own progs.dat.

So for searching your saved games and related errors with sound you have to search in the DarkPlaces directory.

I know this is not a solution for your problem, but I think you need to search for it there. And yes, DP has a rather kinky code structure. 

when loading a level the first time, spawn functions are run on each entity in the level, and a list of sound precaches is built up, where each sound is given a number. After that, any time a sound is played it simply uses the number to identify it.

When loading a save game, the level first loads the normal way, building a list of precaches by calling spawn functions. If this list doesn't match the original list, then the numbers that are used to identify sounds in the savegame won't me correct.

Normally this is not something people notice with sounds, but with models being wrong in a savegame.

Since you haven't really described when you see the problem, the savegame thing may be a red herring.

Calling "precache_sound" multiple times on the same sound is harmless. 

Thanks again for your time and knowledge. I should be able to fix the problem now. 

I'm using the Darkplaces engine, but not the Darkplaces mod. 

Do NOT save your game, switch progs.dat and load your old save. Things like this will happen.

Basically what meltslime wrote.

This is common behaviour and expected when working with different progs.dat´s and using the same savegame again and again.

You mentioned that you are working on a mod and add several new sound files. That is why. 

Nope that isn't the cause. Of course I'm not loading old save games post-progs.dat modification, that's coding 101 stuff. 

I've made a mod based on Copper and yesterday after adding runes to my new HUD I noticed that new rune pickups don't show up *at all* on the HUD.

The serverflags are being set, I can progress to Shub's lair no problem. It's just the runes never get displayed on the HUD.

So I thought maybe I made some kind of mistake with the new gfx.wad, but when I try it out in regular Copper the runes show up fine.

I thought all the UI stuff was handled by the engine itself, so I dunno how this is even happening.

I never touched the serverflags. The closest thing I can think of that might be the cause is I made use of an extra parm - parm11 - to store additional data about the player and extra weapons (all stored using bitflags).

Other than that, I don't know where to look and what to look for. Anyone got any ideas? 

Is there a reliable way to clear the color buffer so that models can be rendered outside the level area?

I know about gl_clear but that doesn't do the trick here.

Here's some context: I want to move the player outside the level area and render a player select 'menu' with a couple of models in his line of sight. When he's made his choice, the player gets plopped back onto the spawnpoint.

This works fine in Quakespasm Spiked. FTE QW and Kex Quake render nothing at all when I move the viewpoint outside the level however.

Any ideas to get this working across engines? 

Yes, precaching of sounds alongside a dynamic element of gameplay was the problem. Thanks again, very glad to see that fixed. 

Does anyone understand this (in id QC code)?

void() monster_xxx =
{
if (deathmatch) {remove(self);return;}
....

and on the other hand there is the bit "NOT IN DEATHMATCH" in the spawnflags of all entities,
processed by the engine at map start?

It seems as if Carmack doesn't trust map developers :) 

Seems like a time-saver. Why make mappers do the manual labor of tagging every monster with the correct flag? 

Also the "not in deathmatch" flag might have been added later, after this code was written. 

I tried to fix hurt_touch in triggers.qc according to the URQP. This is supposed to make every player in the entity getting hurt every second, not just the first one.
However, this code apparently makes Shub cause passive area damage on map END, which causes the Shambler (or player) standing next to it getting hurt.

Any idea what could be wrong here?

Original code:

void() hurt_on =
{
self.solid = SOLID_TRIGGER;
self.nextthink = -1;
};

void() hurt_touch =
{
if (other.takedamage)
{
self.solid = SOLID_NOT;
T_Damage (other, self, self, self.dmg);
self.think = hurt_on;
self.nextthink = time + 1;
}
return;
};

Changed code:

.float dmgtime;
.float attack_finished;

void() hurt_touch =
{
if (!other.takedamage)
return;
if ((time != self.dmgtime) && (time < self.attack_finished))
return;
T_Damage (other, self, self, self.dmg);
self.dmgtime = time;
self.attack_finished = time + 1;
}; 

no idea, the code looks reasonable.

you could put some debug prints in the code to help with this.

For example, eprint(this) in hurt_touch and see if sometimes it's Shub.
If yes, see if somehow shub's self.touch is being set to hurt_touch 

It might be port-related since QSS is acting kinda funky in its latest dev builds, but Shub is also screwed up in Ironwail and Mark V-WinQuake. I kinda based this on the way it's done in Lunaran's Copper mod, so I already suspected it couldn't be wrong. Unless my code simplifications f'ed something up...

I don't think I changed Shub code at all, but I'll take a look tomorrow. If it's not hurt_touch itself, it's something else.

If you wanna go ahead and check the entirety of the code, feel free to head over to the AMQ Github repository and get the QuakeC source. Maybe there's a connection I just can't see right now. 

When approaching Shub, I get console outputs with
Classname trigger_hurt
Touch hurt_touch()

Shub's code looks like this in monster_oldone:
[...]
self.takedamage = DAMAGE_YES;
self.th_pain = (void(entity,float)) nopain;
self.th_die = finale_1;
self.touch = monster_touch;
shub = self;

The self.touch part is another fix that is supposed to prevent sliding/not-jumping on top of monsters. Might that have something to do with it? 

I have a suspicion that END secretly relies on the bug you've just fixed. There's a 16 unit high trigger_hurt spanning the width of shub's platform, at about eye level. I'm guessing that prior to the fix, most of the time shub is absorbing the damage, which has no observable effect. You do occasionally get a 10 hp tic of damage when you jump on the island. 

Well, now you get the 10 HP tic all the time, it seems. Besides undoing the fix (which would be the least ideal solution), is there maybe some kind of exception that could be included to preserve the original behavior, at least on that specific map? I doubt it would matter elsewhere (even though you can never be sure). 

void() hurt_touch =
{
if (!other.takedamage)
return;
if ((time != self.dmgtime) && (time < self.attack_finished))
return;
if (world.model == "maps/end.bsp")
{
self.solid = SOLID_NOT;
T_Damage (other, self, self, self.dmg);
self.think = hurt_on;
self.nextthink = time + 1;
}
else
{
T_Damage (other, self, self, self.dmg);
self.dmgtime = time;
self.attack_finished = time + 1;
}
};

-----------------
Basically what I am doing here is to use the old code only on the "end" map. I don't know if this is efficient programming or whether it can be done in a more elegant way, but it's working. 

Hey. I don't know much about quake modding yet but I am already curious if it's possible to implement a doom-like use command/key to interact with buttons, doors etc. Maybe there might be an example of such functionality? 

There is evidence in the code that they once had a use button, for example, there is a +use command that is defined in the engine code, and there is a ".float button1; //use" in the quakec source. But, the network protocol never sends or reads that data so it's not usable.

However, you can easily define your own use button -- the impulse system lets a mod define a large number of arbitrary inputs that the user can bind to keys and the quakec code can read and use. So you'd just have to bind a key to e.g. "impulse 50", then in your quakec code you can do whatever you want with that. Look in weapons.qc at the function "ImpulseCommands" for examples.

(also note, that you can put impulse checks for self.impulse in any place in your quakec code as long as it's in a function where "self" is expected to be a player.)

One final caveat, there can only be one "impulse" per frame so the player won't be able to both "switch weapons" and "use the door" on the same frame, one of those inputs will be ignored.