Are you able to compile standard Quake progs.dat 1.06 ok? http://www.quake-1.com/files/sourcecodes/kits/progs106.zip 

standard progs, but with some of SOA & DOE content, 1 monster of SOE also 

Does standard Quake progs 1.06 compile?

YES | NO

You are trying to figure out if problem is your code or compiler right? That is how to find out. 

thanks, this works fine, so the problem was my old code... 

See, haha. 

to put new monsters from doe & soa to my progs.scr, what more goes with the respective qc of monsters? 

This page loads slow as hell --- but it will eventually load ---

https://web.archive.org/web/20120213005405/http://www.inside3d.com/tutorials.php

It has monster tutorials at the bottom.

This page has monster mods
http://www.gamers.org/pub/idgames2/quakec/monsters/

You might look at spider21
http://www.gamers.org/pub/idgames2/quakec/monsters/spider21.zip

But ironically, I don't actually know QuakeC but rather just know where those resources are -- so I'll step out. ;-)

/Baker distracts Boa with "Hey look, a nickel!" and sneaks out the back door. 

thanks for helping but I don't understand jokes in english, I'm chilean

and fine... 

Is there an exhaustive list of functions that are available via quakec for vanilla quake? 

1) Maybe see post 2197
2) Maybe read defs.qc in the progs source
3) Maybe see bottom of pr_cmds.c in the engine 

try vanilla's defs.qc...
and bear in mind that a few of the args are wrong (eg: droptofloor does NOT take any args, and certainly not those of walkmove. yay copypasta bugs.). 

cheers guys 

Func, trigger, monster,info, you know the basics. My mod is getting...out of hand as far as multiple naming conventions go. I'm considering unifying the names of borrowed entities under Source engine's naming convention but still allowing the old entity names to keep from having to redo all my maps in progress...should I bother to nitpick this?

I'm thinking of using prop_ instead of misc_ or mapobject_; env_ instead of fx_ or misc_; logic_ instead of info_ or trigger_ (point entities where applicable of course); as examples.

Sort of thinking out loud here. I'm even tempted to go so far as to use npc...no no I'll leave them as monster_. 

Anyone have a good simple diff utility for telling if files are the same or not when merging folders and keeping the different ones but renamed? 

WinMerge does a great job. ExamDiff is supposedly the King. WinMerge is free and awesome. ExamDiff might be available as a free trial if they still do that. 

Every frame I need to check if a fairly small (5-15) set of entities is within a certain radius of the player.

Naive approach is to use findradius each frame and act on the results.

My current approach is to have a linked list that the entities in question add themselves to on spawn, iterate through that each frame and check for distance.

Am I prematurely optimizing with my approach or am I right in thinking that findradius will be slower? Haven't looked at engine code to see if findradius optimizes anything, but I'm just assuming it loops through all entities and checks for distance? 

I guess that findradius was written because the QC is significantly slower than checking all the entities by hand. On the other hand, I can't imagine that checking just one entity in QC is slower than calling the function, so there's a question of exactly when one becomes faster than the other.

If you're using the trick from
https://tomeofpreach.wordpress.com/2012/12/26/not-using-vlen/
then I'd guess the QC method is faster over 15 entities, but it'd be pretty close, so there's an argument to just using the simplest method and calling it a day. 

if you're using fteqccgui, the 'annotate sourcecode' feature can be quite nice for showing you the actual instructions generated from each line of code.
combine that with what preach said, and then optimise it a bit more.

unlike engine code, qc code needs to write back each temporary to memory, it has to read each instruction, it has to do some jumps per instruction, it likely has extra bounds checks, etc.
the engine can just use hardcoded offsets etc, reads much less memory, has better cache performance, etc. on the other hand it does need to walk through every single entity...
so yes, its a tradeoff.

of course, if you're only doing it about 4 times per frame, then who gives a damn, just use the code that is the most maintainable. 

on the other hand it does need to walk through every single entity...

How are entities spatially partitioned in the bsp tree? Is there not a broad phase test? 

findradius does not walk the bsp tree.
dp does use its areagrid for it which can be a speedup, but this does change behaviour, hence why its only dp that does that. 

Can new FTEQCC with "extend an existing progs" be used to fix Marcher Fortress coop?

In coop for Marcher Fortress, unlike any other Quake SP release, if you grab silver/gold key they vanish because key_touch function sets model to none whether or not coop is set.

In theory, using the "fte mod an existing progs" you could add a new key_touch function to the old progs, but would need to override the old one. 

I introduced a retarded bug in marcher that buggers up coop in more than a few ways IIRC

I meant to release a patch, but it's 2016 now and I have other things eating up my time.... :{ 

you *can* wrap the existing function, reverting the model back or whatever after the original touch function (or just replace it entirely), assuming you know the name of the function in question.
but its best to just harass Kinn for the source and fix it properly, or better yet harass him to provide a fix too, and then resort to function hijacks only if he's unable to do so.

extending existing progs is more useful in a general sense (like adding misc_model or trying to fix prevweapon stuff), or for mods whose source is completely unavailable.
you can use it for some really complex stuff, but the resulting code would likely be too hideous to work on long term. 

Pros and cons?

Because obvious repeating textures annoy the hell out of me, I've been thinking about how one might automate random textures on a face.

Here is the best implementation I can think of:

Modify qbsp to divide faces along a specified textures edges. Brushes containing that texture have their textures replaced with with another that has the same prefix and different number.

i.e. original texture is $0brick_wall, is replaced by $4brick_wall, etc.

It is an idea I'm playing with, and hell, I'll probably never implement it, regardless, what are your thoughts?