There aren't any trade secrets in Quoth, if there's any other features people want to understand just shout and I'll put it on the tutorial list. Thanks for the pointer on the keyword order, I'll fix that in the text. 

There aren't any trade secrets in Quoth, if there's any other features people want to understand just shout

I think you are completely wrong! I have seen CZG, necro, Kinn and metlslime QC files and all of them were amazing sets of code which has made my understanding of QC better. I think you seriously under estimate the value of letting people see a working codebase. Cherry picking examples is all well and good but seeing the whole picture is damn right educational.

For example I would love to see the AI code for a bob from Quoth, I love how they move, shoot and even their crazy death is cool. Another gem I would love to see is the working code for the ladders in Quoth, not text descriptions but actually working QC files.

There are tons of things about Quoth QC that would be awesome to look at and I personally believe the greatest thing you could ever do for this community is let people see what QC tricks you have done. 

I should probably post the RMQ qc somewhere.

<Most hated project ever yadda yadda go fuck yourself>

Would any of the people the above didn't apply to be interested in seeing it?

There are some gems in there, like Supa's NPC code and the Shambler lightning attack visual improvement.

Exploding zombies and fast zombies were mine, and pretty cool if I do say so myself :>

I think next map (after I release the current one) will have the exploders in it. 

For all its faults, RMQ had some wonderful things in the qc. 

Map were also incredibly epic... 

 

https://www.youtube.com/watch?v=xnOLhXmhkyA&t=4m8s 

Wish those would get released standalone. 

https://www.youtube.com/watch?v=_NrHNilIqLo 

That looks flocking amazing! 

Why is:
void() frame = [ $f1, self.th_run ] {};
not allowed?

error: Type mismatch on redeclaration of self. void (), should be entity 

In short, because the newthink function has to be determined at compile time for the frame definitions to work.

In long: the [frame, newthink] notation in QC is usually described as a shorthand, but it's actually a bit more than that. When QC is compiled it gets turned into opcodes (like java). Most of the opcodes are pretty generic and normal, but for efficiency reasons that made sense in '96 there's a special opcode which does all the basic monster housekeeping:

* it sets the frame
* it sets the new think function
* it sets nextthink to time 0.1

The only way to create something with this opcode is to use the special [] notation, but once you do, you're locked into using the opcode, and it needs to hardcode the function. I suppose in theory a compiler could treat the [] differently - detect when a dynamic expression has been input and in that case skip the opcode optimisation in favour or writing the relevant QC manually. Might break the principle of least surprise though... 

state functions need special handling if only because they're the one place where a variable can be used without prototyping it first.
this means that the qcc is expecting explicitly a function name and not a statement/formula, and is naturally complaining when the name it saw (self) was not in fact a function as required by the opcode.
the .th_run] part of the definition has not been tokenized yet. 

thanks, that makes sense. :) 

I've got a large enemy that fires twin streams of projectiles from either hand, each being offset quite a bit from the centre to either side.

The point they aim at has a scattered origin, randomising within a small volume to make the fire pattern more interesting.

In a small test map the enemy works fine, but in my main map it occasionally looks like it's the point of origin and not the point of aim that's getting slightly randomised.

Does this sound like an engine precision issue? 

depends how large your projectiles are.
with the vanilla network protocol, origins have 1/8th qu precision.
angles have 1/256th revolution precision

on a large object with offset origins (read: rotating bsp doors), the angular precision can result in significant jerks. this is generally not much of an issue with models though.

if you want to test if its an engine precision thing, try the following engine+cvar settings.
fte: compare sv_bigcoords 0(low/vanilla precision) to 1(16bit angles, 32bit float coords). restart the map for it to take effect.
dp: compare sv_protocol 'quake' (vanilla) to 'dpp7' (16bit angles, 32bit float coords), or whatever it was. not sure what you need to do to actually apply the new setting. 

So that pretty much rules that out. I need to debug again.

Thanks for the answer. 

you're using makevectors and v_* to do the offsets? 

yeah, makevectors(self.angles) is bad if self.angles_x will ever be anything but 0.
makevectors pitch angle is inverted relative to non-brush models (old id bug).
yes, its inverted relative to vectoangles too. 

I got it working eventually in a testmap like I say, without any weirdness. Just in my large BSP2 it seems like the org (point of origin) is behaving like the vec (point of aim).


org1 = self.origin + v_forward * 20 + v_right * 36 + '0 0 24'; //right hand
org2 = self.origin + v_forward * 20 + v_right * -36 + '0 0 24'; //left hand

vec1 = self.enemy.origin + RandomOffset(22) - org1;
vec2 = self.enemy.origin + RandomOffset(22) - org2;


The RandomOffset function just does this:

local vector offset;

offset_x = crandom() * offset_amt;
offset_y = crandom() * offset_amt;
offset_z = crandom() * offset_amt;

return offset;


Am I missing something obvious there or taking something for granted? My coding is built on trial and lots of error, meaning I kn ow nothing of good practices etc. I don't have makevectors anywhere in the qc file actually... 

makevectors is where v_forward and v_right get populated. if you don't call it on self before doing all that, they'll be left over v_forward and v_right vectors from whatever thing last used them. 

It was all in my head about it only happening in the larger map.

Will test it out tonight, thanks. 

After all that pissing about it turns out I just forgot to reset the vectors.

But it works now!

Screaming plasma death coming to a mod near you 'soon'. 

I'm currently trying to make some simple tools for working with wads and paks that work via web browsers. I know this sounds pointless, but given that texmex, qped and pakexplorer are windows only, I thought it might be worthwhile so that people on any platform can fiddle with these formats.

Although both formats are trivial, I've noticed a few weird things with the contained images. I've been looking at the (old and eronious in a few spots) quake specs, and there seem to be three different types of image format used in Quake:
1. pixels
palette files, conchars in gfx.wad, colormap.lmp and maybe others
2. width, height, pixels
most, if not all lmps and status images in gfx.wad
3. name, width, height, pixels1, pixels2, pixels3, pixels4
all standard textures contained in most wads and bsp files

WAD file entries contain a type parameter that specify which format is used, but I've noticed that this isn't always correct. In gfx.wad, for example, the file conchars is listed as the same type as a regular wall texture (type 3), yet has no header and is exactly 128x128 bytes. The lmp files in pak0.pak also contain a couple of textures that have no header, whereas the others do, and a handful of them are strange sizes.

The mystery lmp files are 3352 bytes each. Since all images are meant to have width and height that are multiples of 8 the size doesn't work out, even accounting for an 8 byte width x height header. Just wondering what kind of files these are. The names are " gfx/dim_???.lmp" and "gfx/netmen?.lmp".

Should I just ignore the size and assume that aside from the special cases I mentioned above, that all UI textures and lmps are class 2 and all wall textures are class 3? 

but to answer your question, I don't know. probably!