Doesn't check collision outside of visible area 

Is it possible to spawn a zombie that's laying on the ground by default, and that only wakes up when we touch a trigger, without changing the QC code? 

The best you can hope for in id1 is to emulate it, like E4M3 did. 

What necros said. I remember pushing some scrags with clip brushes once, but they had to be part of an entity made by visible brushes and had to be within the bounding box of the visible brushes. 

If you don't mind it blocking weapon fire, just do a skip textured brush model? 

Would an entity made of just skip brushes work better? 

Trying to understand prog hacks and experimenting with different stuff.
Have few questions.

1. Is there any lists of appropriate functions for 'use', 'think' and 'touch'?
I found .qc files, but how can I know which function can be used where?

2. If I create trigger_multiple and then manually change its classname to info_notnull or InitTrigger it doesn't work.
If I create info_notnull from the beginning, change class to InitTrigger and use same keys and values - it works, but I can't change its size.

Inside map file I can see that first example doesn't have any brush information, only origin which I suspect is wrong anyway - "-64 0 0" while true-info_notnull right next to it has "-1248 352 -288".
Can anyone explain the process of creating "big" point entity?
Using GTKRadiant 1.6.

3. Is it possible to create say healing or other custom/hacked trigger that uses angle(only works when I'm facing specific direction)? 

Would an entity made of just skip brushes work better?

Yes 

qbsp is supposed to calculate the physics bounds of each brush model. The engine fix for this bug would be to ignore the bounds in the .bsp and calculate your own. The tools fix is to calculate bounds correctly in qbsp. The mapper fix is to add a visible brush at opposite corners, hopefully inside other geometry so you don't see them. 

No, I want the effect of clip for what I have in mind. Visibility isn't a problem because I can turn that off with QC, but I want attacks and traces to pass through and only large entities to be blocked. 

Hi DW, I have a collection of posts on my site which answer several of your questions

https://tomeofpreach.wordpress.com/category/map-hacks/

In particular, the following post is a guide to which functions you can/should use:

https://tomeofpreach.wordpress.com/2012/11/18/mid-map-entity-spawning/

and this one deals with building triggers:

https://tomeofpreach.wordpress.com/2013/05/13/build-your-own-trigger/ 

Revisiting that first post, it actually doesn't say as much as I thought it did about which functions you can use.

In a technical sense any QC function can be used. However, if the function takes parameters they will end up uninitialised, which rarely works well, so usually those functions should be avoided.

Which ones are useful is a bit more of a different matter - it's really down to what you're trying to accomplish. The following post has a bit of a guide on how I go about locating a useful function in the code and turning it into a functioning hack:

https://tomeofpreach.wordpress.com/2014/10/07/nightmare-skill-detection/ 

sorry, what i said is not entirely correct. the engine only calculates collision within the bounding box.

so as metl is saying, it can be either side's fault.
the engine is a little lazy on how it decides to calculate collision, but the tool is just wrong in calculating the bounding box.

CAGE FIGHT! 

i don't think it's lazy to trust the data coming from the map compiler. It just turns out to be wrong. 

I can take a shot at fixing this in tyrutils-ericw, or at least add it to the todo list. It might be something that is easy to fix, given a test case. 

Is there a maphack I can do to turn on a dynamic light (much like the power-up glow or weapon flashing) attached to the player, that gets triggered during play and lasts until triggered again or until the end of the map?

I'm mapping for Quoth btw. I know there's a torch powerup available but I'd prefer a pool of light to a spotlight, and I don't want the player to be able to turn it off himself. 

I found your site while searching for info, Preach. Read most of the map hacks articles. I especially liked sad story of info_notnull that thought it is a real shambler 8)
Great info, even though at least half of it is too advanced for me at the moment. Another thing that makes my life harder is editor behavior.
For example, I tried to recreate activated door from Dynamic Entity Spawning and it didn't work (as I described in 2nd question). Well technically it worked, but not in a way it supposed to - activator-button opened door and activated trigger ignored me.

Today I opened my test map and same setup works as it should without me changing anything.
Few other things happened.
All entities with info_notnull and InitTrigger classnames had their position and size reset. Remember I wrote about suspicious "-64 0 0" origin? Well, now it is correct since entity crawled to the center of the world over the night.

