News | Forum | People | FAQ | Links | Search | Register | Log in
Coding Help
This is a counterpart to the "Mapping Help" thread. If you need help with QuakeC coding, or questions about how to do some engine modification, this is the place for you! We've got a few coders here on the forum and hopefully someone knows the answer.
First | Previous | Next | Last
Not Really 
It's something that the engine does so in general you can't modify it away from the progs. If you had game saves which were being triggered from inside the progs (like an autosave feature or a hub system thing) you could mask it by appending ";echo \n\n\n\n" to the command string, but it's a bit hacky, you're wiping the whole notification area like that and making a bit of a mess of the console log.

If you wanted to adapt your favourite engine to not do it then it's a pretty easy change. Grab the source code for the engine, open host_cmd.c and comment out the following line:

Con_Printf ("Saving game to %s...\n", name);
 
 
Bind your save key to "con_notifylines 0; save quick.sav; con_notifylines 4" 
Not Worthy! *takes Hat Off And Bows At Preach* 
Like anyone can grab the source code for an engine, pop it into an IDE and hit compile and not get a gajillion errors.

fteqccgui.exe = easy QuakeC
<insert typical IDE here> = ERRORS!! The C++ Lord laughs at you and says "You're not supposed to be here!" 
@Spirit 
That only works in JoeQuake-like engines.

I don't think Quakespasm supports it nor FitzQuake. DarkPlaces uses "con_notify". 
 
@qmaster
that's more of a dependancy thingm combined with thesystem header files cahanging significantly with every single new ide version (especially between vendors).
qc just has NO dependancies - just compiler and vm. many qc mods still break to engine incompatabilities or compiler bugs. :P

@spirit
con_notifytime 0
set it back to 3 after 3 seconds have elapsed, or increase it over time.
there's a more portable solution for you. :) 
 
The con_notifytime 0 does appear for a split second. Probably 1 frame.

(Which is why the non-standard con_notifylines 0 is nice) 
Thinking Fast 
Somewhere on func_ recently there was discussion on 20fps animation in Quake, and one of the obstacles was that the QC might cope badly with them if the engine dropped below that framerate. Here in partial answer to that problem is a blog post:

https://tomeofpreach.wordpress.com/2015/03/28/thinking-fast/

It's also me trying to rewrite a much older post I made on func_ trying to describe exactly how the Quake engine deals with time and think functions. I hope the new approach taken makes it a bit easier to understand. 
QuakeWorld 
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). 
Thanks Spike 
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. 
Truth, Justice And All That 
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. 
Projectiles 
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? 
Madfox 
You aren't running the model_flam function anywhere, which partly explains why you aren't getting an animation. 
Can't Flim-flam 
the model_flam. 
Rascalling Again 
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. 
Spagetti 
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. 
Why Not 
Steal the one from the Rubicon2 source? 
Not Bad 
reminds me of all the maps I haven't played yet. 
Increasing The Character Count Of My Trigger_multiple Messages 
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? 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.