If you don't want to set a wait value manually, instead of using self.wait in that code you can generate a random number between 0 and 1 using random() instead.

Can you see how to adapt the code to use random to create a delay of between 0 and 1 seconds?

How about a delay between 0 and 2 seconds?

What about between 0.5 and 1 seconds? 

Obviously I posted that before reading the other thread. 

No worries thanks for the great tutorials. I am enjoying messing around with QC finally. Next, I am going to try and figure out a silent spawn without the tfog and audio next. I think I can do it. 

 

After trying to implement random timings I felt it better to go with self.delay. More work but more control for the mapper. Thanks everyone! 

/*==========
te_lightning
==========*/
void(vector v1, vector v2) te_lightning =
{
WriteByte (MSG_BROADCAST, SVC_TEMPENTITY);
WriteByte (MSG_BROADCAST, TE_LIGHTNING1);
WriteEntity (MSG_BROADCAST, world);
WriteCoord (MSG_BROADCAST, v1_x);
WriteCoord (MSG_BROADCAST, v1_y);
WriteCoord (MSG_BROADCAST, v1_z);
WriteCoord (MSG_BROADCAST, v2_x);
WriteCoord (MSG_BROADCAST, v2_y);
WriteCoord (MSG_BROADCAST, v2_z);
};

Writing some TE_ helper functions has gotten me curious. WHY is there an entity parameter needed for the lightning, beam, etc? Is it safe to just write world? 

I figured it out. It uses the entity as the start point regardless of the co-ordinates passed. And this is why the lightning beam starts at the origin of the player, regardless of anything else. 

beams last 0.2 seconds. QC respawns them every 0.1 seconds.

the entity argument is just there to avoid the resulting double-beams issue (trying to depend upon precise timing would be too unreliable with network latency etc, hence why they last longer).
Using world would break when you have two players firing beams, although some engines do understand world to mean 'don't replace any beams'.
tbh 99% of the time that entity arg will be self.

ignoring the startpoint and using the player's position is just to smooth things out so that the player doesn't leave the beam behind when moving sideways etc.

note that there's already an engine extension to provide those as builtins (with that name), so beware of potential conflicts if a modder uses *extensions.qc. 

original code has

LightningDamage (self.origin, trace_endpos + v_forward*4, self, 30);

(even URQP has it that way)

But i had long changed it to

LightningDamage (org, (trace_endpos + (v_forward * 4)), self, 30);

this is especially obvious when shooting from RL window on DM3 and aiming at someone on the lower bridge.
this is because:

org = self.origin + '0 0 16';
traceline (org, org + v_forward*600, TRUE, self); 

The original is "waist lightning". Darkplaces has specific settings to let you pick which style you prefer, waist or gunpoint. 

That only fixes the position of the bolt VISUALLY, which is what Spike was explaining. The above fixes the tracelines/damage as well. 

ya the original deals damage from the gun but visially it came from the hip
i keep confusing myself that sel.origin is the bottom of the model
where the feet touch the floor 

Still taking baby steps into QC with very little coding background. Wanted to check with experienced coders. This bit of code makes a trigger_push silent with a spawnflag. It appears to be working fine in game and no errors in FTEQCC but I feel like the syntax is still wrong.

Next steps will be to learn how to toggle it and add custom sounds.

//============================================================================

float PUSH_ONCE = 1;
float PUSH_SHHH = 2; //DMS push silently

void() trigger_push_touch =
{
if (other.classname == "grenade")
other.velocity = self.speed * self.movedir * 10;
else if (other.health > 0)
{
other.velocity = self.speed * self.movedir * 10;
if (other.classname == "player")
if (!(self.spawnflags & PUSH_SHHH)) //DMS
{
if (other.fly_sound < time)
{
other.fly_sound = time + 1.5;
sound (other, CHAN_AUTO, "ambience/windfly.wav", 1, ATTN_NORM);
}
}
}
if (self.spawnflags & PUSH_ONCE)
remove(self);
};


/*QUAKED trigger_push (.5 .5 .5) ? PUSH_ONCE
Pushes the player
*/
void() trigger_push =
{
InitTrigger ();
precache_sound ("ambience/windfly.wav");
self.touch = trigger_push_touch;
if (!self.speed)
self.speed = 1000;
};

//============================================================================ 

You could also check the spawnflags in the spawn function and only precache the sound if needed. 

Quakedroid would be about the only reason not to just precache everything. 

What does this mean?

if ( (rand()&3)==1 

if ( (rand()&3)==1
rand() returns a number between 0 and RAND_MAX.
&3 truncates all but the lowest 3 bits (so a random number between 0 and 3 inclusive).
==1 gives you a 1-in-4 chance of being true.
and there's no closing bracket, so the entire thing is a syntax error and won't even compile.

of course, rand's randomized bits are generally least reliable in the lower bits, so the above might be quite predictable, but it depends upon the rand implementation. 

Truncatorial bitwise AND. Mkay.

So 25%ish chance in movetogoal to "bump around" using the wall following code if the monster can't step in the direction of its .enemy

I guess that makes (rand()&1) evaluate to 50%ish chance. 

lowest 2 bits, sorry. and yeah, bitwise and.

movetogoal is just all kinds of screwed tbh. its very much an attempt to replicate doom's monsters, but in a way that's 5+ times as expensive due to all the floor checks etc. it can't slide along walls so can't deal with narrow passageways, etc. it works well enough, but its far from ideal. 

Its strung out multi-function calling madness yes. Trying to recreate it. 

So I got the save file and the console output, but I can't seem to find the correct coordinates for putting the camera in one place and a place to view it. What set of coordinates do I use for the 3 sets I'm given from the console output? 

Not sure it is what you're aiming, but in a mapeditor with a viewscreen it is easy to turn the view camera and the info_camera aligned.
Just make sure the arrow of both viewpoints are the same. 

https://mega.nz/#!piwDiK5B!Kc90JQEftzSbvCJSANqZNNpg-8yXboPY8rr4JiUCUIk

Here is a rotfish fix I knocked up for otp. It fixes the fish count, makes fish gibbable, makes them non-solid straight away when dead, and includes a fixed fish.mdl due to the bugged head size in the death frames.

It's all combined in a pak2.pak so it can be used as an id1 fix if you drop it in there.

Source is included, only fish.qc and monsters.qc have been modified however. 

 

Download: https://mega.nz/#!B2wTVa6A!RmkzKaD4VHhOX0zpz9QJjqKtwtKiRxEixT0AUMOtBLk

This is a command line based tool which will read a QuakeC progs.src and all .qc source files listed within, and output a .DEF file compatible with a map editor such as TrenchBroom. http://kristianduske.com/trenchbroom/

This assumes your QuakeC source files contain /*QUAKED*/ style definitions such as those found in the original id software QuakeC sources, as used by the original QuakeEd. For example, from items.qc in the original source:

/*QUAKED item_armor1 (0 .5 .8) (-16 -16 0) (16 16 32)
*/

This makes the laborious task of hand creating a .DEF file a thing of the past, as long as you include the relevant entries in your QuakeC sources when adding or amending entities. While not as powerful as .FGD files, .DEF files have a place and can be a quick way to add map editor support for your new mod!

Source code is included as a simple .c file, which should build on any C99 compiler.