Teleport glitter, such a nice name for it. I thought it was possible to do this like the explosions, but that's not the case, spawn_tfog will always put them at the origin. This is because spawn_tfog is a function with a parameter in the QC, it's defined as
void(vector org) spawn_tfog. Use will always pass a null parameter to this, the value '0 0 0' for a vector.

However, this same thing actually allows us to get lightning beams working! I'll detail the trick first, then explain how it works. You need something to trigger the lightning, lets say a trigger_once with target l1 for simplicity's sake.

Make an info_notnull with these keys, doesn't matter where it is

targetname l1
use FireBullets
v_angle 'x y z'

where x y z is the angle you want to fire the lightning at.

Then make an info_notnull in the place you want the lightning to start with these keys.

targetname l1
use W_FireLightning
ammo_cells 9999999

This fires the player lightning attack, so it does damage, and has a 600 unit range. Each time the lightning is fired it uses one cell from the ammo_cells count, and it won't fire with none, so set it nice and high if you don't want a limit. The most important thing is that the FireBullets entity is one entity higher up in the maps entity list than the W_FireLightning.

How does this unlikely thing work? Well, W_FireLightning fires a bolt along the vector v_forward. The firing thing pretty much works like any other info_notnull does, the only problem is this v_forward vector. v_forward is usually set to the player's facing duing player functions, so we need to find a function that sets it for use.

This is where the other entity comes in. It calls FireBullets. How is this safe? If you look at the FireBullets code you might notice it has parameters (float shotcount, vector dir, vector spread). Luckily, all these values are null, so the shotcount is 0 and it fires nothing. Luckily before it fires it aims the v_forward vector along it's v_angle. The order in which the entities are spawned is vital, becuase that's the order they will run their 'use' functions when they are triggered.

Wooo, that took a while. Ok, for a little bit of fun, how to make a trigger that will be triggered by anything that touches it, not just players. This includes everything from rockets up. I know somebody wanted this in mapping help a while back, but I only figured out how to do this today. Make a brush with class info_notnull and keys

think InitTrigger
nextthink 0.1
touch multitrigger

and any of the trigger_once/trigger_multiple fields you like. Two caveats. One of them is about sounds. The "sounds" field won't work, but if you set the noise field to a sound precached already then that will play. The second one is this trigger is a bit dangerous. Don't give it a message or you'll end up crashing the game if a non player triggers it, I expect. Also, the activator will always be world, so it may not trigger everything right. Of course, activator would be player otherwise, so anything that relies on that probably would be inappropriate for a trigger activated by anything.

Ok, done for now. Have fun 

Thanks for posting the respawning items hack. I wanted to ask you about this yesterday but I didn't want to impose.

I now have two ways to build a functional healing pool, and one way to build an ammo generator. Thanks again. 

Make an info_notnull brush entity and give it values like this:
"map" <mapname>
"use" "trigger_changelevel"
"touch" "SUB_null"
"solid" "0"
"targetname" <name>

The trigger does nothing until it is triggered, upon which it becomes a trigger_changelevel.
Works by calling the actual trigger_changelevel spawnfunction in the use field, which normally crashes with most classes because they usually precache stuff there, but trigger_changelevel doesn't. 

Premise: Set a monster's firing function as an info_notnull's use function to make it fire monster missiles of your choice.

Problem: All the monster missile functions require the self.enemy field to be set to the entity for which to aim towards.

Solution: Entity references in quake is really just a number indexing the entity in edict list. The player will always be entity 1. If you set the info_notnull's "enemy" field to "1", you'll get a entity that fires a missile towards the player when triggered. I'm sure you can, by looking through the edict list when you have completed the map for release, figure out what the entity index for any entity will be in your map, and so make it aim towards any entity.
For example, in the map I uploaded below, all the info_notnulls have "enemy" "7", which I found out through the edicts list is the info_player_start in this particular map. I think that your results may vary on this, as it could be that editors like to save the entity order in not exactly the same way every time, and also other uncertain factors.

Examples:
"use" "OgreFireGrenade"
Fires an ogre grenade towards self.enemy.

"use" "CastLightning"
Shoots a shambler lighting bolt towards self.enemy.

"use" "hknight_shot"
Fires a single (just one) hellknight magic missile towards self.enemy.
Requires a hellknight to already be present in the level for the precaches to work.

