beware of force_retouch! it breaks trigger_hurt!

anyway, the touch function:
if (self.targetname)
if (self.nextthink < time)
return; // not fired yet

it uses nextthink as a random timer for some reason. just weird code. there's no special engine magic needed here, just the sub_null thing to stop the engine complaining when it does try to do its think magic.

it should have used attack_finished... 

Has caused me a load of headaches - a lot of the code I ported used it in loops, some of them per frame (!) which was raping FPS. 

 

Not sure what the intention was with a lot of them.

One in particular was causing a batch of triggers to touch themselves every single frame, meaning the more of that type of trigger I had, the slower it got. 

I meant "duh" to the answer to my question, since I could have just looked at teleport_touch and noticed it myself without having to ask anyone.


Some people just write code in incredibly bizarre fashion. They get fixated on entirely the wrong approaches and then use them for everything. I wish I remember what game it was, but some high profile indie game's source was available on pastebin or one of those, and it was an astoundingly bad clockwork machine of almost 100% string manipulation, in one huuuge header file. Maybe someone else remembers? 

But probably wasn't. 

Hey, so ... Is there an easy way in QuakeC to determine that the player has seen an entity for the first time? Like, an ammo or health pickup for example? 

hmmm not exactly.

you COULD just make a function call that continously runs every frame that checks all entities and marks any items it finds as seen, but that's pretty wasteful and might even cause slow down if there are enough entities in the loop.

Alternatively, you could create a one time, on map load function that builds a new list of only items and then the previously mentioned loop could only iterate through that list.

A simpler, but more manual method would be to just have triggers that mark entities as 'seen'.
This is the method I used in ne_ruins for a few ammo boxes. They are dynamically changed between small or large when the trigger fires on them but only once, so if the player has triggered the check when they had a lot of ammo and the boxes are small, they won't become large boxes later if they revisit the area with low ammo. 

Yeah, that's what I wanted to do ... dynamically scale health and ammo to the players needs. But I guess I won't. That sounds like a lot of trouble and really too much work for what it is...

Thanks! 

just have a crate you break open to get the item -- you can decide what item to spawn once the crate breaks.

Or have items drop off enemies, and scale the amount based on player's current needs. 

just have a crate you break open to get the item -- you can decide what item to spawn once the crate breaks.

Or have items drop off enemies, and scale the amount based on player's current needs. 

 

on your own board, no less!

I prefer using triggers to decide rather than crates because it feels like it creates a better illusion. 

the trigger thing seems pretty easy as long as you aren't running out of edicts. Just place one trigger in the previous hallway to spawn the item. 

So before I write it, has there ever been an OBJ to MAP convertor written? There had to have been, right? I'd love to use MODO to generate geometry that is downright tedious or impossible in Trenchbroom... 

Sharkbanana who can sometimes be found in #qc had a tool for generating q3 .maps that way. I don't know if he wrote it or got it from elsewhere.
it didn't seem to be worth it. too many precision issues or something. tbh, just use misc_model, but then this is q3bsp that I'm talking about, where that sort of thing is possible. 

why don't you have the relevant items .think and call checkclient()? That's certainly not too slow for every monster in the level to call ten times a second. 

ohh yeah, actually that makes way more sense.
checkclient is pretty quick since it's a built in and uses pvs. 

you'll have to filter newly awakened monsters, because they count as clients for one frame to propagate aggro through crowds, but that's simple enough. 

sounds like a pretty good solution. 

I have finished the mr.big model, a rocket jumping, and heavy weapon entity.
Looking in the hknight.qc for the magic to give the gun a "spread" fire action, and in the dog_leap routine for the rocket jump.

The heavy weapon now results in such a damage that even its own entities get killed when placed in the same surounding.
I thought there was a line of code in the ogre.qc that provided this behaviour, not killing own enemy.

Also
SV_startsound:not precached.
How to avoid it? 

SV_startsound:not precached.
you forgot to precache a sound you're using, check all the sound() function calls for any you missed.

not sure about the self damaging, that could be many things. the most obvious thing to check for me would be that you are passing the right entity for the ignore argument in t_radiusdamage. For example, usually it's self.owner, so make sure you set the missile's .owner field correctly. 

thanks necros. I did check the sounds, but strangly only the second monster's call gives the warning.

For convienence, here 's a testmap for MrBig. The qc is included. 

it's the sight sound. that's the only sound that is played outside of the monster's qc file... check ai.qc for the SightSound() method to see which sound is being played. 

Searched the qc.file, but what I find is in void() FoundTarget, what I believe as local float rsnd;.

Is that the spot for SV_StartSound<q/>?