thanks!!! 

Leaks: Are these a big deal? should I be aiming to have no leaks in a level? can I just copy paste and rotate non-player area detail stuff and not worry too much? are leaks mostly a problem in places where the player can actually go? 

Leaks are pretty bad. You don't want them ever. Your map must be sealed much like a water-tight container.

more here: http://www.quake-1.com/wc16a-tutorial/speed.html 

Don't worry, there should be pointfile after compiling your map. When you open your map, typo "pointfile" to your console and after that "developer 1" (1 = on / 0 = off). Then you should see White lines bouncing somewhere in your map. Try locate area where that Line goes ovet your map's intented boundaries and try figure out how to avoid it no go through for example some corners, maybe light is too near some possible leak area etc. Others correct me if I am wrong, but that is how I can visualize it (don't know about technical terminology) 

Some (I know TB2 does, I don't have experience with any others) editors allow you to visualize map leaks in-editor, which is nice since you can fix it while looking at it, decreasing iteration time. Otherwise, what NewHouse said is fine.

With modern computers, speeds in Quake levels are rarely an issue. But not everyone has a modern computer, and some people enjoy being able to play Quake on their older PCs regardless of whether or not they have a "better" machine available, so it's important to avoid leaks or poor sealing.

I'm not sure if it's actually worse than just having a straight-up leak in your level or not, but one thing that people sometimes do to avoid having to seal leaks is to encase their entire map in a giant cube of skybox. This is a very bad idea; yes, you can run .vis on your map, but it will take much, much longer, and besides that, you're still not addressing the root issue, which could end up having significant effects regardless of whether or not your map is "sealed". 

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