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. 

Thank you for the given information, I really appreciate your help! Though I still require any example (if one exists) where the use functionality is implemented as I can't figure it myself yet :( 

I've looked through the qc files and found there are even functions for the use thing in buttons and doors code, but I can't get it what exactly has to be done to call them... 

When you see SUB_UseTargets in quakec, that is a different meaning of "use" than you're thinking. That's how various entities can trigger each other (e.g. when I pick up a key, it teleports some enemies. When I press a button, it opens a door.) Not the same concept as what you're looking for.