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? 

This could be interesting but IMHO only with slight variations of the same base texture, so as to avoid the grid effect. Any more than that and randomization will likely produce weird side effects. 

I think one way to avoid repeating textures using that kind of compiler feature wou, rather than multiple textures for it to choose from, it could use one perfectly seamless texture and rotate it in random 90 degree intervals. Subtle but as far as I am aware a pretty effective result. 

Yeah, but doesn't help with brick textures and such.

I had the realisation that this could also be implemented in editor. Which is probably the better option.

A third option (handy) but worst in my opinion, is decal support for quake maps. I think this is worst because it is engine specific, and the maps wouldn't be backward compatible. 

Would it be though? If the decals were baked on during compilation they wouldn't be. But you'd have to make some pretty big changes to the compiler so that it was able to combine the appropriate images. It would be a pretty powerful tool though.

Psst, someone suggest it to ericw 

the implementation required to make it work with vanilla would be really tricky, probably more complicated than its worth.

I think there is a maximum texture resolution, so if you were to decal over the edges of said texture, you can'd just make a huge mega-texture. In that case you would need to split the texture into separate parts to avoid that limitation.

Then it isn't just the one texture on the face anymore, so you need to split the geometry anyway. 

I think the way to go for brick is to do what czg's honey does, make a 256x256 (I think?) version of a 64x64 texture.

also: http://www.celephais.net/stuff/texturefaq.htm
There is no upper limit to height or width that I know of. The largest texture that shipped with the game is 320x192. 

well if it doesn't care about dimensions then I might make a little java app to randomise textures into a big texture then.