Nice one! 

In theory you could go higher framerate and double it again for the framerate hack. just need to add another 2 layers of meshes switching at .25 and .75 seconds delay. I think I will have to give this a go at one point as well :) 

Neat trick I found. If you place a trigger push with a velocity of 100 right in front of a teleport the player won't be able to use it (if its angles are right, you could always suck the player in for a neat trap!). If you then place a trigger_monsterjump a hair bit in front of it and give it the same forward velocity of 100 but an up velocity of only 1, it will negate the push and let the monster teleport. You could reinforce the concept by putting a func_illusionary in front of it with a unique teleport texture. If you want to make the teleport useable later such as after a fight, you can killtarget the trigger_push and the func_illusionary. 

Sort of a neat trick as opposed to TE_TELEPORT effect at either side of the ent being teleported is if your engine has a .alpha field you could "fade" him out while non solid, hijack his think to be the fade function until hes perfectly transparent, then transport him, and fade him in using the same function in reverse. If done with the right timing it could look pretty good, and you could throw in a EF_BRIGHTFIELD at the end for maybe the last few frames while transporting, and the first few while "rematerializing"....

If the engine has EF_ADDITIVE for blending, I think it looks even better. 

info_notnull

targetname movingteleportdest1
target path1wp1
speed 200
avelocity "100 200 300"
solid | 0
movetype | 7
use train_use
nextthink 0.2
think func_train_find


Borrows code from the misc_teleporttrain to create a moving teleport destination that is invisible. Use in combination with a monster teleport box whose targetname is movingteleportdest1. Give a nice path above an area to drop in monster in a randomized locations. Put multiple monsters in the same long teleport box with only one teleport and you can cut down on trigger_teleport requirements, and add randomization. 

make sure something targets it or else it won't move.

As an extension of this idea, you could have a teleport that changes destination by having it target this entity and giving the 2nd path_corner a wait of -1. 

You can teleport to monsters, even dead ones. :) 

 

So you give a grunt 'effects 8' and when he dies, he trigger spawns a fiend into his own location. 

Too bad you cant gib corpses this way... have a grunt spawn a zombie or fiend in a spray of gore! 

Spawn a zombie, then after 0.05 seconds spawn a fiend at the zombie's position.

Best way would just be to use qc though so as not to inflate the monster count. 

Would be unwise to spawn large monster from small monster due to bbox Size difference. 

Yeah, qc would be good again to check for !walkmove. 

So, which hack should I write up next:

a) A trigger which randomly selects between triggering "event_a" and "event_b"

or

b) A trigger_counter which can be reset and used over and over again.

I mean, eventually I'll get round to both, but which one should I do first? 

a, though b sounds more interesting. 

i can do a) myself already VERY hacky, i'm most interested in hearing your solution. 

Do b) 

but im sure there is a much more clever solution to it. 

Preach us probably accessing the video buffer for the screen and using the pixel colours as random numbers with 3 info_notnull entities. 

 

// Try it...jump around on any map

void () test_touch =
{
if (other.flags & FL_CLIENT) bprint ("OUCH !n");

};
void () worldspawn =
{

world.touch = test_touch; 

From what I can see, there's been more discussion about the randomised trigger, but more explicit votes for the reusable counter. Since we live on a democratic message board, we will ignore the prevailing enthusiasm and go for the winner instead.

I've been playing around with the idea over the past week, trying to come up with the simplest implementation of a reusable counter. I think I'm basically there now, but one of the features requires a logic gate, and a flaw in my previous article on those has become apparent, so I will fix that first, and then the new hack will follow. 

Another two-fer! 

So the fixed logic gates are up at

https://tomeofpreach.wordpress.com/2013/05/13/new-logic-gate-design/

The updated portion is highlighted in yellow. I've also updated the example .map at http://www.quaketastic.com/files/single_player/maps/gates.zip both to incorporate the update to the article, and to make the example map playable. All four gates are hooked up to example entity systems and can be tested in-game.

Now for the new stuff...
https://tomeofpreach.wordpress.com/2016/02/21/reusable-trigger_counter/
Not only featuring reusable triggers, but also triggers which you can interrupt to reset during their count.

Bonus content: What went so wrong in the original logic gate post to make Preach miss out a vital entity? I often use a "clean" copy of the QC source to test things out. Unfortunately, this clean copy is not quite 100% identical to the basic Quake source, and W_FireAxe is one place they differ. My "clean" version has a call to makevectors which the original Quake progs is missing. This doesn't affect the player code which has some redundancy, but the axe hack entity is not so lucky and started firing in a random direction. The changes to the article work around this. 

When you ask a question and then answer it before anyone had a chance to say something, that's usually a rhetorical device. Not today though, I just happened to crack the puzzle I set myself last time, and made the reusable counter work without a logic gate. Read the follow up article here:

https://tomeofpreach.wordpress.com/2016/02/23/more-reusable-trigger_counter/

Still not enticing enough? Well, the post links to an example .map file, so you can copy-paste the hack without the need to understand it! You want more? Well, the article even invents the anti-counter - an entity which acts like a trigger_relay until you've used it n times, rather than one which only acts like a trigger_relay after you've used it n times. If you want a crusher or trap the player can only activate a few times before recharging it, this does the job.