to make sure u have no leak but clinodes excess, clip some recesses/alcoves in your map, i.e. make less clipnodes (lower the amount which is supported by qbsp), if the number of clipnodes will be lower than critical and you'll still have a leak error, then you got the leak, go seal it. 

So there is something mysterious here: I only added some walls, and in order to test texture alignements, and how it looks with shadows, etc.. I tried to compile the map, and sunddenly, the map leaks, while it didn't before the modifications (and these modifications were not impacting the map sealing...)

Anyway, I will try to add clip brushes in order to reduce ClipNodes (particularly on terrain part), and I'll try to recompile and see what will happen... using your tools tips ;)...
BTW, when loading the prt file in the map, I can see the "point" going throught the middle of a wall... It's something weird because there is no "hole" in the map ! o_O 

Thank you, that's exactly what I'm going to do (see my previous post)... They crossed each other ;) 

like a leak in hulls 1/2. Check the brush and its neighbours and make sure they're aligned. If the leak is in hull 1, you can often verify the leak by walking/falling through the brush.

Btw, it's the pts (point) file you load into the game, the prt (portal) file is used by vis when the map is sealed. 

I didn't be able to walk/fall through the brush... I will check the map this evening (with your "magic" -hull <1/2> option)... Thank for your advices ;) 

Ooops I forgot to mentionned that, If I remember well, leak occured in Hull 2 (reached occupant etc.. after Hull 2 start in TxQBSP...), so what am I suppose to look for now ?? 

can be tricky to find and fix. The first thing I'd do is to inspect the brush and its neighbours where the pointfile goes through the hull. Look for tiny misalignments (zoom in real close), especially in non-axial junctions.

Try expanding or otherwise change one or more of the brushes in all directions to find the culprit. Building with the -hull 2 option may help if there are HOMs in that area but it's mostly useful for finding clipping errors fully inside the map (which don't cause leaks), see also ToolTips. Use the -starthull 2 option to speed up the turnaround time (to quickly see if the leak is fixed; abort if not).

If you can't sort it out, send me the zipped map (no wad yet) and I'll see what I can do. Please also include what compiler options you're using. 

Im having trouble with brushes dissapearing during compilation. they are in the editior (Gtk 1.4) but when i run BSP (treeQBSP v2.00 -- Modified by Bengt Jardrup) i spring a leak! i run BSP after mapconv. perhaps mapconv is screwing up? i donno. 

updating to 2.01 and adding option -q2map, this will eliminate the need of a conversion tool. I doubt that the conversion is at fault though.

From the compiler log, in what hull is the leak? 

i have the opposite problem. brushes that don't appear in the editor appear in the map!
:P 

Turn off editor hiding of func_wall brushes! 

they're normal brushes. :P 

it's some kind of bug in gtkr that makes the editor not load up a brush if it's 'broke' but the bsp compiler must fix the broken brush as it compiles the map. 

You've probably tried all sorts of things to fix it, so pardon me if this is redundant, but have you tried checking it with MapSpy? It's a really great tool that's useful in tracking down bad brushes in any Q-engine based game. 

the problem isn't a large one and only shows up once in a long while, but the next time it does, i'll try it out. it's certainly more efficient than going through the .map file and removing the offending brush. 

if radiant doesn't load it, why don't you copy and paste all your brushes into a fresh .map? 

The leak occurs in hull 0 (i think) That is to say "processing hull 1" comes after the leak warning.

Ill try 2.01. 

guess it was the conversions fault. 

how would that fix anything at all? O_o 

The latest compiler versions have the new Tyrann logic that probably is the main reason for the better result, good to hear it worked for you. 

I think he meant copying and pasting the brushes inside Radiant, and not a text editor. If you can't load/select the brush in Radiant using typical means (i.e. making a huge brush and using Select Partial Tall), then you probably won't be copying it over into a new map and the problem would be solved. However, this would royally mess up all of the trigger/target combos since Radiant likes to rename those when you copy/paste them.

Going back to MapSpy: the way I get rid of offending brushes is to run the map in MapSpy, get the brush/ent number, and then use the Find Brush feature in Radiant to select the brush. Frequently you can't actually see the brush, but it's selected, so all you have to do is hit Backspace and it's gone. 

this would royally mess up all of the trigger/target combos which is why i don't do it. :) i takes ages to fix all of those again, and even after you'll find you missed something.

also, even if gtkr couldn't select the brush for deletion, once i know the brush number, it is simply matter to load the .map file in a text editor, search for that number, and delete it manually. gtkr seems to rebuild brush numbers once it loads or saves the map again. 

knowing how large your maps can get perhaps you have reached a limitation in the format structure of the file as it is read by the editor so it is doing weird things to your map.

Maybe it would be worthwhile to send the map as part of a bug report to the GTKRad team.

If this happens to be the case and GTKR reads Q1 and Q3 map files at different file struct sizes (like Dark Places recognizes no size limits on Q3 .bsp's but there is an absolute 32K one on Q1 .bsp's) then something as simple as converting from Q1 to Q3 .map and reading it into GTKR in that format may help. 

no, it has to do with when you vertex edit brushes.

sometimes, if you create a broken brush by vertex manip, gtkr doesn't seem to 'notice' until you move the brush around. under some circumstances (which i haven't been able to figure out yet) the brush goes from broken but not noticed to full on broken, maybe if you save and then reload the map before getting rid of the unnoticed but broken brush.
*shrug*

anyway, i don't really bother submitting bug reports or anything. nothing seems to come of it anyway. 

I submitted a few bug reports on Bugzilla, and nine months later I got a few notices via e-mail saying the bugs had been fixed.