I use fteccgui as fteqccgui. I can compile the client.qc but I have no idea how to make it correspond the player's death. I think it needs some more code.

local entity spot; // entity to hold our axe ogre
if ( spot ) {find (world,classname,"player");
{
local entity leak;
spot.think = xogre_leak1;
}
}

I tried your email, but it faints. 

gimmy a hint! 

Set spot.goalentity to player perhaps. 

if(spot)
that does nothing. spot isn't initialised yet. if this was C you'd crash. As this is QC, it'll just always evaluate to false and do absolutely nothing.

find (world,classname,"player");
this does nothing. you're calling the function and finding a player, but as you're throwing away the result you're not getting anything out of it.
Of course, seeing as the player has just died, the return value is probably going to be equal to 'targ' anyway. You probably meant to look for a different classname, like your ogre's classname.

local entity leak;
Variable not referenced: leak
the weirdly named 'spot' variable is used, but leak totally unused...

spot.think = xogre_leak1;
You didn't check that 'spot' is actually alive.
Your dead ogre will suddenly resurrect purely to take a leak!
Lets hope its not a gibbed head. :D
Note that there's no loop, so only one entity could possibly start pissing (except that spot is always world so you're probably just going to crash the server with your assignment to world, if the if statement wasn't there).


Imho, you should shove the check somewhere in ai_run.
When a monster's enemy has died, that function decides whether the monster should resume attacking its oldenemy or whether it should resume walking/standing instead.
So when the enemy dies, delay the standing and switch to the pissy animation instead (make sure its an 'xogre' that's doing the ai_running first, and make sure it doesn't forget its enemy just yet).
That way you don't risk waking monsters from the other side of the map (which might get quite crowded, and really awkward in coop).
and then you can dupe the walking animations to have the monster walk to the player's corpse and then start to pee only when its close.
then once its done pissing, you can have it start to play some point+laugh loop, or just have a constant stream of pee until something else wakes it up by shooting it (or make the looping part call ai_stand to have it wake up if another player gets close). 

I've taken the plunge into cut and pasting QC. What's the "state of the art" clean id1 source code I should be using in 2018? 

The vanilla source code (version 1.06) can be found at least here:

http://icculus.org/twilight/darkplaces/files/id1qc.zip

C0burn had also linked Ultimate Regular Quake Patch's source code to me. It has a lot of fixes/workarounds for problems that may arise with the vanilla code. I borrowed some code from it for one of my maps.

http://www.quaketastic.com/files/misc/urqp106a.zip

Good luck to your plunge! :) 

Looks like a lot of MP focus in that second link. Thank you! 

For my own purposes I put some QuakeC onto github a while back. There's various places to get these same things, but:

For the original 1.06 QuakeC you can browse it here: https://github.com/neogeographica/quakec/tree/1.06

or download a zip of it from here: https://github.com/neogeographica/quakec/archive/1.06.zip

For Preach's cleaned-up 1.06 you can browse here: https://github.com/neogeographica/quakec/tree/1.06_Preach

or download here: https://github.com/neogeographica/quakec/archive/1.06_Preach.zip

And you can see the differences between them here: https://github.com/neogeographica/quakec/compare/1.06...1.06_Preach 

Eh, one caveat that just occurred to me about those zipfile downloads. If you get the code that way then all the files will use Unix-style line endings. Might cause you issues depending on what text editor you're using. 

The URQP package is neat. I didn't know that that was where the Quake Info Pool fixes ended up. 

I've updated the QuakeWiki with a list of bugs I know about in the 1.06 code.

https://quakewiki.org/wiki/Quake_bugs

It's most of the URQP stuff, plus other bits and bobs.

Please amend or ask me to amend if anything is missing! 

Quote from your list:

Rotfish does not become non-solid until the final frame of it's death animation * this is not in line with other monsters, so it is considered a bug

Correct me if I'm wrong, but don't fiends exhibit similar behaviour, too? 

They become non-solid on frame 6/9!

Glancing at some others quickly, hellknight is frame 3, as is the grunt.

I think it should be harmonised. 

