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). 

having mapped for this game for a few years and all that, i thought it was really cool that there were so many tricks i never knew about. thanks for these-- i already found a use for the respawning items trick. ^_^ 

What do you mean by 'create an func_illusionary entity (=no brush!)'?

In BspEditor, there is no choice but to have a func_illusionary attached to a brush. This is where you can walk through what appears to be a solid wall.

If I use "model" and "frame" anyway, the model does not appear, just the brush. 

The idea is to make a regular point entity, and give it the classname func_illusionary, as though func_illusionary were a custom mod entity. In worldcraft, this causes problems as the fgd file says func_illusionary is a brush class. One way to get round that is to remove the definition of func_illusionary completely, as it has no parameters, and name both brush and point func_illusionary entities manually. I don't know how much of that extends to BSPEditor, but you may want to look at doing something similar. 

OK, so I remove the func_illusionary from the ents.qc and now I can't see it in the editor.

I then create a light entity and rename it to func_illusionary and add 'model' and 'frame'.

I have Qbsp on -verbose and see that a texture is not being found, and when I look at the map file, a texture has been added to the func_illusionary:-

{
"frame" "1"
"model" "progs\player.mdl"
"classname" "func_illusionary"
"origin" "0 0 0"
{
//"0000" "0"
( -8 8 8 ) ( -8 -8 8 ) ( -8 -8 -8 ) NONE 0 0 0 1.000000 1.000000
( 8 8 8 ) ( -8 8 8 ) ( -8 8 -8 ) NONE 0 0 0 1.000000 1.000000
( 8 -8 8 ) ( 8 8 8 ) ( 8 8 -8 ) NONE 0 0 0 1.000000 1.000000
( -8 -8 8 ) ( 8 -8 8 ) ( 8 -8 -8 ) NONE 0 0 0 1.000000 1.000000
( -8 -8 8 ) ( -8 8 8 ) ( 8 8 8 ) NONE 0 0 0 1.000000 1.000000
( 8 8 -8 ) ( -8 8 -8 ) ( -8 -8 -8 ) NONE 0 0 0 1.000000 1.000000
}
}

The actual origin of the entity is not '0 0 0' but I can now see the player model in-game where I set it in the map (not 0 0 0).

If I now try it again with "model" "progs/ogre.mdl", the engine gives an error of 'no precache' of the model for the func_illusionary even though I have ogres in the map.

Does this mean that the engine is seeing the func_illusionary before the ogre is precached, and if so, can I do anything about it without resorting to messing with the progs.dat? 

in the map file a monster_ogre entity must be placed before (are rather above) the func_illusionary.

i don't know about texture thing you said, but there must not be a brush assigned to the illusionary. try to delete the brush and set the { and } accordingly. 

I cut'n'pasted the func_illusionary to the end of the file and then ran Qbsp from outside of the editor (because the editor seems to change the order of things arbitrarily), but still no show :-( 

First off, I don't think that the brush info at the bottom should be there, but I can't say why it appears. Perhaps try deleting all those brush info lines from the map file to make it look like the other point entities then try a recompile. Then again, if it's working with a player model maybe that's what BSPEditor expects.

The precache thing I suspect is fixable. Precaches occur in the spawn functions of entities, and the spawn functions are called in the order that the entities are listed in the map files. So if your func_illusionary entity is higher up the list of entities than the ogres in your map are, then the ogre.mdl won't have been precached yet, even though one would be before the map loads.

So just make sure there's at least one ogre higher up the entity list, and that error should go away. 

I took twice as long as neg!ke to say the same thing, never mind that post 

I'm not sure that this is interesting enough, but I'll post it anyway.

If you have a monster_ogre_marksman next to a monster_ogre, the end result will be 2 ogres that can get mad at each other. I don't know if any map uses this yet (or wants to use it) but someone might find a use for it...

This bug only works, because in the code, the classname isn't changed when it tells it to just put in a normal ogre. 

Didn't you play PuLSaRs Hellbridge recently? :)I think that on this map you can see some ogres fighting on skill 3. 

is it possible to make shootable doors? basically, you shoot the door, and it opens. then after a bit, it closes. ideally, whenever you shot the door, it would open up again -- even if it was in the process of closing.

i want to do something like the doors in q3's tourney4 map (pro-t4). 

You just have to set a health value (5 is in general ideal, i.e you can open the door with axe), and set wait at a positive value (-1 never return)... I think I did this for a secret area door hidden in a wall in my last map... I think other people here could confirm... 

I guess you understood I was talking about func_door fields there... ;P 

thanks! and yes obviously they are teh doors ;) 

What JPL described will work; however, shooting the door while it closes will not have an effect--you can only shoot it while it's closed. You could minimize this problem by giving it a very fast "speed" field, though. 

i just might do that, thanks 

about the trigger that can me touched by anything in #11:

i did it exactly like you said (btw it's multi_trigger), but i couldn't get it to work. in the test map i made it was supposed to just fire a trigger_relay with a message.
there were also some unknown bboxes with that shouldn't have been there and they disappeared when shooting them. they seemed to be related to the touch-trigger. 

If anything that prints a message has an activator other than the player, the message won't be printed to the player.

You can see this at the end of terra5 where a trigger_counter counts the deaths of the fiends and wakes up chtohohothothton and prints some messages when they're all gone. However if you trick the fiends into jumping in the lava, there's a trigger_hurt there that kills them, and then the messages aren't displayed because the activator was the trigger_hurt.
Same thing with the logic gates you can build with trap_spikeshooter and doors in front of a button. You can't have the button print a message because it's activator is the trap_spikeshooter, not the player.

So I dunno if I'm quite following you up there, but if you are trying to prove a trigger was fired by something else than the player by printing a message, you should try something else. (Perhaps a light switching on of a door opening or something.) 

i thought it would be fine if not the trigger itself had the message but some other entity that is fired by it.
i tried it with a light then and it worked.

to have a message displayed, i guess i would have to let it activate another trigger which spans over the entire room the player is in at that moment, or something like that... 

gibs don't trigger it, either.
there goes my idea... :/ 

I am not 100% sure this really does work or not, but I THINK that if you create a func_wall entity that surrounds a monster, and kill the func_wall when the level has loaded, the monster will stay in the same place as if the func_wall was still there, yet be able to see and shoot the player. If the monster has a jumping attack, then if it jumps toward the player, it will come out of the box and act as normal.

I am about 50% sure this works, as I remember doing this when I made apsp1, trapping some enforcers on a ledge. The func_wall may have been made from clips.

I've seen some other strange func_wall tricks used in other levels. RPG used some funny trick in one of his mini Ep1 maps, where there were some nights trapped apparently within func_wall brushes. that acted like statues, but came alive later in the level. I would be interested in how that works, RPG. 

holy fuck, does that work? :o can anyone check? i would, but, alas, no quake. :S

regarding the rpg trick, i think you could do it by using the func_wall with the model set, the killtargetting the func_wall and just teleporting in the real monster.