leafs (... leaves ...) contain an arbitary offset into the compressed pvs lump. They don't start at predictable places, and the qbsp is free to overlap duplicate sequences.
Breaking it into 'two byte sets' is thus a silly thing to do.
That said, I have no idea why you would find a 0 0 pair anywhere in the data unless it was unused, which is a possibility. 

I think you're correct in identifying that the pairs after 7 11 do not parse correctly according to the decompression algorithm. Can you recheck the code that's getting the block of visdata? You may want to check if you get the same data by following the design of the original code more closely: reading each leaf, taking the visdata offset from that leaf, and then reading a pair of chars from that offset. 

Leaf 0's pvs is always "everything is visible". Is this handled as a special case, or does the vis lump contain an entry for leaf 0 as well? 

Okay.

This is the compressed vis data for my testing map.

VisData: (26 bytes) 255 10 255 2 207 10 207 10 243 2 243 2 255 10 255 10 0 1 15 255 15 0 1 7 205 11

I'm inclined to think it's good, because when I use it the level renders correctly. I currently do not decompress the zeros, I can get away with this on my test map because the leafs are so few. Every leaf renders correctly except for 9 and 11, which are the only two leafs to include a zero in their PVS. Fair enough, since I'm not handling the zeros yet. I'm about to, and want to make sure my thinking is correct.

Take leaf 9. It's compressed vis bytes are 0 1. Each leaf takes two bytes of data to have enough bits. After the 0 1 in the data is a 15.

To make sure I'm thinking correctly, this really means it's vis bytes would be 0 15, because it means 0 (starting zero run) 1 (add one zero, done with zero run) 15 (non-zero, add directly).

Is this correct? 

To make sure I'm thinking correctly, this really means it's vis bytes would be 0 15, because it means 0 (starting zero run) 1 (add one zero, done with zero run) 15 (non-zero, add directly).

Is this correct?

You are correct in how vis leaf 9 works. I think it does expose a problem though.

You started by calculating that each vis leaf requires 2 bytes to store the visibility data of 13 leaves. You then reported that this makes the size of the vis data 26 bytes. The crucial point is that 26 bytes is the size of the uncompressed vis data. We would expect the compressed data to be different in size, otherwise why bother with compression?

To complicate things further, there's an issue of map size. Your map, being unusually small, exposes a rare corner case of the compression algorithm. Leaf 9 has compressed vis data 0 1 15 - that's three bytes. Even if the other 12 leaves lacked zero bytes, that's 12 * 2 bytes + 3 bytes = 27 bytes. The algorithm has made the "compressed" data longer than the uncompressed data!

The important takeaway lesson is that we can't calculate how long the compressed vis data for a map will be from the number of leaves. In most real levels it will be smaller that the uncompressed data, in small box levels it will be larger. The only way to get the correct size is to parse it byte by byte from the file. 

That's what I was doing. Sorry I didn't mean to make it look like I was trying to calculate the size of the compressed data using the number of leafs. It was only by chance that the number of bytes in the compressed data was twice the number of leafs, and that it was two bytes to store the uncompressed pvs for a leaf.

Great to have reassurance though :)

I think I may have it working, it works correctly on my tiny test map, and on Stalwart, a small-ish dm map. Time to get some bigger maps and see what happens. 

Alright, I have PVS working for the world itself. How are models other than 0 (the world) handled? Does a leaf's PVS information contain info on every leaf, or just leafs in the same bsp tree/model? It looks like it's just in that leaf's own tree/model.

Are other models just handled via frustum checks? 

pvs is used for 3 things:
bsp rendering (drawing less bsp faces).
entity(net) culling (reducing network traffic).
gamecode logic (trivially skipping tracelines).

the renderer might want to cull submodel faces based upon view position.
or it might batch the entire submodel and be faster if it doesn't then try to split it up.

the other two situations generally use positions relative to the world. submodel pvs information is likely not useful, although it might be handy if both positions are expressed relative to a submodel. such cases are both awkward and minor, as well as infrequent.

phs next? :P 

Don't think Quake 1 has PHS, I think Q2 started that :)

My implementation is still a little buggy, due to way I'm handling, or rather not handling, the different models in the .bsp.

Do I need to find the player's position in every model's bsp tree? Right now I find what leaf the player is in starting at node 0, which works but all the non-map models (like doors and elevators and the like) are not marked as visible.

Should my process be to walk the bsp tree for every model? Does each model's head node point to a tree that can be traversed using the .bsp's planes, and end in a leaf for that model? Does this mean there's going to be a set to render for each model in the level?

I was so focused on getting pvs for the map working, I didn't stop to consider what the overall process should be. 

