any value less than time will give you the soonest think function possible

As Spike has pointed out a few times, when a think function is called, for that dive into the code only, time is set to what .nextthink was before being reset. So the most reliable way for a "do this next frame" is probably self.nextthink = time; 

Only if your code depends on the value of time in some way. If all you need is for it to run in the next server frame then you can take the shortcut. If time cannot every be less than 1 then a value less than 1 is always less than time... 

i think it's more about successive thinks.

the less aligned monster thinks are, the less impact the ai routine has when it's run, i would think.

if you just set nextthink to 1, every monster will be thinking at the same time. 

could someone modify MH's Aguirre's light utility so that it casts shadows from bmodels?
and maybe a new key '_noshadows' to disable shadows on that particular bmodel?

or is it not possible? like bmodels can't be used for some reason? 

Not commenting on how it can or can't be done, but I'd recommend making it opt-in rather than opt-out. Having an entity key _castshadows which you set to 1 to enable the new function would keep the current behaviour on existing maps, which is always desirable when possible. I also think there's a good chance that the cases you don't want it on (entities which move or have little to no impact on shadow casting) outnumber the entities which would benefit. It would make it reactive - used only when the lighting looks wrong - but I don't think that's a bad thing. 

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.