I think DaZ has used it in some of his latest Quake videos, for the intro bit. That's what it's intended for! Using it on regular play demos might render unexpected results since it's tuned for slow movement. 

I just converted one of my normal play demos with it and it looks like I'm drunk or stoned playing. 

It was made in response to the now classic january 1st W00tles post! 

That's a very cool utility! I thought he was placing waypoints or somesuch, but this method of doing a flyby camera is way more intuitive and simple! 

Fixed a bug with parsing Fitzquake spawn baseline messages - the program couldn't parse my own jam2_mfx demo so I just had to debug it.

http://mandelmassa.net/quake/demsmooth-1.03.zip 

Mandel, please write Quaddicted a demo meta data extraction tool for 15, 10002 and 666. Something that extracts statistics like kill/secret count, length, completion, skill, maybe even shots fired or distance tracked if that is possible. Thank you! bye! 

I just might! 

In triggers.qc:

void() teleport_use =
{
self.nextthink = time + 0.2;
force_retouch = 2; // make sure even still objects get hit
self.think = SUB_Null;
};

the purpose of force_retouch is clear, but I've always wondered why a teleporter had to have its nextthink set just to do nothing. Is that more obtuse secret qc behavior related to how force_retouch works? Or just cruft? 

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.