Ahh crap, so no work around? Oh well... 

in the code, it looks like the sound comes from origin + (mins + maxs)/2, which means, the center of the bounding box at its default location, shifted to compensate for any movement (since origin for bmodels is normally 0,0,0.)

But, the mins/maxs for bmodels might be calculated badly by qbsp, so you could still be right, i'd have to look into that. 

If the platform is against a wall, you could have another hidden platform moving in exectly the opposite direction and maybe as you move out of the range of one sound, you'll move into the range of the other.

I have used that idea in a map where I wanted to draw the player's attention to a button operated bridge but the player was too far away to hear it - I just put another one of the same spec. in the floor beneath the player. It worked fine. 

Neat idea ... I'll try that, thanks! 

Remember that you can put eprint(self); in the spawn function of various things that use bmodels, and then compare them to what you think they should be.

Question for the coders, though: can you make the sound follow it around? 

can you make the sound follow it around with code changes? 

no & yes respectively 

Feel free to expand on both... 

without modifying the exe, sounds cannot follow an entity.

they are just spawned in at whatever entity it is tied to's origin.

this is the kind of thing i mean about id being lazy about sound in their engines.

another example would be quake 3 having doppler shift, but doom3 NOT having it. they actually took a step back... 

You can hack it in the progs too, for a reasonable return. The easiest way to do it is spawn a new entity with the platform, the "func_plat_sounddummy", so that the platform's enemy is the sounddummy and the sounddummy's owner is the platform. Then in plat_go_up and plat_go_down you replace the sound call with:

local entity oself;
oself = self;
self = self.enemy;

self.air_finished = time;
self.cnt = 0;
sounddummy_play();

self = oself;

Above them define:

void() sounddummy_play =
{
setorigin(self, (self.owner.absmin + self.owner.absmax) * 0.5);
sound (self, 1, self.noise, 1, ATTN_NORM);
self.cnt = self.cnt + 1;
self.nextthink = self.air_finished + 1.4 * self.cnt;
self.think = sounddummy_play;
}

Notice the unusual way to calculate the nextthink time, this makes the sounds play at as close to regular intervals as the discrete frames allow.

Similarly in plat_hit_top and bottom replace the sound call with

local entity oself;
oself = self;
self = self.enemy;
sounddummy_stop();
self = oself;

and define

void() sounddummy_stop =
{
setorigin(self, (self.owner.absmin + self.owner.absmax) * 0.5);
sound (self, 1, self.noise1, 1, ATTN_NORM);

self.nextthink = -1;
self.think = SUB_Null;
}


Then the sound gets restarted every 1.4 seconds. Of course, this isn't quite the same as the looping sound quake does usually, since it always plays from the beginning, and doesn't wait until the end to restart. But on a lift you can probably create a sound which sounds ok looped like this.

Further improvements would be to dynamically create the sounddummy and remove it once the lift has come to a halt(AND the halting sound has been given time to finish). Also making the looping time customisable/better fitted to your selected sound.

Of course, the best improvement would be to save the extra entity entirely. Unfortunately to do that you need to make the lift perform a number of "think" operations before it reaches it's destination, while remembering that it needs a "think" function for it's arrival at the final destination(see SUB_CalcMoveDone for the details of that). Add to that the fact that you have to work with self.ltime rather than time, and think about what happens to the sound if you're blocked(probably best to make the original sound a looping sample, but not to rethink - if you're blocked then the sound can afford to come from the same place until the lift is unblocked). So it's a much tougher proposition to get right. 

The duplicate entity moving in the opposite direction worked. Hooray! 

if anyone's mapped for half-life and knows what im talking about is it possible to get game_text into my quake maps? 

The map "Visions of Hatred" of Darin McNeal has a CCK.
A kind of Cut-Scene Construktion Kit.

Included is the 'Cut-scene Construction Kit' I developed for this level.
It allows the inclusion of scripted cut-scenes into quake levels."

http://www.quaddicted.com/reviews/vision.xml 

I am lighting a static model with a 'light' entity using 'mangle'. It lights the background but not the model.

If I then use 'light' without 'mangle' (default light value in both cases) the model it lit perfectly, albeit that so is a lot of the surrounding area, which I do not want (atmosphere, don't you know!).

So, I suppose my question is: could it be something to do with the (mangled) light's cone not covering the whole of the model's bounding box? Or is some other "undocumented feature" at work here? 

The surface below the model has to be lit properly. Maybe you can achive roughly the same effect as mangled lights by using multiple weaker lights with higher wait values. 

A mixture of two lights, one 'mangled' and the other, a plain light, lighting the floor below, looks just about right.

Only another 1000 or so lights to go... 

hey, iv made a door using the "func_rotating_door" solid class entitie and it just makes the brush disappear its no long there ingame... what am i doing wrong? could someone help me and tell me how im supposed to use it? thanks 

only some compilers can properly compile a map with a rotating brush. try aguire's compile tools. 

Frikac's cant? 

nvm thats qc sorry -.- 

No, his aquires compile tools did not help... maybe im making the door wrong?

all i did was make a door shaped brush and tied it to func_rotating_door 

func_rotate_door = info_rotate + rotate_object 

so when i make the func_rotating_door i should use it like a origin brush? 

http://shub-hub.com/files/trash_will_be_removed/rotate.rar 

http://kell.quaddicted.com/quoth/quoth_tutorial.html#rotatings