"use" "ShalMissile"
Deploys a voreball that starts seeking towards self.enemy. I had some problems with this when it collides with un-alive things. Looked like it just disappeared without a trace.
Requires a vore to already be present in the level for the precaches to work.

"use" "Wiz_StartFast"
"health" "1"
Fires two wizard slimewotsits towards self.enemy. The health field is required because the actual function that fires the missiles checks if the scrag is alive first. (See below.)
Requires a scrag to already be present in the level for the precaches to work.

"use" "Wiz_FastFire"
"owner" <entity-ref>
Fires a wizard slimewotsit towards self.enemy. The owner field is required because this function checks that whatever spawned the missile (usually a scrag) still is alive first. Thus the owner field here must refer to an entity that is "alive". That is, it must have a "health" field set to anything non-zero. "owner" "1" should work, as that refers to the player, which usually is alive.
Requires a scrag to already be present in the level for the precaches to work.

"use" "boss_missile"
Fires a Chthon fireball towards self.enemy. This requires that self.enemy is alive (has health), or else it will start seeking after the player no matter what you intended. I tested this with a info_player_start as the target, and it worked once I gave it "health" "1".
Requires a monster_boss to already be present in the level for the precaches to work.

The result:
http://czg.spawnpoint.org/stuff/ogretest1.jpg
http://czg.spawnpoint.org/stuff/ogretest2.jpg
(Sadly didn't manage to capture the shambler bolt)
Map file:
http://czg.spawnpoint.org/stuff/ogretest.map 

Kindly provided by John Payson and Fat Controller.

http://www.planetquake.com/fatty/default.asp?opinion=johnpayson 

That is genius czg, I'd triedsomething like this before, but that's much neater than my method was. One especially useless thing you can do with monster functions is add them to creatures that don't have that kind of attack. So you can have a knight with missile attacks by adding the function to the th_missile of the knight. Wiz_StartFast and ShalMissile work alright, CastLightning is a tad unfair, sham_magic1 is a bit better but causes wild animation frames after the attack until it goes into pain or melee attack.

You could combine this with additional hitpoints and possibly quad to make a boss monster type thing out of a knight. For those who've never seen it, adding a key of "armortype 1" and of "armorvalue x" gives a monster x additional hitpoints. Quad is accomplished by setting a key of super_damage_finished to something overly large, like 9999999. However, without some kind of visual cue your boss monster is different to a regular knight, it's not really fair on the player. Maybe you could get away with it if you used some of the effect flags, but I'd still think of this mostly as something to mess about with for fun, rather than something you'd want to include in a released map.

I've still got a few of these things I've not written up, I'm gonna look to making an example map for one, then I'll see about posting the details. 

About the "use" "Wiz_FastFire" bit, there's a remove(self); call at the end of that, so the info_notnull will be gone when it fires once. It can't be fired multiple times.

About the setting "enemy" "1" thing to make them target the player, this obviously won't work with coop, as they'll only target the FIRST player. Also I guess when other players connect they'll be added to the end of the entity list (?) and thus be impossible to find the index for. (Might join at different times, before/after certain events that create/remove edicts.)

CastLightning is a tad unfair
The shambler lightning bolt could be used for traps, like having it fire across a hallway once every second so the player has to time a jump across. And also just for decorative purposes, as and alternative to the event_lighting setup. 

that fire off Shambler bolts? I am in evil mapper heaven. 

"classname" "monster_dog"
"armortype" "1"
"armorvalue" "999999"
"super_damage_finished" "999999"

/me imagines a monster_dog chasing the player around a level until the player finds a weapon and ammo cache 

:D 

http://www.planetquake.com/fatty/default.asp?opinion=johnpayson 

In case some people haven't heard of this, there's an old trick discovered independently by various mappers to get more complicated logic into your entity triggering.

The basic concept is to create some box room off in the void, and put a spikeshooter, a func_door, and a shootable button in it. When the door is open, the spikeshooter will shoot the button, so if this "logic gate" will pass the message on to whatever the button targets. If the door is closed, the spike will hit the door instead of the button and the event gets blocked.

Use this the way you'd use an "if" statement in a scripting language. 

I probably wasn't clear on this when I said it, but I just meant CastLightning is a tad unfair when you give it as an attack to a knight. It fires instantly without any warning or charge up so it's impossible to avoid. As it's own entity I'm sure it's fine. 

All good stuff so far...there's one I'm wondering about though, maybe someone could explain it.

Remember zippie's 100b map 'stamppot' ? There was a teleporter you go through and you end up disoriented and your movement is all weird. I could be wrong, but I think it was more than just clever brush work/player placement. 

clipping into a HOM there (<--spelt it right that time) 

you didn't spell 'your' right :p 

... a 'crazy progs tricks' themed speedmapping session! 

"angles" key on the info_teleport_destination IIRC.
Either "angles" or "viewangles" or something like that. 

my friend, and years from now I'll be a spelling God! 

The first n entites are always reserved for players, where n is the maxplayers of the current server. So if you're running a 2 player coop server, an entity with "enemy 2" would target the second player. Not much use though, as in a single player game an entity targetting entity 2 is gonna be shooting at the origin - as the next entities after the players are bodyques, used to mark corpses when players die. As far as I know, there's no way to hack in any co-op only behavior, and even if you could, you certainly would have difficulty customising the map for the number of players.

That said, I'm looking at one tiny prospect in a function in items.qc for causing events to occur only in coop, but don't hold your breath. 

This is one big hack, it combines quite a lot of stuff towards one end, and one of the steps is extremely unlikely. It uses the player lightning hack, the logic gates and the use function. But what it does is creates a trigger that will be fired at the start of the map if it's single player, but will not be fired if the game mode is coop(or deathmatch). It's not as good as having a coop only flag, but it would let you alter the gameplay if it's being played as coop.

Ok, so, an overview of what's gonna happen first. We will build a logic gate to test for coop. The logic gate will not use any actual gates, it will just be a shooter and a shootable button. However, rather than use a regular spikeshooter, we instead use an info_notnull based on the player lightning shooter that will only fire if the game is not coop.

Ok, so, the stuff. Build a room away from the main map with a shootable button at the end. Give it a low amount of health, no more than 30hp. Give it a target of notcoop, this is the trigger that will be fired if the game is not coop : - )

