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. 

Well, for the record I'd still like to see decals someday >_>

I'm imagining it would get pretty whacky though. You'd have to account for the palette for instance when blending the two textures, I get the feeling that with some colours you'd end up having to make some compromises. And compromise is never something you really want to automate... 

talk to mankrip re: colour blending with palettes, something tells me he's all over it. 

That stuff freaks me out. Some kind of voodoo magic I think.

If he could provide ideas as to how his implementation could be applied to low-res textures that are baked into a map, I'm all ears, but from what I've seen a lot of the quality seems to rely on the fact that he's working with a high enough resolution that the grain introduced by the super duper advanced and spooky dithering isn't too obnoxious.

And by "I'm all ears", I mean "I hope someone else is all ears because I know enough about coding to know that I can't code that" 

You'd have to account for the palette for instance when blending the two textures
Not if the decal is 24-bit, then it'll ignore the palette. One thing though: wouldn't decals exclude QS compat? 

Wouldn't be capable of using replacement textures, but I don't see why qbsp couldn't be extended to merge the decal with its underlying faces into a new texture. If qbsp then output these new textures with the names used such as <mapname>_dec1.pcx...<mapname>_decn.pcx then perhaps it could support replacement textures even if only manually. 

Any help in solving this issue?

https://github.com/muk0r/qompiler/issues/1

Im building a compiler. I want it to use profiles to load saved compiling setting. How can I load a batch file to assign values to the variables I've created in the first batch file?

The current version is in branch v0.75

https://github.com/muk0r/qompiler/tree/Qompiler-v0.75 

do any of you guys have access to the "team fortress" or "future vs fantasy" source codes? 

TF: http://upload.foppa.dk/files/tf_29src.zip
You should check out Custom TF too, cool stuff added there, like building your character. You could be a thief (invisibility). You could have a special knife and when you stabbed like 5 people you could summon a Shambler who was following and fighting for you! :D ...and other shit that people were adding over the years to their mods.