maybe. either way, it'd still be great if someone could haxor that in. :) 

we were talking about how bsp models use their bboxes to figure out collision a little while ago.

i mentioned about setting bbox in qc affecting that. i tested it out, and yes, if you manually set bbox size, you can don't need to put visible brushes at the min/max extents.

also, if there are visible parts of the bsp model but the bbox is smaller, any bits outside the bbox are nonsolid. 

also, if there are visible parts of the bsp model but the bbox is smaller, any bits outside the bbox are nonsolid.

Hack of the week right there, folks. Awesome! 

what the heck is this anyway? :P 

It's a glitch in the trace code. It arises in the part of the code that tries to determine the exact impact point of a trace on a solid surface. The loop starts with a point at "0" which it knows is in the open, and a midpoint which it knows is in solid BSP. It then backs up from the solid point in small increments until it gets into the open, and so fixes the endpoint of the trace.

The glitch occurs because the increments don't always exactly hit the 0 point as they build towards it. It is possible for the trace to be in solid for all of the test points before 0, and for the increment to never hit exactly 0. The loop would then return the first point past 0 as the nearest point-in-open to the impact point(i.e. backup past 0). However, we already know that 0 is closer to the surface and in-open so that point is returned instead.

Phew, so basically I think this is most likely to occur on short traces where an endpoint is near a surface, as these are the traces where floating point inaccuracy is most prevalent, and I believe that makes a difference. However, there is a binary chop portion of the trace algorithm, so the circumstances that cause it to happen may just occur at random on any given surface.

Possibly also complicated or intricate BSP architecture could make this more likely, since you would have to dive down to a smaller scale to check exactly which bit of fine detail a trace collides with, but I've got no example to back that up with. 

that helps a lot to know at least what is causing it. 

Sounds don't start until one second after worldspawn. Is this 'fixable' from qc?

My FMB_BDG map finishes with an earthquake and it would be nice, from a continuity point of view, to start the next section with the tail-end of the earthquake. 

So it's probably fixable from the map(s). 

Completely untested, but if you spawned a static sound which didn't loop, does that cause an error? Otherwise it might just get around the problem... 

that helps a lot to know at least what is causing it.

Probably the most important thing to know about it is that it doesn't matter at all - there's nothing going wrong in your code and the engine has already coped with the potential inadequacy. So I'm not even sure the message is worth preserving in the engine... 

well, if there's no purpose to it... i just get spammed by it sometimes and it clears out the console buffer of useful debug text, which is annoying. good to know it isn't causing problems.

also, trying to spawn a static (ambient) sound that isn't looped results in that 'sound isn't looped' error we used to get with the broken ambient_thunder entity. 

i have a bad feeling about this but....

is there ANY way to detect if the player has either opened the menu or closed it? 

