The linked tutorial commits a sin, a subtle but important piece of bad design. If you run the mod, load a map and find a mage, make a save game. If you keep reloading the game, at random all the models will go wrong when you load a save game. Why?

Well, it's because of the randomisation, which will occur differently each time you run the map. The save file does not actually stored the list of precached models, and instead regenerates it by loading the map from scratch, before loading the saved data. Whether the first monster on the map is a mage or a vore will change the order of precaches, and if the decision goes different ways between the initial load and the re-load, you get mismatched models!

There are a few ways you could fix this. You could precache all the models for the vore and the mage before rolling the dice to see which one you get. You could make the method of switching pseudo-random rather than random so that the same order occurs each time you load the map. The important lesson is that when it comes to the map initialisation sequence, you can't allow anything random to affect a precache. 

I forgot to mention I based my coding by making a copy of enforcer.qc and did the modifications fromp here. I actually did that "monster_nailinf" stuff before, and tried to remove the 2s the precache code had from the enforcer code, but still to no avail.

Running darkplaces with "developer 1" in, and it says this:
http://image.noelshack.com/fichiers/2015/46/1447599239-infantry20151115155014-00.jpg
I'd also like to note the guy's supposed to be following pathcorners in front of me, if that information can help. 

Is it included in the progs.src file? 

http://pastebin.com/3uad8AEA 

Thank you, that was exactly what I was looking for! Now the monster spawns with no problem.

Now the only thing that needs fixing is the idle sound and death sound not playing, as well as the rate of fire and him stopping shooting when the target's dead. 

Idle will only play when walking, not standing. And you precached death but play death1. 

in the line that checks if the target is on sight, how should I write "or if the target's health equals or is inferior to 0"? 

 

if(self.enemy.health > 0)

It translates into code quite directly. Also you want use AND here, not OR, because you only want to continue firing if your enemy is visible and is alive, so in total you need:

if(visible(self.enemy) && self.enemy.health > 0) 

 

So the next step in my mod is to add my lines of code into the latest quoth release by decompiling it. I could stop here and just have the Infantry Gun, Gatling Gun and Nail Infantry, but for what I want to do I'd love to use quoth's expansion as well as my stuff on top of it, stuff like more base monsters (or hell, more monsters in general), rotating doors, teleporting enemies... all of that good stuff.

So I've been doing a bit of research. I tried this: http://quakeone.com/files/10-miscellaneous/95-mrelusives-quakec-compiler-1999/ but it says the directories don't exist despite what seems to be a clean command line ("path to progs.dat" -d). Then I red this: http://www.quakewiki.net/archives/botshop/code/plus.txt and downloaded said software. When executing it, Windows says the program is not compatible with my current version of W8.1.
Going back to the first software, I grabbed its progs.dat on the software's directories, but it says after analyzing progs.dat "DEC_CalcProfiles - No parameter names with offset 377".
Anybody can help me there? 

 

"DEC_CalcProfiles - No parameter names with offset 377".

that basically means that the qcc stripped out the names (and very probably types too) of locals.
this means that if you can find a decompiler that makes stuff up, you'll still end up with what is basically gibberish.
You do NOT want to have to maintain that.

I have a private fork of frikdec which will try to decompile anything. nothing is fatal, it just writes out a best-effort instead. which is gibberish.
I don't give it out for a few reasons:
1) I don't want the flak from modders pissed at me for opening up their closed mods.
2) I don't want to have to maintain it.
3) I REALLY REALLY REALLY DO NOT want to have to help other people get it to compile.
4) any encouragement to get people to work on decompiled code is a baaaad idea.
5) unmodified frikdec is good enough for most purposes. mods that it can decompile generally have enough usable hints to not result in gibberish.
6) this way madness lays.

years ago, I did toy with the idea of 'appending' to a progs.dat file. load an existing progs, compile some new code, write out a new one with the extra code added (with some functions wrapped or whatever).
I didn't get very far with it though.

by the way, decompiled code sucks. 

If the mod is closed source, your best bet is to approach the authors and ask nicely.

Decompiling isn't really the way forward. 

Anyone know where I can find a good QC written function for this one that ID left out? I found one in another forum but its usinf a function called anglemod_view () which has a lot of while statements and seems prone to runaway loops. Mostly because it seems to have problems with a 360 degree roll. 

Sorry for the Malice progs.dat
Even when the ones that created feel sorry now for their encriptment. 

I sent Preach an email about that subject yesterday evening. I'm waiting for his response. 

