Void facing "Polys" (I assume that you mean the faces of brushes that are touching the void here) are ignored however putting a skip texture on them would probably confuse the bejesus out of any bsp compiler.

You might be able to make a big "Curtain" of additional skip brushes that occlude the faces facing inwards. I don't know if that's going to help or hurt you though. 

Once you fill that hole, the compiler will automatically remove all void-facing ploys. This will cut your r_speeds in half, probably. So basically you can't accurately gauge performance until the hole is filled. 

skip on 'void facing' polys will not cause problems, but it unnecessary from a technical standpoint. (some people do that because it's clearer to look at).
The reason is that the compiler completely removes all faces on the outside of the map before the skip removal process runs. 

That makes sense. I wasn't aware of the order of the steps that qbsp does things. I do know that with other "Special" textures that mixing some of them with others on the same brush can be a bad idea. I was just extrapolating from that. 

skip was actually added into the whole compilation process much later on. it's a separate utility that runs after qbsp. 

I've only messed with it once so I'm pretty clueless on using hint and skip outside of knowing what it does in a very basic sense. I was fiddling around with it and made a Quake shadow like you can see in e1m3 (I think) using nothing but a skip texture and func_detail. The func detail made the shadow and then the skip texture made the brushes that cast the shadow invisible.

The latest tools (Tyranns anyway) have skip support built into them so no need for a separate step. 

I'm at the point now where I'm making the level air-tight so I can start testing some stuff (it's not 100% yet but it IS around 99% complete in terms of geometry).

The compiling error I get is in the pastebin -

http://pastebin.com/ZdU0diLA

The only problem is when I look up the the co-ordinates of the error message it's actually pointing to a light entity and not a brush!?

Can lights cause leaks?? 

QBSP doesn't pinpoint the leak precisely, only the point entity closest to it. You can load the pointfile (.pts) in TB or put it in the maps dir and type pointfile in the console, both of which will display a line that leads from that entity to the leak (=where it goes outside the map).

Note that a "leak" doesn't always have to be a hole in the brushwork, it can also be caused by point ents that are placed on the outside. 

Well, I've got some wondrous screenshots here...

http://i48.tinypic.com/27ypkiq.jpg - showtris 0

http://i47.tinypic.com/28ksdns.jpg - showtris 1


I looked at the pointfile and I ran around the map looking for some clue, nothing. Then I typed r_showtris 1 and I found a massive line that is so far away from my actual map that when I try to fly towards it I get "teleported" back to where I started.

I thought maybe the entity was so far away that I would never find it, so I created a selection brush around the whole map and "locked" it, then did a ctrl + a & delete to see if I could delete it that way, no luck though...

Any ideas? 

Which lightmap/texture format was the problem and which one did you patch it to use? 

And I patched it to use GL_BGRA. GL_RGBA is fine, too. 

That's likely a microleak. It's a tiny rift between two brushes that only qbsp can see. This is a result of TB being shit - sorry. I'm working on a fix for such problems. 

Select the brushes where the line passes through and snap their vertices. That might fix the problem. Also note that you can import the point file into TB. See the docs. 

I tried to load the pointfile into trenchbroom but the whole map goes black and all I can see is a very very tiny line that goes on forever, when I try to "unload" the pointfile it doesn't work. It stays black. 

Untill you find the leak you can just box the map and use fastvis. 

btw sleepy: this is likely because my videocard is shit, but if I load point file, it blacks out my 3d view except for 2 yellow lines and I have to load a new map to get it back. 

Thanks, will keep that in mind for TyrQuake.

Hopefully will get a chance to help out with TB a bit more soon! 

When you load a point file, the camera snaps to the start of the line, maybe that's why it looks black? 

Ok, so I decided to load up my map in the latest trenchbroom build (was running version 1) and obviously it said there was a bunch of mishapen brushes etc so I rebuilt them or tidied them up. Did a whole bunch of messing about with stuff, removed the slime (I know it's a portal and I was getting some weird portal messages) and I managed to get it to compile. But it still wont vis...
Here's the pastebin -

http://pastebin.com/dxJu1g1q 

It should give the line # in the .map file where the error resides. So you can just go into a code editor and delete the faulty brush. 

 

you could have provided a link! :P

I found it anyway, managed to plug about 3 holes by setting it to -noents (this has required some serious google research!!) and I reckon there is a whole lot more.
One of the biggest headaches is I found a bunch of curved walls that I have made where I can shoot rockets clean through the wall, in the editor the vertices look perfect.

Oh and my lovely tri-soup rock terrain is also showing up as leaky (after I fixed a bunch of brushes I noticed the leaks were gone but now I can fall through some of the faces, it's like I fix one problem and it creates another!) 

Why not help others by adding to the Quake Wiki with your new found solutions to a problem that you encountered? Your progress with dealing with various issues is exactly what it's meant for. Be verbose and complete. If needed the issue will be boiled down and answers given in following edits. 

This is very likely my fault. It's a bit too complicated to explain right now, but basically, I thought I could get away with how I am treating vertices and plane points. I did a bit of cheating to make the vertex editing in TB easier, but I recently realized that it's not a good idea.

So I have been working on fixing these problems for the last two weeks, but sadly, this whole issue is just a rats nest of more problems. It'll take a bit longer - sorry. 

Some of these problems are definitely my fault, I had left a few holes around but since I am using a generic brown texture on the brushes in these areas I have made it very difficult to spot.
The solution in this instance may be to use a bright pink texture for all my brushes and then just texture the surface on the inside of the map (should make it easier).
As for the vertex problem, are the vertexes handled any differently in version 1 than version 1.05 (ver188)?

quaketree, I have intended on doing a bunch of professional videos for trenchbroom and a lot of plans were made and I sat down with the guy doing the recording/editing and it looked good but we supposed to record the first few tutorials this week and it just never happened.
Starting to think it may never happen.