Quakec Clock

[toneddu2000]

Hi guys, I'm trying to deepen every day my knowledge in quakec and every step I make I understand I don't know so much!
One of the thing I couldn't find explained is the concept of time in quake.
It's useless asking you to help for the problem I have right now, so I'll try to create a more costructive issue:

How time beats in quakec? I mean, when the "clock counter" starts? When the map is loaded? And when player dies, time stops? Or it continues ticking even after new map is loaded? And, most of all, how to control it?
I tried to use the variable "time + value" a lot of time but with no success.

I created this to create an example situation.
Imagine a tipical situation where a main entity, at some time, spawns. This entity, after an X amount of time (time after its spawning), spawns other sub entities. These sub entities could spawn after other X time other sub sub entities or call the main entities in a X time or every Y time.

Is it doable in quakec a structure like this?
There are other threads discussing this argument?

thanks in advance you guys

[taniwha]

This is where you use .think and .nextthink (and, if you want, the state operator (void ()foo = [] {...}).

Most engines require you to set the move-type to something other than MOVETYPE_NONE for think to work (QF allows MOVETYPE_NONE, both nq and qw). NOCLIP might be a good one.

Another thing to watch out for is nextthink: normally one sets it to a time in the future, and the engine will call think after that time (accuracy depends on server frame rate). If you don't want think to be called for the time being (eg, until some other condition is met), set nextthink to 0 (or less). Now comes the fun: in QW, if nexthink is > 0 but <= sv.time (engine name), the think function will be called repeatedly in the same frame. This is useful if your think function is complicated an gets the dreaded "runaway loop" error (you don't want to do this sort of thing often, though). I've recently made it so both QF's QW and NQ do the looping only if nexthink == sv.time (I ran into a problem with the marksman ogres in honey because I'd made NQ work the same as QW).

BTW, watch out for .ltime: it's really weird and updated only for MOVETYPE_PUSH objects (and is a part of the problem I had with marksman ogres).

[Cobalt]

[Spike]

huh? movetype_none has thinks in every single quake engine.

float time; is the time since the map started. players from the previous map will join at about 0.3 secs in or something weird like that.
it isn't system time, because that would break everything. specifically, system time in a float would have too low precision. doubles do not make everything okay. just using long doubles instead is a stupid suggestion, so I'm glad noone suggested it.

.float ltime; has nothing to do with the remove() builtin, at least as origionally designed.
.ltime is only used by the engine for .movetype == MOVETYPE_PUSH, where it is used instead of time for checks against nextthink. it is also incremented ONLY when the pusher actually moves. this allows syncing thinks to specific distances traveled even if something stood in its path and stopped it from moving for 10 mins. like I say, the engine only does that with movetype_push, so with any other movetype its 'free' for reuse. Any such reuse is mod specific.

traditionally you have:
startframe()
foreachclient
{
if self.isaplayer then playerprethink()
if (self.movetype == movetype_push)
{
fractionmoved = trytomove(self.velocity * frametime);
self.ltime = fractionmoved*frametime;
if (self.nextthink && self.nextthink < self.ltime) then {self.nextthink = 0; self.think();}
}
else if (self.nextthink && self.nextthink < time) then {self.nextthink = 0; self.think();}
if self.isaplayer then playerpostthink()
}
ext_endframe();

as taniwha says, QW can think multiple times in a single frame. the time value will be set to self.nextthink before the call. this is to keep nextthinks etc ticking at 10fps if there's only network traffic driving physics at 5 fps. also player entities do not have their physics run as part of the generic physics frame, but rather only on response to network traffic.
fte (and I *think* dp too) uses the qw multiple-thinks-and-players-outside-the-frame behaviour by default, even for nq mods, just with an exit clause if the think function sets nextthink to time.
yes, this breaks certain mods (headhunters at least), but fixes physics to give prediction. in fte, you can set sv_nomsec (badly named, I know) to mimic nq physics more precisely. a value of 2 makes it an exact match (assuming there's no bugs!)

[taniwha]

[toneddu2000]

thanks you guys for all the replies but I'm still a little confused.
If I understood correctly:
1) there's no clock in quake linked to system's clock
2) only value for time used in quake is float time; and it starts to "count" since the map has started
3) float ltime is tied to MOVETYPE_PUSH (so I think it's used by crushing platforms and similar, I guess. Not so useful in game)
4) to make the time flows I need to set think and nextthink for every entity I need to sync with quake time
5) Quake works a 10 FPS (right?)

My remained doubts are:

Is it impossible to start a timer when the map starts and keep checking it to inject events at specific time (like a scripted game - the player walk in an area map and, after 2 min, a monsters horde spawns at his back or whatever)
float time is a builtin variable? Or it was created by id just in the quakec? I mean, using DP, it could be possible to recreate a clock system (with timers and stuff) just with blank quakec code?

PS: I didn't understand the "thinking and linking" matter said by taniwha. When an entity is meant to be "linked"?

[andrewj]

[Cobalt]

[toneddu2000]

@andrewj: that's exactly what I needed to know: if time was relative to entity which call it. Thanks a lot

@Cobalt: thanks for the hint, I'll try that

[Cobalt]

[frag.machine]

[Cobalt]

Thanks FM, worked nice!