We can pick atten to lie between 0 and 4. The engine now defines:

nom_atten = atten / 1000

dist = nom_atten * length(sound.origin - player.origin);

So the crucial thing here is to notice how the attenuation affects the distance.
Attenuation 2 samples are effectively twice as far away as attenuation 1 sounds.
Attenuation 0 sounds are always treated as distance 0 away.

The next thing you need to know is that the volume is multiplied by
( 1 - dist) * rscale in the right ear and (1 - dist) * lscale in the left ear.

rscale is equal to 1 + v_right*normalise(sound.origin - player.origin)
lscale is equal to 1 - v_right*normalise(sound.origin - player.origin)

Don't worry too much about what rscale and lscale mean, just be aware that they are never negative and sum to 2.

We need to compute when both the left and right ear go to zero volume, as in that case the sound is not played.
We know that lscale and rscale are never both equal to 0. So the only case we need to think about is

1 - dist <= 0

this implies that
dist >= 1
so
nom_atten * length(sound.origin - player.origin) >= 1

atten * length(sound.origin - player.origin) >= 1000

It is best to keep the inequality in this form, so that you don't have to worry about dividing by 0 if either the attenuation or the length go to zero.

In real terms, this means a sound with attenuation 1 is audible 1000 units away, attenuation 2 is 500 units away, etc. 

 

Quake God as Sub-Nigurath 

If you are going to run this function very frequently, then you might consider it a candidate for optimisation. As it happens, this inequality is ripe for one of my favourite optimisation tricks. It hinges on the idea that calculating the square root of a number is expensive compared to regular operations such as addition and multiplication.

The length of a 3d vector is calculated as

sqrt(x*x + y*y + z*z)

What we notice is that if a and b are > 0 then

a*a >= b*b is equivalent to a >= b

so we can rewrite our inequality from earlier as:

atten * atten * length * length >= 1000*1000

But we have multiplied length by itself, which reverses the sqrt involved in the calculation of length, and takes us back to the value before that step.

So we can replace that with

atten * atten * (x*x + y*y + z*z) >= 1000000

If we were writing this straight in C, there would be no doubt that this method is faster, it replaces one call to sqrt with a single multiplication. In QC, it's a bit harder to decide if it's beneficial, because vlen would have done the multiplication in the brackets for us, which is a little cheaper than doing it ourselves in QC.

In effect, we have replaced the function call to the builtin vlen with four multiplcations and two additions. It's worth noting that a function call has quite a bit of overhead too, so it's likely that we're a way ahead in doing this. If I'm really honest, this is more of an "inner loop in critical c++ rendering code" optimisation, but it's cute to look at. 

very simple when it's all laid out like that, and a nice trick for optimizing vlen calculations. ^_^

(as it turns out, i have other parts in my mod that require frequent vlen calls as well) 

That value of 1000 *may* have been 1500 in an earlier version of Quake. This is based on a comment I saw in somebody's source maybe 6 years ago; can't remember where or who now.

I've no reason to either doubt or believe it, but I've switched to 1500 myself (in fact I've turned it into a cvar) as I like the extra ambience that it generates in a map. 

now that i know a little more about it, i found this line in snd_dma.c for fq085:
vec_t sound_nominal_clip_dist=1000.0;
so it looks like id brought it back down to 1000 unless metl did that, but there's no comment there about it. :) 

Iris doors involve maths. Hypotenuese etc.

I got lazy and used a prefab - the lip is difficult to work out. 

 

that's the problem, yes.

the alternative is to set the movedir directly in the map file, but that requires a quakec change (since as written, a func_door always calls SetMovedir() which clobbers any movedir you set in the map file.) 

Can't be vertical either. I did consider adding a flag to doors, but it seems a bit overkill.

I already have a func_door_model, so maybe that's the cleaner solution. 

He uses a lip of 49 and -49 equally on the
8 doors. Maybe the bounding box of each of
his doors are the same size to get that lip.

Otherwise its movement seems perfect, without
gaps. 

Example has a total of four different lip values with the opposite pieces moving on the same axis being the same.

None of the values are negative either.

A .mdl solution is a maybe, but not ideal since I'll have to fake the collision. An external bsp could either prove impossible or the solution to everything... 

Yea, it's just those 4 doors that move at 45 degree angles that have a lip thats hard to get right. Maybe Iikka's brush model at the corners (45 degree) have multiple brushes to change its bounding box, thus making it easier to figuring out the lip. 

if you modify the qc to set the movedir yourself, you can make vertical iris doors too. 

And I do have a place for a vertical one that would be very cool since the player is thrown through it as it opens by a trigger_push into a large section of pipe beyond.

Will have to think about this. 

The prefab of the irisdoor was a rather strange collector item as I couldn't find it in the Qoole prefab directory.

I saw it once in 2004, when the Qoole side still excisted. I couldn't find it as it was in qml format. When I finally found it I realized all the lip sizes were in it, and I even understood less from what I saw.
Glad I could find it in my dusty archive.

I tried a vertical irisdoor with func_trains,
but it really gave me the creep. 

func_train works in theory. Would be a lot of pissing about on a very small grid though. 

I am having trouble with my Ogres.

Going upstairs he is OK but when he returns, he seems to get stuck and twizzles around on one or two of the steps. He looks like he is searching for the way down but never finds it. Other monsters, such as knights and hell knights, are fine and follow the same path_corners without any trouble.

Is this a bounding box issue and do I need to allow more room on one side going in one direction?

For instance, I seem to remember that in the xy view, the lower left hand corner of the path_corner is significant. But could there be relevance to the direction of travel so that I should allow more room on one side in one direction but more room on the other side in the opposite direction?

There is only one monster on this path and no other monsters can cross the path, or otherwise get in the way of the ogre. 

Well, Hell Knights have the same bounding box as the Ogre so I'm not sure what could be going on... 

id1 Ogres as the same size as a Shambler, so if there's a bottleneck smaller than 64 units they can get stuck. 

If you use your own progs, you can simply give ogres the smaller bounding box. 

No they don't. Hell knights use the smaller box, ogres use the larger box.

If the ogre is going up fine, but not down, then you need to raise the ceiling by the height of the step. If it still doesn't work, then keep increasing the ceiling height. But 1 or 1.5 x height of step should be enough.

For gb's suggestion to work, you would need to make them use the smaller box. And yes, they do completely fit inside it. 

in order for a monster to take a step, it has to have it's 4 corners of it's bbox 'on ground'. the monster is allowed some leeway, but if the steps are too short, it would have to 'skip a step' which makes the vertical distance too far down.

essentially, the big monsters need bigger steps. :P 

obviously, without seeing the map, i can't be sure, but i don't think it's a ceiling issue.

the check when walking up a step is different from when walking down.

it is allowed to step up more than it is allowed to step down.