looks like they added a property which will remove the trigger after it was used a certain number of times. If the mapper added "cnt" "5" it would delete itself after 5 uses.

Since unspecified properties default to "0", they convert 0 to -1 in the spawn function. 

Guess that would make it rather useless in ID1 maps, for example. At first I thought it could be something like Maddes' URQP code fix for multiple clients getting hurt at once and only the first client receiving damage, but that would have to look differently code-wise. 

I am comparing Maddes' URQP code with Preach's cleaned-up QuakeC 1.06 source and see a difference in ai.qc, in function FindTarget().

It starts as follows in URQP:

float() FindTarget =
[...]
if (sight_entity_time >= time - 0.1 && !(self.spawnflags & 3) )
{
client = sight_entity;
if (client.enemy == self.enemy)
return FALSE; // This is what I wonder about
}
else
[...]

In Preach's version, it's return TRUE. Which one is correct? According to the file comments, this is supposed to return TRUE if an enemy has been sighted. (Also: What would happen if it's wrong?) 

Any way to access cvars which are not saved to config, e.g. r_slimealpha in QSS? Stuff like cvar("r_slimealpha") wouldn't work, apparently. 

Any reason why (am using darkplaces if that is relevant) sounds are sometimes mismatched? Picking up a health pack may make a megahealth sound, ogres may play a death sound in place of their pain sound...not good. 

More info: It doesn't happen all the time, and the mod I am modding features a lot of new sounds. Typically it seems the mismatched sound is taken from the same folder (e.g health pack plays megahealth sound), but very rarely it seems completely random. 

In the past, people have had this issue because there is something inconsistent about the order of precaches in their code. But, I think that would only show up as a problem when loading a savegame or playing a demo.

Darkplaces might(?) have a feature that auto-caches when you try to play a sound that was not precached. If that's true, perhaps this creates the inconsistent order (becuase it could depend on player actions.)

So, make sure you are precaching all sounds you use in worldspawn or one of the other spawn functions, and, make sure nothing in the spawn logic can randomize the order of the precaches. 

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