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. 

Suppose that you are writing a mod which other mappers will use, and you want mappers to be able to control a parameter. In this post I will use corpse-duration in a corpse removal system as an example. Traditionally if you wanted a global property then you would add a field to worldspawn to set it.

Apart from it being a bit of a waste to add a field to every entity which is only ever read from worldspawn, I think there is a better pattern, which is a bit more powerful. The key use-case is a property which a mapper might want to vary as well as set initially. Corpse lifetime arguably fits this criteria, for example: during a large horde combat you might want to remove corpses faster than the rest of the map.

My suggestion is to create a new entity function as follows:

float corpse_duration;
void() set_corpse_duration =
{
��corpse_duration = self.count;
��if(!self.targetname)
����remove(self);
}


Then the way to set the corpse_duration initially is adding a point entity with classname set_corpse_duration and count equal to the desired duration.

Can any of you keen entity hackers see how we change it dynamically? Well, we set up an entity with the desired count, but with "classname" "info_notnull" and "use" "set_corpse_duration". If we set a targetname then every time we trigger this entity it sets the corpse duration. If you want to codify it as less of a hack you could invent a new classname for this kind of entity like set_dynamic_property, but it doesn't need any supporting code.

The remove(self) bit of code is a bit ugly, but it makes sure that initially setting the property doesn't cost you an entity, yet the info_notnulls can be used multiple times. 

I am trying to query a monster to see if the current enemy has an artifact enabled. I am using (self.enemy) and I checked to see if it a player. I query the flags (self.enemy.flags) and it does not show the player flags properly. I tested this by using an artifact routine (void() powerup_touch) to print to the console what it was doing and it produced a different flags value.

I double checked the classname field and other player variables and it is certainly looking at the same entity, except the monster query will not show the content of the flags correctly.

Is there something strange about queries with the player flags? 

what value are you seeing? how are you querying for flags? flags must be checked via bitwise operation (self.enemy.flags & FL_CLIENT) will return 1 (true) for the player.
are you saying you do the above operation and it returns false when the monster is angry at the player?

also note that players gain and loose flags a lot during play, godmode, notarget, onground, partialground... 

I was mixing up .item and .flag queries. I was too tired to see the difference and could not understand why. doh! 

to add to progs.dat.
I'm quite the noob when it comes to coding.
Included misc_model entity from a old tutorial, but that was just copy/paste and compile.

For example i would love to have such swinging door's/ pushable func_rotate things like in ne_ruins.
Googled, found no tutorial for that yet, and dont know what other stuff could come handy.
Suggestions?