no, it is not recursion.
recursion is when a function calls itself.
you can accomplish this in qc with the usual method:

void() proc1
{
//stuff
proc1();
}
this also does everything on the same frame, just like for and while loops.

when you use thinks, it is the engine that is calling the function when nextthink ticks by.

for the explosion, if you're feeling adventurous, you could try throwing a bunch of MOVETYPE_TOSS invisible entities out of the explosion point that spawn explosion sprites themselves. ;)
looking forward to seeing it. 

To add, there is no queue with think functions, you only get one. So if you have code like

self.nextthink = time + 0.5;
self.think = CleanTheDishes;

self.nextthink = time + 2;
self.think = CookDinner;

the second think function overwrites the first one and so you end up eating off dirty plates. One way to fix that is to move the code which sets up CookDinner into the CleanTheDishes function, chaining the functions one after another.

This worked because our two functions were dependent. If you need your entity to think about two independent things one solution is
to have a master think function. This should think regularly, and check timers on your entity manually. The way that playerprethink and playerpostthink handle powerups running out is an example of this pattern.

If that's too complicated, the other way is to have two separate entities, as each one has its own think function and nextthink timer. 

Nice analogy; because we don't want to be eating off dirty plates now, do we?

It is falling into place, so thanks. 

I have been compiling my own progs.dat file using the tools from the ID FTP. Is there a good base of .QC files? Has the community got an agreed on base? Any recommendations? Something to start from? 

http://www.inside3d.com/gettingstarted.php 

Ok, this is fairly what-the-christ.

So, I'm running around my mod opening doors with keys. Use a key, door opens - it just plays the door open sound. I'm thinking hang on...didn't it used to play a "use key" sound before when it opened?

I then check vanilla quake. But no, even playing vanilla quake - no mods - key doors are only making the door open sound when they open.

I look in the QC - vanilla QC - the door is *trying* to make a "use key" sound, but it's immediately getting overridden by the "door open" sound (same channel). Looks like that's how it behaves all the time. So, another id bug to fix then. But why do I have a very clear memory of hearing the use key sound in vanilla Quake??

And more creepily, why did Scampie hear it on some compiles of his map, but not on others??

What is this door devilry?? 

sock: and definitely use a new compiler.
you can use more c conventions like for loops and increment and decrement operations.
also removes arguably useless stuff like needing semicolons after function braces.

kinn: not sure, but maybe because czg's progs from his last map pack had a fixed variation where the key sound plays and the door opens after a short delay? 

ok, so i've fixed the key use sound thing, and also for visual effect added a small delay between the key being used and the door actually opening. This introduced me to something that I never knew anything about before. Namely this:

in door_touch, if I replace the call to door_use(), with:


self.nextthink = time + 1;
self.think = door_use;


The door actually opens after about 10 seconds, not 1 second. (whu?)

if I write:


self.nextthink = self.ltime + 1;
self.think = door_use;


The door opens after 1 second, as expected.

do doors play by totally different rules when it comes to time and nextthink shizzle? 

wrote that before seeing necros' post :}, didn't know czg did this but maybe that's where i'm remembering it from... 

preach made a fantastic post about this explaining how nextthinks work on MOVETYPE_PUSH entities:
http://celephais.net/board/view_thread.php?id=60097&start=330&end=330 

also of note, setting .velocity on a MOVETYPE_PUSH entity without setting a .nextthink will do nothing.

.nextthink must be set higher than .ltime in order for the engine to update position based on .velocity 

@rj, thanks, I am still learning where everything is hiding! :P
@necros, I got the qcc compiler from ID and it would not work under 64win so I got hold of FTEQCC instead. The original ID files produced a ton of warnings and crap messages. I don't suppose any of that has been cleaned up and a new qc pack of files is anywhere? Or should I not worry and just add my own stuff to the pile?

Are there any QC libraries? Luckily czg released his source so I can see how he did the trigger spawn routines. Is there other things that everyone uses? 

thanks, that was useful. Preach - never stop quakeing, you are an asset.

So, from what I gather, because time was not advancing from the door's point of view, when I set self.nextthink = time + 1; it still had a self.ltime of like 0.1 or something, so the "ten second" delay i mentioned earlier was basically due to however long the game had been running up until that point + 1 second. lol.

Funny that I'm still learning new things about quake, but then again I've never dicked around with push ents before, which is why i've never come across this :} 

Sock: http://www.btinternet.com/~chapterhonour/clean%20source.zip ought to be handy.

It's my cleaned out copy of the qc source, only for the purpose of defeating all those warnings. I might have made some other minor tweaks but I'm pretty sure it's faithful to the basic game. The only real compromise I added to it is a pointless, vestigial function at the bottom of DummyFunction which defeats the warnings about .wad and .light_lev not being used in the progs, even though you must define the fields. 

