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. 

Limit the player's movement speed to walk velocity without changing any cfg values? 

you can manually modify .velocity of the player when fl_onground is set. It's not going to be perfect though as there's no way to do this without changing cl_forward/back/side settings. 

Ok. My first thought was to just force always run to off, but I know there exist people who don't have that on by default.

But considering what I want to use it for (crippled state) maybe that won't be an issue. 

I would modify cl_*speed. Obviously *some* people may actually play with modified move speeds, but I think in your own mod, you have to be able to make some assumptions or decide not to cater to extremes. 

Ok, so I'm writing a tool that reads and writes quake wad files and was wondering if someone knows why some wads include the palette and some don't. Is the palette in the wad used anywhere? 

gfx.wad probably had the palette in it at one time, before it became a .lmp file instead. Perhaps that is where the palette-in-a-wad came from. 

so i should assume the palette in the wad is not used and therefore optional. 

So, what does 'Implicit Conversion' mean? I assume it means the result of the IF I'm trying is a constant, but I don't know why this:

if ((self.angles == 90) || (self.angles == 270))

Produces it. Basically if it's been rotated to face north/south as opposed to east/west do X instead of Y. Both of which are bounding box definitions.

Little help? How do I write that IF statement so it's not an Implicit Conversion?