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! ^_^ 

This thread's almost fallen off the page, so I thought I'd put a couple more things on here. The first is how to make a non static entity with a model. This is like the func_illusionary trick, but because the entity remains dynamic you can remove the entity later. You can also set angles on it, something neg!ke said wasn't possible with a func_illusionary.

The downside is that you have to mess about with modelindex to make the model display correctly. Make an info_notnull with these properties:

mdl progs/player.mdl
modelindex n
think SUB_regen
nextthink .3

Where n is the modelindex of the model you want to load. How does modelindex work? As the quake engine precaches models for the game, it places them into a numbered list. The modelindex of a particular model is it's number on this list. Index 0 is the null model, index 1 is the world itself. The next models will always be the brush models from the bsp, then the models precaches by the QC in the order that the models are first precached by the spawn functions.

This all makes it a big pain to work out which model has which modelindex. I'd recommend running the map through darkplaces or aguires engine, as these have commands that will display the list of models along with their modelindex. Be warned, the order in which models are precached may change if you alter the entities in your map. Also, different skill settings may have a different modelindex, so be careful.

On the plus side you can set all the things like frame number and angles without a problem, and even give the same entity a use function if you desire.


Ok, now for overwriting paths. What this does is allows a one time alteration of the path of a func_train. You can't toggle it back, and you can't switch it again to another path. But someone might be able to find a use for it.

Ok, here goes. To make the explanation simpler, we are going to alter just one point on the path, you can expand this to replacing multiple points and doing more complex things quite easily, it just takes more fiddling with triggers. Make a path of path_corners with targetnames p1 -> p2 -> p3 -> p4 -> p1. Then make the replacement p1 path_corner, making sure it is further down the entity list than the original p1. Give the replacement p1 the same targetname and target.

At this stage what should happen if you run the map is that the train goes between the first four points, the second p1 path_corner will be ignored. Now for the trick, add a key to the original p1 of

use s_explode6

Now, when you want to change the tracks, just fire a trigger that targets p1. This will run s_explode6 on the original point, which removes it in 0.1 seconds. The new p1 has no use function, so it remains. Why use s_explode6 instead of SUB_Remove? Well, just for neatness really, it's possible that you'll be triggering p1 from a touch function, and removing entities during a touch function can be dangerous.

That's the basic idea, anyhow, but you can do quite a bit with it, it's mostly how you set up the new p1. For example, there's no reason the new p1 has to target the same entity as the original p1, it could go p1->p1a->p1b->p2 and then back through the original path. You could choose never to return to the original path, do something like p1 -> q1 -> q2 -> q3 -> q4 -> q1. And then you could pull the same trick again with q2, switching onto yet another path...

You might be tempted to try this with monsters following paths as well. In theory this should work, but there is one problem. If you remove the point the monster is currently heading for, it'll start heading for the world origin and won't ever resume it's path. This doesn't happen for func_trains as they calculate exactly how far they have to move as soon as they start moving. Monsters have to hit the trigger of the path_corner, and constantly correct their course using the navigation AI. Bit of a shame, but there's not as much use for changing monster paths as func_trains offer anyway. 

How many of these tricks will become invalid when loading the map in a custom progs.dat, such as Nehahra or Zer? That's perhaps the only thing that might stop me from using some of these. 

It's hard to say exactly how many would still work with a new progs. Potentially all of these could be broken by a new mod, if it was written correctly. But I'd say in the vast majority of mods, the vast majority of tricks will work. Like the use trick would stop working in only two circumstances; the mod completely rewrites the entity triggering system(which would mean you'd have to map differently for it anyway), or the mod adds a use function to the entity you're trying to use. The former would really only occur if it was some total conversion thing, and the latter is unlikely to affect info_notnulls.

I'd say that probably all of these tricks would still work in zer, and quite a lot of them in nehahra. As a rule of thumb, a mod that just adds content without changing the base stuff should accept these tricks. The more it alters what went before, the greater the chance something will fail, which is why zer should run them but nehahra may not. 

I know QdQStats will break the coop detection stuff, because it allows some of the 'cheats' in coop (for route planning purposes).