Now for the more complicated bit. Make an info_notnull with these fields

targetname cooptest
v_angle x y z
use FireBullets

Then make another info_notnull straight after that with these fields

targetname cooptest
use W_FireLightning
nextthink 0.3
think CheatCommand

The second info_notnull should be in sight of the button, and the v_angle of the first entity should be the angle the second one needs to fire at to hit that button.

Ok, one more entity is needed to trigger cooptest, but it's important that this doesn't happen until the lightning info_notnull has had time to run cheatcommand. So the easiest way to do this is with another info_notnull, with the following keys

target cooptest
nextthink 2
think DelayThink


And that's it, not bad for four entities by my reckoning. Oh, you wanna know how it works? Ah, that's a good trick. CheatCommand is none other than that family favourite "impulse 9". Which happens to give the entity 200 cells, when before it had none. W_FireLightning requires the entity to have cells before it will fire. And in coop, impulse 9 doesn't work, so the lightning remains without any cells and doesn't fire. Seems I was a bit pessimistic earlier... 

A tried adding "effects" "1" to a func_door to what I thought was no avail. Instead, all I got was a glowing swarm-of-bees around the map origin. What was REALLY strange was that this "swarm" seemed to be responding differently to the various sounds ocurring on the map, i.e. shotgun blasts, rocket explosions, etc. O_o

P.S. Only in Fitzquake though :) 

A brush based model such as a func_door will always have it's origin at the centre of the map when it's in it's natural position - ie the position it was in when you built the map. If it then moved down 64 units when it opened, then the centre of the swarm would also move down 64 units. So I'm guessing the effect was just being applied to the origin of the entity, which happens to not be anywhere near the door.

What you could do is move the door so that it's over the origin, then use an entity editor to move the door back to where it should be, by giving it a key of origin x y z, where x y z is the displacement to move it back into position. You may have to perform further editing to make everything work right. For example, when I just tested this I needed to add a trigger_multiple to set the door off, as the automatically generated trigger still lay at the origin. Things like not linking multiple doors may also help.

As to the weird reaction of the particles, I also saw this in fitquake080. I suspect that the swarm is reacting to other things that create particles, like gunshots/explosions, rather than the sounds, but something odd is happening. 

the particles are coming FROM INSIDE THE LEVEL!!!111 

woah, rockage! ^_^