I decided to play around with the vertex editor in GTKRadiant 1.5, and I noticed that there isn't really much freedom to move verticies as I saw in comparison with 1.4

This just looks weird: http://i.imgur.com/Z6kO8P4.gifv

Anyone know why this is? 

this has always bothered me. wonder if there's a way around it? 

but I thought there was a way to select two controlpoints by keeping the leftmouse down and surround them. 

installed Radiant to see.
It should be: press shift + left mouse surround.
Then both controllpoints move smoothly. 

Yeah it looks gash, but what you are trying to get radiant to do is undefined.

Radiant does not create new planes or split brushes automatically in order to maintain brush validity after vertex manipulation, so in order to keep the brush valid it must move other plane points - and the results are about as useful as you would imagine.

Trenchbroom is a bit smarter in that it creates new faces as required. To be honest though I'm a diehard Radiant fanboy and get by with the clipper and edge manipulation, using vertex manip only on certain shapes where I know the results will 

"...where I know the results will be predictable" 

If you build an entity entirely from clip brushes it doesn't usually work - I remember it being something to do with the bounding box not being enlarged by clip brushes. The workaround at the time I learnt this was to sandwich the clip brushes between thin regular brushes on opposite sides, so the clip lived within the boundaries they formed. Is this still state-of-the-art when it comes to making clip brush models, or is there some new compiler which corrects this automatically? 

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.