What QC Compiler would you recommend nowadays? 

http://triptohell.info/moodles/fteqcc/ 

I think it's the only modern one..? 

New blog post, detailing how to create func_player_clip, and func_nonplayer_clip, which are solid only to players and non-players respectively.

https://tomeofpreach.wordpress.com/2015/11/18/selective-clipping

It's not technically monsterclip, because it is solid to other things as well. But as long as you use clipping brushes, the set of non-player things which will collide with them and the set of monsters are essentially identical.

Bonus material (cut from the post): There may be a small opportunity for a bug here with hitscan weapons, pain functions with walkmove on the first frame and very unfortunate positioning, but I don't think stock monsters can encounter it. Still, a cookie if you can figure out where it is and how to avoid it... 

two players enter a server.
the first player says 'I'm off'.
so the postthink says 'oh, in that case I'll make the other player into a monster'.

you probably want to use setorigin instead of setmodel. its more efficient for what you're trying to do. just leave the .modelindex set and clear out .model
in fte or dp, you don't need to do any relinking.

additional: will not work in fte, dp, or any quakeworld server. in these engines, player thinks are typically out of sync with monsters in order to facilitate prediction.
not when playing coop or deathmatch, anyway. 

two players enter a server.
the first player says 'I'm off'.
so the postthink says 'oh, in that case I'll make the other player into a monster'.

But the player entities are reserved in a block at the head of the entity list, so the slot is only freed up for another player.

My potential worry is that if you attack a monster with a shotgun, that might trigger a pain animation. Frame 1 of that pain animation plays instantly, and if the monster moves the physics occurs immediately. Since we're still within the call stack of the player functions, this gives the monster chance to walk inside an info_nonplayer_clip while it's non-solid, and land up stuck afterwards. It would be better if pain functions never called frame functions, but just set them as a think to happen immediately, but you can't make that change centrally so it's fiddly to do.

you probably want to use setorigin instead of setmodel. its more efficient for what you're trying to do. just leave the .modelindex set and clear out .model
in fte or dp, you don't need to do any relinking.

That's cool, noted. I don't know those corners of the engine well enough to know what you can get away with, and what's too much of a hack for some future engine to bear.

additional: will not work in fte, dp, or any quakeworld server. in these engines, player thinks are typically out of sync with monsters in order to facilitate prediction.
not when playing coop or deathmatch, anyway.

But do those engines let players execute thinks out of sync with each other? The idea is that the natural state of things is non-solid func_player_clip, and solid func_nonplayer_clip. Any time the engine runs physics on the players, we invert the natural order, then swap it back before physics runs on anything else. This is safe so long as all the players get acted on in a block, separate from all the other entities, even if the frequencies differ.

If the engine might ever run the physics on one player but not the others straight after, then the optimisation needs to go, and we must toggle the solidness after every individual player. Piles yet more inefficiency on in coop, but its the price of correctness. 

nextent skips entities that are free, correct...
But player entities are never free even if there's not a player in them. nextent thus finds player entities even if there are no players.
this means that flags&FL_CLIENT is unreliable, if not for the map the player leaves on then it definitely will be for the map that comes after.
pre/postthink won't happen for the first/last player slot if there is no player in it.

player entities are run out of order in quakeworld engines. the server runs player physics only when a network packet has been received from the client in question. this ensures that the entity state the server replies with is actually correct with regard to the state the server acknowledges.
this is done out of sequence because with 4 players it would otherwise require up to 288 physics frames per sec (assuming an infinitely fast server, less if the server's cpu is a bottleneck as multiple clients+packets may be serviced between waking periods).
removing the nextent optimisation would indeed also solve this case.

note also that touch events will fire between pre+post think (as well as during walkmove+movetogoal), and may get into an inconsistent state that way. whether this is actually a problem depends on the rest of the mod. 

Did not know that about empty player slots, but that's certainly a no-go then. I've amended the post to remove the optimisation, it's actually a much easier read now!

Re: touch being another issue, agreed, but like you say it's something that's only an issue based on the mod. Essentially it's movetogoal and walkmove that are the troublemakers - bits of code which set velocity etc. on an entity don't matter as the physics they set in motion isn't evaluated immediately.

A particularly brutal way of dealing with that threat would be a wrapper which simply causes walkmove/movetogoal calls to automatically fail if made during player physics! Both functions can already fail is the monster is blocked, so there's no guarantee of success for any call. It's mighty tempting, even if it's not all that pretty...