Not Really
#1618 posted by Preach on 2015/01/04 01:24:23
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);
#1619 posted by Spirit on 2015/01/04 10:13:44
Bind your save key to "con_notifylines 0; save quick.sav; con_notifylines 4"
Not Worthy! *takes Hat Off And Bows At Preach*
#1620 posted by Qmaster on 2015/03/10 05:07:52
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
#1621 posted by Baker on 2015/03/10 08:14:11
That only works in JoeQuake-like engines.
I don't think Quakespasm supports it nor FitzQuake. DarkPlaces uses "con_notify".
#1622 posted by Spike on 2015/03/10 09:33:36
@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. :)
#1623 posted by Baker on 2015/03/10 23:35:23
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
#1624 posted by Preach on 2015/03/29 00:38:36
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
#1625 posted by Spike on 2015/03/29 03:49:55
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).
#1626 posted by necros on 2015/03/29 04:48:27
how does it behave if you set nextthink = 1?
#1627 posted by Spike on 2015/03/29 06:55:17
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
#1628 posted by necros on 2015/03/29 15:28:30
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.
#1629 posted by Spike on 2015/03/29 18:53:12
@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
#1630 posted by Preach on 2015/03/30 00:04:46
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
#1631 posted by Spike on 2015/03/30 01:46:13
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
#1632 posted by Preach on 2015/03/30 09:36:59
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...
#1633 posted by Spike on 2015/03/30 17:23:44
'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
#1634 posted by madfox on 2015/04/29 23:12:44
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
#1635 posted by Preach on 2015/04/30 06:38:44
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
#1637 posted by madfox on 2015/04/30 11:24:17
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
#1638 posted by madfox on 2015/04/30 11:29:02
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
#1639 posted by ijed on 2015/04/30 17:04:52
Steal the one from the Rubicon2 source?
Not Bad
#1640 posted by madfox on 2015/05/01 01:24:39
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.
#1642 posted by necros on 2015/07/01 03:33:49
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?
|