aka sv_gameplayfix_multiplethinks (exists as a cvar in both fte+dp)
vanilla quakeworld already performs multiple thinks per second if the real framerate drops too low somehow.
it'll just keep running think functions until it catches up with the actual time.
(yes, this means that really low think intervals is just wasteful). 

how does it behave if you set nextthink = 1? 

gives up because it didn't progress at all.
there's a lot of mods that use self.nextthink = time;
the time global will presumably stick one frame behind.
its probably also worth mentioning that quakeworld really doesn't do the whole fixed interval thing at all, favouring latency over smoothness (vanilla doesn't support interpolation at all).
it doesn't exactly do the order thing either, if you abuse newmis 

gives up because it didn't progress at all.

does it think exactly once though? otherwise, it is another compatibility break with winquake. :(
i use nextthink = 1 when I need one single think update on the very next frame. 

@necros
vanilla quakeworld: that's an infinite loop
fte: exactly what you want: exactly one think per physics frame if you set nextthink <= time like that.

@Preach
'If the drop to 10fps was only temporary then the entity may �catch up� once the framerate increases, but this will result in strange extra-fast behaviour in the meantime'
This is incorrect. time will be clamped to the start of the frame, even in vanilla nq.
This means that while an entity may run slowly in nq, it will NOT catch up / run fast once framerates increase.
(the nextthink = 1 example should give the time value that was correct at the start of the frame in every engine, due to this clamping - it will still be meaningful for the thinks of other entities although it'll happen about half a frame sooner than it otherwise would). 

I've updated the article, although now I'm a bit worried that I have the way frametime increases the wrong way round. From double-checking the source (what I should have done rather than writing the article from memory!) it looks like thinks are actually triggered when they're less than the true time plus the next frame length. This means the startframe function has the true time, but it's actually earlier than all the times thinks will occur this frame. The engine still lies about what time it is - but lies that it's the future rather than the past.

When it's morning and I'm less prone to making a mistake I'll put a second amendment in the article and fix all the tables 

depends how you define it.
startframe gets the time at the start of the frame. once the frame is done, time is updated to starttime + frametime. ie: the physics frame covers a block of time rather than a single absolute timestamp. Its still lying about being in the past (time should be starttime+frametime), but logically it somewhat IS in the past, as its trying to update those entities that still have thinks pending since the last frame. 

Yeah, the problem is that the article is taking the position that any function not told that time = starttime + frametime is being lied to (and if you're lied to, you can't successfully simulate multiple thinks). Under that definition, the startframe function is also lied to, since it is told time = starttime. However, it can always reason about which think functions should run this frame from this position, so I think it would be better to redefine what's lying etc... 

'but lies that it's the future rather than the past'
startframe is told its in the past, not the future.
think times are unordered, but always within the time period defined by the frame.

if you want to update the entities to the _current_ time then you should be using while(ent.nextthink<=time+frametime)
just make sure you don't do this on movetype_push entities. 

I'm trying to obtain a kind of a flamethrower for a model.

I'm a bad coder, everything just happens on the experience of addding to an excisting code.

To get the explod2.spr working I made a flame script that looks like this:


$frame 0 1 2 3 4 5 6 7 8 9 10 11

void() flam_stand1 =[ 0, flam_stand2 ] {};
void() flam_stand2 =[ 1, flam_stand3 ] {};
void() flam_stand3 =[ 2, flam_stand4 ] {};
void() flam_stand4 =[ 3, flam_stand5 ] {};
void() flam_stand5 =[ 4, flam_stand6 ] {};
void() flam_stand6 =[ 5, flam_stand7 ] {};
void() flam_stand7 =[ 6, flam_stand8 ] {};
void() flam_stand8 =[ 7, flam_stand9 ] {};
void() flam_stand9 =[ 8, flam_stand10 ] {};
void() flam_stand10 =[ 9, flam_stand11 ] {};
void() flam_stand11 =[ 10, flam_stand12 ] {};
void() flam_stand12 =[ 11, flam_stand13 ] {};
void() flam_stand13 =[ 12, flam_stand1 ] {};



void() model_flam =
{
precache_model ("progs/explod2.spr");
precache_sound ("ambience/waterfal.wav");
ambientsound (self.origin, "ambience/waterfal.wav", 0.5, ATTN_NORM);

self.solid = SOLID_BBOX;
self.movetype = MOVETYPE_NONE;

setmodel (self, "progs/explod2.spr");

setsize (self, '16 16 16', '24 24 24');
self.think = flam_stand1;
self.nextthink = time + 0.1;
};


void() FlameExplode =
{
// T_RadiusDamage (self, self.owner, 120, world);

// WriteByte (MSG_BROADCAST, SVC_TEMPENTITY);
// WriteByte (MSG_BROADCAST, TE_EXPLOSION);
// WriteCoord (MSG_BROADCAST, self.origin_x);
// WriteCoord (MSG_BROADCAST, self.origin_y);
// WriteCoord (MSG_BROADCAST, self.origin_z);

// BecomeFExplosion ();

T_RadiusDamage (self, self.owner, 40, world);
sound (self, CHAN_VOICE, "weapons/r_exp3.wav", 1, ATTN_NORM);

WriteByte (MSG_BROADCAST, SVC_TEMPENTITY);
WriteByte (MSG_BROADCAST, TE_EXPLOSION);
WriteCoord (MSG_BROADCAST, self.origin_x);
WriteCoord (MSG_BROADCAST, self.origin_y);
WriteCoord (MSG_BROADCAST, self.origin_z);

self.velocity = '0 0 0';
self.touch = SUB_Null;
setmodel (self, "progs/explod2.spr");
self.solid = SOLID_NOT;
s_explode1 ();

};

void() FlameTouch =
{
if (other == self.owner)
return; // don't explode on owner
if (other.takedamage == DAMAGE_AIM)
{
FlameExplode();
return;
}

sound (self, CHAN_WEAPON, "weapons/bounce.wav", 1, ATTN_NORM); // bounce sound

if (self.velocity == '0 0 0')
self.avelocity = '0 0 0';
};

/*
================
W_FireFlame
================
*/
void() W_FireFlame =
{
local entity missile;

self.currentammo = self.ammo_rockets = self.ammo_rockets - 1;

sound (self, CHAN_WEAPON, "weapons/grenade.wav", 1, ATTN_NORM);

self.punchangle_x = -2;

missile = spawn ();
missile.owner = self;
missile.movetype = MOVETYPE_BOUNCE;
missile.solid = SOLID_BBOX;
missile.classname = "flame";

// set missile speed

makevectors (self.v_angle);

if (self.v_angle_x)
missile.velocity = v_forward*600 + v_up * 200 + crandom()*v_right*10 + crandom()*v_up*10;


else
{
missile.velocity = aim(self, 10000);
missile.velocity = missile.velocity * 600;
missile.velocity_z = 200;
}

missile.avelocity = '300 300 300';

missile.angles = vectoangles(missile.velocity);

missile.touch = FlameTouch;

// set missile duration
missile.nextthink = time + 2.5;
missile.think = FlameExplode;

setmodel (missile, "progs/explod2.spr");
setsize (missile, '0 0 0', '0 0 0');
setorigin (missile, self.origin);
};


I compared the sprite with the grenade code of the ogre.
If I can stop it tumbling and make a straight foreward replacement of the sprite
it could give an idea of a flame thrower.

The result of this is, that the sprite only gives one frame, and all projectiles head east.

What should I do to prevent this? 

You aren't running the model_flam function anywhere, which partly explains why you aren't getting an animation. 

the model_flam. 

I'm just shooting in the dark.

I tried another way in the entity.qc by making a missile_explode, _touch, _launch and make the entity shoot the sprite. I only see one sprite frame, while there are 12.

Trying to add the flameframes of the sprite I can't use the entity.qc because it has it own frames.
The weapon.qc has already the grenade sprite so there it won't fit either.

So the script was a site file to make the entity launch the sprite as an attack scene of a kind of flamethrower.
Where do I make this call to the flame.mdl.

Probably it needs another statement to get the result. 

What I did was the first part at the end of model_flam make a flame.qc
and try to use the rest as the attack scene for the entity. 

Steal the one from the Rubicon2 source? 

reminds me of all the maps I haven't played yet. 

How do I do this? Do I have to edit something in the triggers.qc or suchplace? Any guidance would be most highly appreciated. 

that is limited by the engine, unfortunately. :(

be more succint, or use trigger_multiple that hits 2 trigger_relays, one with no delay, another with a delay of 2 seconds.

some custom engines can display more text, I think? 

The Inside3D website has been hacked for a while (and somehow nobody on the forum mentionned this) and that really bums me out because its tutorial page had a lot of useful stuff that helped me started some coding.
Is there a way to get them back, or at least some of them? 

Archive.org 

... where's that sticky post pointing the very basics to qc newbies?

I was thinking about another "total conversion": new monsters, new weapons, new player. How much the engine code is coupled to Quake stock assets? If I replace the Shambler model for a Santa Claus that shoots cotton candy, will I break something? 

I think the right question is: in order to do a total conversion, what can I actually replace without touching engine code? 

 

Quake actually has a really good segregation of duties between the engine and the QC code - I've heard how much harder it is to decouple gameplay and visual modifications in DooM. A good example to have in mind is the total conversion Malice, which replaced every graphical and audio asset in Quake, with completely different enemy behaviour and gameplay. All of this was accomplished without any modification of the engine (it predates the source being published).

There are some places where changes are more difficult/impossible to make, like the HUD or the fundamental physics or the rendering of surfaces. But if you want a monster with all new animations, behaviours and attacks, that's easily in reach of QC.

It's a shame Inside3d has been hacked, as that used to be a good place to start. However, the best resource for a new coder who wants to modify monsters is AI Cafe, and although the original site is long gone there's a mirror at:

http://www.quakewiki.net/archives/aicafe/tutorial/main.htm

Although I love promoting my own site, unfortunately it's pitched at the vanishingly small "experienced QC" crowd, so go do the AI Cafe tutorials first. 

Funny you should mention that today... with AtomicGamer going down, Inside3d is in the process of relocating to insideqc.com FrikaC registered it today and already migrated the forums. Hopefully less... hacked at, this time.