Should we class unused content, such as the death knight grunt sound and unused animations and unused shub sounds, as a "bug"? There's other bits and pieces as well, including unused animations in the knight, soldier and ogre. Can we introduce these in a non gameplay changing manner? Should they be an optional spawnflag/worldspawn flag? 

In the ai.qc i took the ai_run part.

===
void(float dist) ai_run =
{
local vector delta;
local float axis;
local float direct, ang_rint, ang_floor, ang_ceil;
local entity spot; //xogre_leak code
movedist = dist;
// see if the enemy is dead
if (self.enemy.health <= 0)
{
self.enemy = world;
spot = find (world,classname,"monster_xogre");

if ( spot ) {find (world,classname,"monster_xogre");
{
spot.think = xogre_leak1;
spot.leakentity = self;
}
}


and the bastard lays it's blame on me!

Thanks Spike, that was right on target!
Now see if I can switch leak with laughing. 

Thunderbolt bugs relating to the "three beams"

I assume this bug isn't related to lightning attacks (both thunderbolt and shambler) being able to damage entities through walls? Also, hitchecks with the thunderbolt are kinda weird. (You probably know what I mean with that, but if you don't, just tell me, and I can explain in a reply.)

multiple megahealth rots down too quickly (double rot)

I had learned about this actually, when I tried to make a custom Doom-like health bonus item. My health would rot down super fast after having picked up like ten of those items! @~@ I actually thought that it was a feature, to make supercharged players less OP, or something. :D

targets not fired if the player doesn't take the item (e.g. already has max armour, touching armour should trigger a monster/something, but doesn't)

This is even more so arguable, whether it's a bug or not. I actually prefer it the current way. If I wanted to make 100 % sure about the targets being triggered when touching the item, I'd add a trigger_once brush or something.

(Also there are minor typos here and there in the list.) 

Thanks. I wasn;t aware Preach had a version of his own. I'll most likely use Preach's 106 code when I dive back in. I am using FTEQCCGUI and Notepad++ 

@dumptruck
Last year muk0r put together a "clean QC source"... but the readme doesn't say if there is any bugfixes :(
http://www.quaketastic.com/files/Clean_QuakeC_Source.zip

but maybe (i said maybe because i don't know if you want these features) you should start with custents?
http://www.quaketastic.com/files/tools/windows/quakec/custents.zip
It seems to be a mix of all the cool features of the two official mission-packs, like: rotating brushes, earthquakes, particle fields, breakable walls, etc 

Thanks for these links. I am looking at adding some of the custents features for sure. 

I think the "same name texture" crash mentioned on that page is only in GLQuake and derived engines. 

I agree about the item not triggering it's targets if it hasn't been picked up, that is definitely not a bug, it makes total sense for an item to not do anything if the player touches it but can't interact with it for whatever reason, like if their ammo is full or they have full armor or they already have that type of key in their inventory. Not to mention that a vast majority of maps are designed around this mechanic one way or another, like key traps triggering when the player, you know, picks up the key or encounters that get triggered when you pick up a particular weapon or powerup like quad damage

Now if we're talking about keeping the player from picking something up if they already have enough of it that's another story, it would definitely be nice sometimes if some things like ammo or health only gave themselves to you if you actually needed that much, it would definitely help prevent wastefulness by picking them up on accident when you don't really need that much yet 

I agree about the item not triggering it's targets if it hasn't been picked up, that is definitely not a bug, it makes total sense for an item to not do anything if the player touches it but can't interact with it for whatever reason, like if their ammo is full or they have full armor or they already have that type of key in their inventory. Not to mention that a vast majority of maps are designed around this mechanic one way or another, like key traps triggering when the player, you know, picks up the key or encounters that get triggered when you pick up a particular weapon or powerup like quad damage

Now if we're talking about keeping the player from picking something up if they already have enough of it that's another story, it would definitely be nice sometimes if some things like ammo or health only gave themselves to you if you actually needed that much, it would definitely help prevent wastefulness by picking them up on accident when you don't really need that much yet 

I should mention that the changes in the cleaned up code are only to eliminate compiler warnings, there aren't any bug fixes or behaviour changes. Just wanted to set the right expectations for it.