As for what I'm trying to accomplish, I had that weird idea of trigger_push that pushes player only while he is facing specific direction. Realized that movement and view direction both use 'angle'. Got confused and tried to make something simpler.

So far I can recreate trigger_push behavior and trigger_multiple with angle, but not mixed together. 

I think that might be a difficult combo to create. One of the barriers is that the "movedir" field is used by both type of entities to determine the direction of travel/activation. The bigger one is that the code which decides if you are facing the correct way to activate a trigger doesn't really depend on any other properties of the entity - it's hard-coded to call multi_trigger.

So if my heart was set on it, I'd probably accept I need to just have a conventional "facing trigger" activating some kind of hacked entity which pushes the player, and can be toggled on and off. I've never seen anyone create a trigger which can be switched on and off an arbitrary number of times before, the "spawn a trigger" was a state-of-the-art trick, but only good for one shot. But now I wonder if there might be a way...

The idea would be to create a moving trigger! I think the door functions are the best bet for this. An important detail is that we get actual instant teleportation if we make set the speed high enough, which will probably save us worries about movetype. Then you have a position far outside the map for the trigger to sit idle, and a target position for it to jump to when triggered. Use the door TOGGLE spawnflag value (32) so it doesn't auto-return and it might just work.

This is just a theoretical plan right now, but if it works then it's a really huge hack idea with a wide number of applications. So when I get a chance tomorrow I'll try to see if it can be made to work. 

hmm, will a trigger generate a touch if it teleports over an entity? (eg: with setorigin) i think you need force retouch? 

"movedir". Yeah, that's what confused me too.
Maybe it still possible if we accept that this trick will always push and trigger using same direction?

I tried to activate different variations of pushing entity and failed. Maybe I'm doing something wrong (still a noob), but it looks like push trigger only works directly and does nothing when triggered by anything except for player. 

It's good to take a look at QC sources to figure out why something is not working.

For example "counter trigger" won't message "Only 3 more to go..." etc. when the activator is not player...
if (activator.classname == "player" && (self.spawnflags & SPAWNFLAG_NOMESSAGE) == 0)

Now I'm looking for some workaround, so monster killing each other can "fire" message in counter. 

Hey DeeDoubleU, this one's for you.

https://tomeofpreach.wordpress.com/2015/11/19/toggleable-trigger_push/

It gets you a trigger_push hack which can be turned on and off an arbitrary number of times. You'll still have to do a bit of the heavy lifting here, useing a conventional "facing detector" trigger to turn it on. You may have to play around with the best way to make this work, some suggestions to try:

* Get rid of the TOGGLE spawnflag, so the trigger naturally returns to "closed" after a short time, and only constant retriggers from the facing detector will keep it in place

* Keep the TOGGLE, but have a trigger_relay which resets it at the same rate that the facing detector is reactivated

* Keep the TOGGLE, and have a pair of overlapping, opposite facing detectors. One triggers to turn the pusher on, and the other facing turns it back off. 

You're next in the queue! I like this hack so much I'm going to use it to fix your problem too! But it's bedtime now so it may take a little while until I get a chance.

TextFish: Have you tried a slient, rapidfire https://tomeofpreach.wordpress.com/quoth/tutorial/info_trap/ targeting the player through the floor? That sounds pretty hacky to me! There's probably a way to create a follow spot in just regular quake using an info_notnull, the effects flags, and the ShalHome function.

It's also interesting that both of you have asked a question which the aside in https://tomeofpreach.wordpress.com/2015/11/18/selective-clipping/ is very relevant to. Who does the spotlight follow if there are no players connected? In coop, which one of the players do you want to give the "3 more to go..." message to? 

Thanks for your help! I already tried few combinations with "enemy" key. I finally got it working. Problem was I forgot to set "wait" ;)

So I have connected enemies to info_notnull, which triggers counter every time enemy dies with "enemy" key set to 1, so it always blames player ;D

Here is an example:
{
"classname" "info_notnull"
"angles" "-0 0 -0"
"target" "counter"
"targetname" "count_enemies"
"use" "multi_trigger"
"enemy" "1"
"wait" "0.01"
"origin" "400 472 0"
}
 

My idea isn't worth abandoning Quoth for and it sounds like the info_trap would be very reliant on the player remaining as low as possible in the map (limiting the use of bridges and multi-story buildings etc.), so I think I'll need to put it on the back-burner until I can think of another solution!