How do i know how to align my pathcorner entities? At the moment im using trial and error to correctly place my path corners, its time consuming! 

Knowing the orientation of East in Quark it takes the right lower angle. 

I could swear the path_corner must be at the lower left corner of the bbox on your pic Maddox. 

Thanks! 

In that (sensitive) case my east lies downwards. 

Whats the best way to split a brush? I've used the C tool and sometimes it splits a brush, other times it chops part of the brush off. What do I need to do in order to consistently split the brush?

Thanks 

when extracting corners the path_corner stays the same!

@-naitelveni: there's a nice trick you can use to enlighten your windows with this func_train.
Use a window as func_train, and add one path_corner some units before it. Give it the same target and targetname, and wait -1.

When starting the game the window has hardly chance to settle and will turn forward.
If you place a light just before it the front will light up, but as it is replaced now it looks as if the light comes from behind.
A little light before the wall will give it a small shine.

editor
map
screeny 

it's in the help document
help->Shaping Brushes->Clipping->Clipping Modes 

Check this post by Pritchard for a better understanding of the clipping tool: http://www.celephais.net/board/view_thread.php?id=60908&start=2389 

Thanks topher, I should have checked that help file out, very handy.

I'm wondering about overlapping brushes - do they "plug leaks" say if I copy and past a bunch of brushes and rotate them so they're all intersecting, then drag a sky brush down to their top most point (and say they intersect with the floor brush) would these overlapping brushes cause a leak? are overlapping brushes generally considered a no-no? 

ah...
i don't know yet.

and put a screenshot i didn't understand either ,

i will ask the last question as well.
are overlapping brushes generally considered a no-no?

i think that overlapping brushed don't cause leaks, because leaks are holes. i don't know if they affect the lights.

i'm just cutting brushes, resizing them, merging them, etc,, for now. 

You can overlap brushes, some things benefit more from being clean cut but do not be concerned so much with that. Just be aware of z-fighting with textures.

Clipping is the best way to split a brush in TB. You can press CTRL+ENTER to cycle clip modes. 

Leaks are caused by either an exposure to the void or an entity with its origin in the void.
Overlapping brushes aren't very good practice, mostly because of Z-fighting and increased compile time. It's better if you can avoid it. Doesn't really matter if they're made func_detail though since these are ignored during compile. 

Overlapping brushes aren't very good practice, mostly because of Z-fighting

Doesn't z-fighting only happen with moving brushes (doors & plats) that move to the same coordinates as other brushes? Surely the compiled .bsp doesn't "know" if two world brushes have their faces on the same plane, because what texture is displayed gets resolved during the compile process.

Sorry, my terminology is probably all wrong, but hopefully you know what I mean... 

Go place two brush inside one another, each with a different texture. Compile it, run it in game, and report back to us with your findings. 

I've done it countless times with no ill results.

From a post by necros from 2010 (http://www.celephais.net/board/view_thread.php?id=4&start=10212&end=10212):

i don't know why, but overlapping brushes will cause zfighting in newer engines like q3 and d3. in quake, qbsp will manage to remove overlapping WORLD brushes without any issues. (overlapping func_ or other visible bmodels WILL cause zfighting with other bmodels or the world).
afaik, it doesn't cause any problems once the bsp is in the engine.

i'm not sure where we are atm concerning the compiling aspect of overlapping brushes. i don't overlap because i like to work clean, but it's just personal preference.

(emphasis mine) 

Now go do it in Hammer/Source ;)

Its just a bad habit that you wouldnt want to carry into other game engines. 

Had overlapping brushes for the pillar lights at the end hanging from the ceiling. Other than that it was an excellent map. *nit pick* *nit pick* 

Overlap corners, don't overlap faces.

Also, someone actually referenced something I said as advice! Neat. 

Thanks for all the help all.

I've had an error compiling my current build, not too sure what a "non convex face" is, or how to fix it, but it seems to be the problem:

http://imgur.com/EHxdeAB

I tried deleting all the recent brushes I had added, but it still seems to happen. Any idea what I should be looking for so it compiles?

The map is currently wide open, void everywhere - is there a limit to how open a map can be to compile? can I plug gaps / skies later on? or even just make a sky box enclosing the limits of the map? cheers 

"CheckFace: Face with too few (a) points at (x y z)"
"CheckFace: Healing degenerate edge at (x y z)"
"CheckFace: Healing point (x y z) off plane by a"

I have no solution for it but maybe readme and check the related polygon in the map file. 

The map is currently wide open, void everywhere

with surounding walls, bottom and sky. 

Why would you want to seal your map if you're not running vis? I tend to leave the areas I'm working on open until I'm ready to move on to the next one - I only bother sealing them then.

As to non-convex faces, I'm not sure how you managed to achieve that but an editor shouldn't let you create an invalid brush like that. If you do find the culprit, and you're using a modern editor like J.A.C.K. or TrenchBroom, I'm sure the developers would be interested in seeing it...

Which -options are supported by that compiler? I would see if there's any way to get more information out of it. It's strange that it doesn't provide any coordinates in the error. 

Any of you guys know of an extended runic/metal texture set? I've found a few more in kdmtex.wad but more choice never hurts. I'd especially like to find all the different runic tiles in both glowing red and "switched off" versions (id1 is missing some in each variant). 

I always build fully sealed and error free as I go. I only run a full vis every so often, but I like to know the map will compile properly without errors before putting too much more work into it. Fixing problems is the least fun part of mapping and I wouldn't want them to pile up.