thanks for confirming that for me. i was looking at the engine source, and that was what it looked like, but i'm not familiar with it enough to be sure.

i do remember the bit about time being set to nextthink time on think calls. i've used your 'servertime' workaround often because of it. :)

as for making a fakethink sorted list, i thought of it, but i only have one bit of code where it would be important, and it felt like it was better to just solve the problem by working around it rather than making the whole fakethink system.

thanks! 

Is it possible for one entity to affect (stop) the sound of another entity e.g by forcing a null.wav to play on that other entity's channel?

I have just noticed on an old map of mine that when the player dies the music keeps playing, which seems wrong to me. I thought I might just be able to drop a 'sound' line into Player DeathSound to say kill the music, then carry on and play whichever death sound you want. But I do not know how to use the sound(self,...) parameter to point to a specific entity.

Alternatively, could I stop all sounds just before playing the Player DeathSound? 

instead of "self" in that sound call, use the name of another entity. 

(i.e. the entity that you want to silence) 

also of note: make sure you play that sound with 0 attenuation to make sure it is 'heard'.
if you are outside audible range, the engine won't even bother registering the sound and so won't interrupt a previous one playing on that channel. 

metlslime: thanks, once I realised that I needed to add the entity name to ALL parameters, we wuz cookin' on gas.

necros: it's in the form of:
sound (self, CHAN_VOICE, self.noise9, self.volume, self.distance);

where 'noise9' happens to be the null.wav, and everything else is already set from within the original entity's entity definitions.

It works just fine now: music stops, player does his death sound and dies gracefully, monks start chanting a dirge - I keep allowing myself to be killed because I find it ever so slightly amusing :)

(One day, I'll get the hang of this .qc stuff) 

concerning c++
i've been messing with that fake GI hack with MH/Aguirre's light and the main block right now is integer precision...

specifically, in order to get better results, i need to add more suns. the more suns i add, the brighter everything gets.

i'd need to use a light level of maybe 0.5 or less.

unfortunately, everything's in ints.

how hard would it be to convert everything to floats and would that markedly slow down light calculations?

is it even worth doing? :P 

so... i posted that and then i just thought of a better solution (albeit, one that's way more hacky).

i was thinking i could assign all sunlight a different light style and then give it a light style of z to n instead of m... 

yeah, that didn't work that well. :P 

Out of interest - what are the performance implications of using styled lights on that sort of scale? 

All lights in quake are styled, you can see the code which sets the styles in the worldspawn function with. Performance costs are only incurred when the style changes, either due to an animated style (multiple letters) or calls to lightstyle to alter the style.

Incidently there's a trick to making easy lightning effects relating to this. Lighting tools put all the sky lighting on style 0, but we can see that it's possible to alter the levels of style 0 in the same way as other styles. If you put all of your static, sourced lights on a different style, you can reserve style 0 exclusively for light from the sky. Then you can quickly switch the style to intensity "z" to create a flash of lightning while keeping indoor lighting constant. 

I know what I'm gonna be doing now!

Cheers. 

awwww 

it's also annoying because you have to remember to set all your normal lights to a style other than 0. although, i guess you could code up your qc to default to another style.

I don't think qc will help you; styles have to be set up in the map file (either "style" or "targetname" on each light entity) so that light.exe knows about them. 

oh that's right. ouch. 

I'd edit your fgd/def file to make other lights default to a different style. I'll admit I've not tried it, so maybe the effect isn't all that dramatic. It sounds like it's one of those things where you could get a good effect in the bsp format, but that maybe the tools for it aren't quite there yet... 

is there some kind of bug where triggers touching each other can cause a touch function to run on the other trigger?

ex: trigger A and trigger B are touching.
player touched trigger A, trigger A and trigger B both run touch functions. 

Sounds like you forgot to set the trigger_dont_link flag. 

you're thinking about door_dont_link.
this happens with just normal triggers. 

 

Any chance that it can be because the trigger brushes are oddly shaped, and the resulting bbox shaped triggers end up coinciding? Never heard of an effect like this before, might have to take a look at the map to figure it out.

Another tool that I've only recently begun to use is the pair of builtins traceon and traceoff. Calling the former means that all the QCasm instructions get printed to the console until you call the latter. It's about as close as you can get to a debugger for QC, and a lot of the time it's much quicker than adding a bunch of dprint statements to nail down a bug. Putting them round the touch functions might be helpful. 

this actually happened in ne_ruins.
it's in that little corridor between the two maps, in the start map, there are a couple of triggers that get fired depending on flags (ie: just entered the map or returning).
except they were both firing until i spaced them 1 unit apart.

i'll have to try out those builtins... 

yikes... that's a LOT of output.
it'll take some time to get used to reading this.
i suspect it'll be best to turn it on and off sparingly. 

Yeah, it's not something that you want on functions running many times a second,it might be necessary to turn it on right after the basic touch rejection code. The thing I found it best for was when I have a function with lots of if branches, and needed to work out which ones it was taking or rejecting.