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. 

Oh!! That's what those hideous comment blocks are. I figured it was just a way for someone to copy and paste it over into some wierd editor definition in case they lost it. It sounds cool but I still don't understand the use case.

What other formats are there other than .def and .fgd? 

The use case is that the original QuakeEd (that id developed and used on NextSTEP to make the original maps) parsed the .qc files and used those definitions to display what entities were available.

The modern use is that all the entries can be stuffed in a .def file and trenchboom (etc) can use them to populate the entity list.

I'm not aware of anything other than .def and .fgd, but maybe there are other formats in use in some of the more esoteric editors. 

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!

This is a bit of a tautology - the reason those comment blocks were there was so that ID could write the .def file inline, and then extract it into a single file using a command line tool. The comments don't do anything for the QuakeC processing of the file. You're basically saying you can take all the effort out of writing the .def file, so long as you've already written the .def file. 

Thats true however I think the original QuakeEd read the QC files directly at launch and there never was a tool to pull the definitions out into a .DEF. I may be wrong though.