QuakeWorld has phs.

submodels are completely separate objects from the world model. they all have their own separate bsp tree. they just share indexes. node 0 is generally the world's root node, but you'll need to check the submodel lump to find the root node for all the others (and ideally world too).

the view leaf(s) will be different for each submodel, if only because each model has a unique set of leafs.
Either way, translations and rotations would mean you'd need to find the view leaf for each submodel even if they shared leafs. 

That should be simple now that I have methods for vis/pvs and bsp walking going. Good to know I wasn't barking up the wrong tree.

I think I'll actually take a break from this and work on lightmaps. Graphics stuff is more fun. :) 

I've got the tree1.mdl and I'm trying to give it a BBOX size of

setsize(self, '-8 -8 -16', '8 8 96');

But in game the bbox is the size of the entire mesh, which makes it too big to use.

What am I missing here? I've experimented with different collision types and so on and nothing seems to work. Does the mesh itself have some sort of hidden flag forcing this behaviour from qc?

I've got other objects which allow me to manipulate their physical dimensions no problem using the same method... 

This is probably not the issue, but have you made sure the setsize call happens after you set the model? 

I was being 'clever' and made a little subroutine to do that for me, leaving it at the end.

So... with that out of the way, if I do this on purpose will the collision be both the right size and orientation? 

I was being 'clever' and made a little subroutine to do that for me, leaving it at the end.

So... with that out of the way, if I do this on purpose will the collision be both the right size and orientation? 

bbox+bbox collisions fully comply with specified sizes. bbox+bsp collisions have weird offsets+discrete supported sizes.

bbox+bsp collisions are based upon the mins of the bbox rather than the origin of it.
this means you can increase the mins_z to move it up off the ground or decrease it to let droptofloor/walkmove/etc position the base of the tree further into the ground or whatever. it also means you should really try to keep the x+y set to the size of a bsp hull.

if you never use walkmove/droptofloor/tracebox/movetogoal/pushers on your tree then none of that applies and you can set the size to whatever the smeg you want. movetype_none, woo. 

That clarifies things. I've noticed different behavior in different engines as well, but it all seems to come back to not knowing the ins and outs of the format to begin with.

Let's do map objects! 

To tie in to the save-game shenanigans from Sunday, here's a blog post describing how to use Preach's black magic for good instead of evil:

Debugging and Save Games 

OK, so it took long enough to debug and make correct that the discussion died down, but here's a post on making ogres play fair and aim vertically:

Proper Ogre Aiming

Hopefully I'm hitting the right balance of maths and code here today, but please tell me if it was too cut-down to comprehend, or waffled too long on the whys and the sums. 

...

But I can't wait for someone to compile this so I can get smashed by ogres. 

And I just updated their qc in RRP X) 

Hopefully I'm hitting the right balance of maths and code here today
Thank you, thank you, thank you! I really can't get my head around all the maths without a good example in QC. This is just perfect for me because I can tweak it and try out different things. 

There are a few places where I made myself leave things out from the QC code as posted, even where the changes are natural and not that hard. This was to maintain the focus on the new idea. Getting gravity correct and moving the launch point of the grenades forward are two such changes that would have distracted; I wouldn't release a mod without them.

The one that I'll share here is how to do the tan function correctly, as you might use it in a maths library. The flaw as I see it is that it changes global state, purely as a side effect, by calling makevectors and overwriting v_forward. It's not hard to imagine how this could break code if users were not aware. Here is the fixed version of tan, which was cut for space:

float(float theta) tan =
{
� local vector ang; //temporary used to calculate trig values
� local vector v_forward_temp, v_right_temp, v_up_temp;

� //save off global state
� v_forward_temp = v_forward;
� v_right_temp = v_right;
� v_up_temp = v_up;

� ang = '0 0 0';
� ang_y = theta; //assign theta to the yaw to simplify reasoning
� makevectors(ang);
� theta = v_forward_y / v_forward_x;

� //restore the globals
� v_forward = v_forward_temp;
� v_right = v_right_temp;
� v_up = v_up_temp;

� return theta;
} 

@Preach, I finally got around to merging your code into my ITS QC base and it works like a charm! Thank you :D

You got a spelling mistake in your tan2 function:
"and = '0 0 0';" should be "ang = '0 0 0';"

Also I highly recommend you prefix your tan/tan2 functions with "mathlib_" otherwise they conflict with the DP extension QC file.

I personally prefer (self.enemy.origin + '0 0 24') otherwise the grenades have a habit of falling short most of the time and especially if the ogre is below the player and close to a ledge. 

Need to get this replacing my dodgy code.

I like your approach, it's the more difficult way of doing it, but intrinsically better.