@Preach, that is awesome what you have done, but I can't get the link to work? 

Forgot to test the link, turned out the ftp failed because the server dislikes filenames containing spaces. Renamed to
http://www.btinternet.com/~chapterhonour/cleansource.zip 

Thanks Preach that has saved me a ton of effort trying to work out what is my mistake and what is broken already. 

if i have two entities, one with .nextthink = time + 0.01 and another with .nextthink = time + 0.02 will the order the thinks occur be based on nextthink or just the order the entities are stored in the list in the engine?

my gut tells me it's the latter, and that makes me sad. :( 

didn't say, but it should be obvious, i'm assuming the next frame will be longer than 0.02 seconds after. say 0.1 seconds after to be clear.

time = 0
->a.nextthink = time + 0.01;
->b.nextthink = time + 0.02;
time = 0.1
a fires first, guaranteed? or it might be a or b based on it's position in the list.

i should think before i post. -_- 

If the frame takes longer than 0.02 then it is strictly in the order that the entities appear in the entity list.

Interesting fact though, say that instead we start at time 17
a.nextthink = 17.01
b.nextthink = 17.02

Now at 10fps the next frame starts runs at server time 17.1. However, during the think function for "a" time will be set to 17.01, and during the think function for "b" time will be set to 17.02. This change literally applies only to the QC variable, not to anything else in the server.

Back to the original problem, a lot of the time with the think intervals that you have chosen players today will see a think before b because the cap on fps is 72, which is high enough for a frame between 0.01 and 0.02. Beware of the effect in the previous paragraph though, if you are setting the nextthink values from within individual think functions for "a" and "b" it may not be the case that
a) b.nextthink - a.nextthink = 0.01 (even accounting for floating point error!)
OR
b) that b.nextthink won't occur in the next frame!

That second one needs a bit more explanation and in particular would benefit from concrete figures. We will say that the server issues a frame every 0.014 seconds.

Frame i:
server time = 17
b.nextthink = 17.003
Frame ii:
server time = 17.014
b's think at 17.003 executes and contains the qc:
b.nextthink = time + 0.02;

Since the engine sets time = 17.003 during the think, we now have
b.nextthink = 17.023
Frame iii:
server time = 17.028
So b executes a think in consecutive frames!

If you really need execution in order you might have to concoct a "priority queue" style system, with a new fakenextthink field. That would mean a linked list of entities so that the following pattern holds:

self.fakenextthink <= self.nextent.fakenextthink

You insert into the queue by traversing the list until your fakenextthink is <= the next fakenextthink. Finally you'd need a function that runs from startframe and traverses the queue, running fakethink on all the entities which are due. Since the queue is in order of fakenextthink, they run in the desired order and as soon as you reach one which is not yet due to run, you know you can stop traversing.

Two tips: firstly don't forget to purge the entities from the queue before you fire their events! It's very likely that entities will want to reinsert themselves into the queue from their own fakethink calls, so you need to be aware of that. Secondly, I'd keep up the practice of setting time = fakethinktime for the duration of the fakethink call (then you MUST reset it to evaluate the next entity on the queue).

These two tips combine for an interesting effect: you can have multiple fakethinks occur in a single frame, since they get reinserted into the queue with a fakenextthink that might still be lower than the server time. I suppose to be sure of correctness we need to make sure the loop of execution is less traversing the linked list, so much as always looking at the head of the list and popping it if execution time has arrived.

I have another use for this priority queue in mind which is less technically involved and more generally applicable, so I might go away and write it up with some nice complete code over the weekend...until then! 

thanks for confirming that for me. i was looking at the engine source, and that was what it looked like, but i'm not familiar with it enough to be sure.

i do remember the bit about time being set to nextthink time on think calls. i've used your 'servertime' workaround often because of it. :)

as for making a fakethink sorted list, i thought of it, but i only have one bit of code where it would be important, and it felt like it was better to just solve the problem by working around it rather than making the whole fakethink system.

thanks! 

Is it possible for one entity to affect (stop) the sound of another entity e.g by forcing a null.wav to play on that other entity's channel?

I have just noticed on an old map of mine that when the player dies the music keeps playing, which seems wrong to me. I thought I might just be able to drop a 'sound' line into Player DeathSound to say kill the music, then carry on and play whichever death sound you want. But I do not know how to use the sound(self,...) parameter to point to a specific entity.

Alternatively, could I stop all sounds just before playing the Player DeathSound? 

instead of "self" in that sound call, use the name of another entity. 

(i.e. the entity that you want to silence) 

also of note: make sure you play that sound with 0 attenuation to make sure it is 'heard'.
if you are outside audible range, the engine won't even bother registering the sound and so won't interrupt a previous one playing on that channel.