I can't see how you could, no QC runs while you're in the menu (assuming you're thinking of single player - multiplayer is different but no more helpful). You'd end up trying to spot differences from frame to frame in the same way that QC detects loading from a saved game. The problem is that you could quite easily go into the menu, do nothing and then leave after a while. I don't see how this would leave anything for the QC to find... 

yeah, i was afraid of that. :(
oh well, thanks anyway. 

What was this used for in SoA? 

cutscenes. it's a player model that will run to path_corners and wait for a few seconds, if 'wait' or 'delay' or something is set.
iirc. 

 

Has anyone ever tried porting func_areaportal from quake 2 to a quake 1 engine and related tools? Any idea on how hard it would/wouldn't be? 

So I've been thinking about a way to add a lot of new weapons to a mod, but I'm not sure about some things. The first issue would be how the hud handles the weapons, since there's only enough room for 9 weapons, I would need to figure out a way to make sure that weapons don't take each others spots. I was thinking of adding a precache variable to each weapon and then checking to make sure that none of them conflict with each other when the map starts. I think that would eliminate the problem of weapons taking other weapons spots. I have no idea how and for what reason they're placed on the hud the way they are, anyone have any insight on this? 

There's actually quite a lot to be said about the HUD but I'll try and get the basics into one short post.

The engine uses the QC field called items to determine which weapons to display on the HUD. If you look in defs.qc you will find the following:

// items
float IT_AXE = 4096;
float IT_SHOTGUN = 1;
float IT_SUPER_SHOTGUN = 2;
float IT_NAILGUN = 4;
float IT_SUPER_NAILGUN = 8;
float IT_GRENADE_LAUNCHER = 16;
float IT_ROCKET_LAUNCHER = 32;
float IT_LIGHTNING = 64;

To display some collection of these items on the screen simply sum the values of the icons you want displayed, and then set self.items to equal the total.

The numbers are all carefully chosen as powers of 2. This is useful because it makes any sum a unique combination of these numbers. It also means that you can use the bitwise OR function to safely add an item without checking if it is already there:

self.items = self.items | IT_SHOTGUN;

If we started with 0 items, and then blindly added IT_SHOTGUN to self.items we might get into trouble - if that line of code ran twice then self.items would equal 2 and we'd have IT_SUPER_SHOTGUN instead.

We can also use the bitwise AND function to test if an item is present:

if(self.items & IT_NAILGUN)
{
�//do something just for players with a nailgun
}

If the bitwise functions are new to you I'd advise searching for a c tutorial on them, it's probably been explained before in a clearer way than I'd invent today.

Other things to know about icons:
� Setting self.weapon to one of the IT_ values highlights that icon as the selected weapon.
� The mission packs added extra weapons which complicate the icons code somewhat, so I'll avoid that until another day.
� The engine automatically makes new items blink on the HUD when they are added to self.items. 

I made some path_corners in a map that are different z distances (hight/lower than another path_corner) apart, thinking that my flying monster would follow them. To my surprise, it didn't. After removing the z distance from my path_corners, the monster follows the path just fine.

It seems that with flying monsters, if path_corners are different z distances apart, they 'ignore' the path_corners. From a brief look at the quakec, everything looks ok. Maybe this is a bug in PF_walkmove? Looking at the function, it looks like it ignores the z axis all together (line 28), so maybe it's not a bug, Carmack just ignored it :p.

Note: This doesn't affect walkmonsters (as much) as flying monsters. With walkmonsters, they seem to be able be able to find their next path_corner as long as the z distance between them isn't too much (I haven't found out exactly what it is).

Looking a monsters.qc at the walkmonster_start_go and flymonster_start_go functions, and more specifically at if statement testing if there's a target, walkmonsters set their .ideal_yaw to vectoyaw(self.goalentity.origin - self.origin), flymonsters don't do this. I have no idea if that statement is related to the problem, correlation does not imply causation. :)

I need to fresh up on my trig.. 

it is a bug with movetogoal.
movetogoal does not check z unless both .goalentity AND .enemy is set.

if .enemy is set to a path_corner, it actually will track vertically. unfortunately, this necessitates a qc change.

ALSO, if you can believe it, THIS SAME FUCKING BUG IS PRESENT IN DOOM 3. CARMACK. COME ON MAN.
you will not believe the incredulity i felt when i set up a nice path for my cacodemons only to have them not able to fly up or down to reach them, even with AAS computed. 

walkmove explicitly does ignore z but it is only a simple 'step in this direction' function.
the function you want to look at is the movetogoal one, which does the random monster bumping around stuffs and probably contains the vertical adjustments for flyers when chasing enemies. 

Upon reading your posts, I naively added ``self.enemy = self.goalentity'' right after path_corner check in *monster_start_go functions in monsters.qc, thinking that it would fix all of my problems. Now the monsters are facing towards the path_corner and are in their walking animation, bit they're not moving at all. D: I suspect this has to do with a change I made, as I've been adding a lot of new things and haven't been testing any of them :p. oops.

Now 'all' I have to do if find what the problem is.. 

you will need to haxor it in.

basically, in ai_walk, change:

movetogoal();

to

self.enemy = self.goalentity;
movetogoal();
self.enemy = world;

or alternatively, create a movetogoal wrapper only for walking:

void(float step) walktogoal =
{
self.enemy = self.goalentity;
movetogoal();
self.enemy = world;
}

and just replace movetogoal calls with walktogoal in ai_walk.

the wrapper method is probably cleaner and if you make new walking functions, you don't need to repeat the hack.