Log is shown below. This is a map that previously compiled fine, on a different computer, and the only changes I've made (I think) are adding a few clip brushes. But I may have been compiling with different settings on the other computer, can't remember. I remember that running with cliptype precise avoided the MAX_MAP_CLIPNODES error on the other computer (not to mention fixing a few other important things.) This is a massive map that I've been working on for 3 years now, so I'd rather not upload it as a problem map if I can avoid it. Maybe I should try some different zhlt settings? Help appreciated.

edit: Also, the line file never enters the map's hull. I'm 99.99% sure this map doesn't have a leak.

hlcsg v3.4 Final (Feb 25 2006)
Zoner's Half-Life Compilation Tools -- Custom Build
Based on code modifications by Sean 'Zoner' Cavanaugh
Based on Valve's version, modified with permission.
Submit detailed bug reports to (amckern@yahoo.com)
--- BEGIN hlcsg ---
Command line: C:\ZHLT34~1\hlcsg.exe "c:\valve hammer editor 3.5\maps\map_cp_0"-cliptype precise -texdata 8192
Entering c:\valve hammer editor 3.5\maps\map_cp_0.map

Current hlcsg Settings
Name | Setting | Default
--------------------|-----------|------------------------
threads [ 2 ] [ Varies ]
verbose [ off ] [ off ]
log [ on ] [ on ]
developer [ 0 ] [ 0 ]
chart [ off ] [ off ]
estimate [ off ] [ off ]
max texture memory [ 8388608 ] [ 4194304 ]
max lighting memory [ 6291456 ] [ 6291456 ]
priority [ Normal ] [ Normal ]

noclip [ off ] [ off ]
null texture stripping[ on ] [ on ]
clipnode economy mode [ on ] [ on ]
clip hull type [ precise ] [ legacy ]
onlyents [ off ] [ off ]
wadtextures [ on ] [ on ]
skyclip [ on ] [ on ]
hullfile [ None ] [ None ]
nullfile [ None ] [ None ]
min surface area [ 0.500 ] [ 0.500 ]
brush union threshold [ 0.000 ] [ 0.000 ]

Using mapfile wad configuration
Wadinclude list :
[zhlt.wad]

49 brushes (totalling 376 sides) discarded from clipping hulls
CreateBrush:
(11.69 seconds)
SetModelCenters:
(0.00 seconds)
CSGBrush:
(5.34 seconds)

Including Wadfile: \zhlt34x86final\zhlt.wad

• Contains 3 used textures, 1.09 percent of map (8 textures in wad)

Using Wadfile: \half-life\valve\halflife.wad

• Contains 253 used textures, 91.67 percent of map (3116 textures in wad)

Using Wadfile: \half-life\valve\halflife_special.wad

• Contains 17 used textures, 6.16 percent of map (21 textures in wad)

Using Wadfile: \half-life\valve\liquids.wad

• Contains 3 used textures, 1.09 percent of map (32 textures in wad)

Using Wadfile: \half-life\valve\xeno.wad

• Contains 0 used textures, 0.00 percent of map (264 textures in wad)

added 80 additional animating textures.
Texture usage is at 3.35 mb (of 8.00 mb MAX)
19.64 seconds elapsed

--- END hlcsg ---

hlbsp v3.4 Final (Feb 25 2006)
Zoner's Half-Life Compilation Tools -- Custom Build
Based on code modifications by Sean 'Zoner' Cavanaugh
Based on Valve's version, modified with permission.
Submit detailed bug reports to (amckern@yahoo.com)
--- BEGIN hlbsp ---
Command line: C:\ZHLT34~1\hlbsp.exe "c:\valve hammer editor 3.5\maps\map_cp_0"

Current hlbsp Settings
Name | Setting | Default
------------------|-----------|------------------------
threads [ 2 ] [ Varies ]
verbose [ off ] [ off ]
log [ on ] [ on ]
developer [ 0 ] [ 0 ]
chart [ off ] [ off ]
estimate [ off ] [ off ]
max texture memory [ 4194304 ] [ 4194304 ]
priority [ Normal ] [ Normal ]

noclip [ off ] [ off ]
nofill [ off ] [ off ]
noopt [ off ] [ off ]
null tex. stripping [ on ] [ on ]
notjunc [ off ] [ off ]
subdivide size [ 240 ] [ 240 ] (Min 64) (Max 512)
max node size [ 1024 ] [ 1024 ] (Min 64) (Max 8192)

SolidBSP [hull 0] 500...1000...1500...2000...2500...3000...3500...4000...4500...5000...5500...6000...6500...7000...7500...7726 (1.13 seconds)
Warning: === LEAK in hull 0 ===
Entity info_target @ ( 894,-2664,-712)
Error:
A LEAK is a hole in the map, where the inside of it is exposed to the
(unwanted) outside region. The entity listed in the error is just a helpful
indication of where the beginning of the leak pointfile starts, so the
beginning of the line can be quickly found and traced to until reaching the
outside. Unless this entity is accidentally on the outside of the map, it
probably should not be deleted. Some complex rotating objects entities need
their origins outside the map. To deal with these, just enclose the origin
brush with a solid world brush

Leak pointfile generated

SolidBSP [hull 1] 500...1000...1500...2000...2500...3000...3500...4000...4500...5000...5500...6000...6500...7000...7500...8000...8484 (1.81 seconds)
Warning: === LEAK in hull 1 ===
Entity info_target @ ( -48,-2896,-696)
SolidBSP [hull 2] 500...1000...1500...2000...2500...3000...3500...4000...4500...5000...5500...6000...6500...7000...7500...7542 (1.44 seconds)
Warning: === LEAK in hull 2 ===
Entity env_beam @ ( -48,-2896,-676)
SolidBSP [hull 3] 500...1000...1500...2000...2500...3000...3500...4000...4500...5000...5500...6000...6500...7000...7500...8000...8500...9000...9366 (2.45 seconds)
Warning: === LEAK in hull 3 ===
Entity env_beam @ ( -48,-2896,-676)
Error: Exceeded MAX_MAP_CLIPNODES
Description: The map has a problem which must be fixed
Howto Fix: Check the file http://www.zhlt.info/common-mapping-problems.html for a detailed explanation of this problem

--- END hlbsp ---

hlvis v3.4 Final (Feb 25 2006)
Zoner's Half-Life Compilation Tools -- Custom Build
Based on code modifications by Sean 'Zoner' Cavanaugh
Based on Valve's version, modified with permission.
Submit detailed bug reports to (amckern@yahoo.com)
--- BEGIN hlvis ---
Command line: C:\ZHLT34~1\hlvis.exe "c:\valve hammer editor 3.5\maps\map_cp_0"

There was a problem compiling the map.
Check the file c:\valve hammer editor 3.5\maps\map_cp_0.log for the cause.

--- END hlvis ---

hlrad v3.4 Final (Feb 25 2006)
Zoner's Half-Life Compilation Tools -- Custom Build
Based on code modifications by Sean 'Zoner' Cavanaugh
Based on Valve's version, modified with permission.
Submit detailed bug reports to (amckern@yahoo.com)
--- BEGIN hlrad ---
Command line: C:\ZHLT34~1\hlrad.exe "c:\valve hammer editor 3.5\maps\map_cp_0"

There was a problem compiling the map.
Check the file c:\valve hammer editor 3.5\maps\map_cp_0.log for the cause.

--- END hlrad ---

Make the line longer.

Try doing a cordon compile of different sections of your map.
and just fly around looking at every nook and cranny.
But try running with -particles 900000 like stu said - make the line bigger.

Map can look perfect, but some times there are 0.5point leaks. I experienced that a few times, usually when stretching stuff and cutting.

the LIN file helps a lot, you should try it.
Also you have some complex stuff in the map, try breaking it down a bit.

like tetsu0 said also, you can cordon compile or use the "big-block method"
which i prefer, to quickly/fastly find the leak.

All that is is make a giant brush and cover up your entire map. cut the cube twice to make 4 equal parts, and remove one corner at a time and compile.

anything inside the brushes will not compile, hence you can narrow down where the leak is originating from.

There are also other things that cause leaks like having an brush-based entity or point entity touching outside the world. Check Tommy14's for even moar things that can cause leaks.

regarding clipnodes:
what i do to gain more clipnodes is to compile with clipnodes -simple, and also, take ANY complicated brush work and cover it in a brush or series of brushes with textured with CLIP. DO NOT make any really crazy shapes textured with CLIP, cuz hammer won't like it and will smite you.

some moar info on clipnodes from again the master, tommy14

Okay, so it was a leak. But in my defense, it wasn't caused by actual brushwork resulting in a hole in the map. The line file entered at a point where I had used a very thin brush to patch the map up. My guess is the engine was excluding or altering this brush in some way. I replaced it with a larger brush and it compiles successfully now, but now I'm running into this error when Half-Life tries to load it:

Hunk_Alloc: failed on 50400072 bytes

I realize that this is supposed to mean I have insufficient memory, but I have 2GB, and it was loading fine on my old 1GB computer.

Also you have some complex stuff in the map, try breaking it down a bit.

By break down you mean simplify? I'm rather proud of the more complex areas of my map. I'll work on adding more clip brushes wherever possible, but I'd really hate to simplify the brush work already present, especially considering that I've seen it in-game before so I know it's not a total impossibility.

DO NOT make any really crazy shapes textured with CLIP, cuz hammer won't like it and will smite you.

I'm glad you told me this. I had no idea it could cause problems. I use clip brushes such that they simplify the clipnodes in the map (I have a fair idea of how they work), but sometimes I make the brushes more complex so that they conform to the space they're filling, rather than just having parts of the clip brush go outside the map. Would you advise the other method?

sometimes I make the brushes more complex so that they conform to the space they're filling, rather than just having parts of the clip brush go outside the map. Would you advise the other method?

Not exactly sure what you mean, can you elaborate a little?

Take all the complex things and turn them into func_walls
everything that's not an external wall, that is.

So pretty much anything with more than 4 sides, or smaller than 32units^2 make a func_wall..

Tables, Chairs, fancy machines, columns, lights....

Idk what is exactly IN your map, but if you send us a screenie of the Hammer view i can give even more tips.

Absolutely what Tetsu0 says is correct.. Like he said, stuff like even simple cylinders or anything remotely complicated compiled as a worldbrush, will make your VIS time skyrocket eons, which is: ='(

Instead of using func_wall, i prefer to use func_illusionary covered with a clip brush(s), to approximate the shape in size of the object. This way, any piece of the illusionary sticking out of the clip brush won't create clipnodes.

If your complex object(s) are out of reach of the players, just make them illusionaries. (no clipping brushes necessary)

Hope we're aren't confusing you. Can't wait to see your map btw! =)

Not exactly sure what you mean, can you elaborate a little?

No, but a picture can:

Take all the complex things and turn them into func_walls
everything that's not an external wall, that is.

So pretty much anything with more than 4 sides, or smaller than 32units^2 make a func_wall..

I've already func_walled everything that isn't part of the hull of the map. I've optimized this map pretty extensively, granted I could be missing a few things.

EDIT: I have more to say about this, but I have to go to work.

Instead of using func_wall, i prefer to use func_illusionary covered with a clip brush(s), to approximate the shape in size of the object. This way, any piece of the illusionary sticking out of the clip brush won't create clipnodes.

If it's a func_illusionary (or a func_wall or that matter) it shouldn't create clipnodes, from what I've been able to gather. I did a few tests, compiling a square room and seeing how many clipnodes it creates, then putting a complex object in it and making it a func_wall: the number of clipnodes were the same. However I'll do more experimenting with your idea.

Idk what is exactly IN your map, but if you send us a screenie of the Hammer view i can give even more tips.

Sure thing. You can't see the entire map, but you get a good idea of the most complex parts:

Hope we're aren't confusing you.

Nope lol.

From your pic, the third method is preferable afaik. In my experience, making funny shapes out of clip brushes can cause weird things to happen. besides, the aim of using clip is to SIMPLIFY the clipping area afaik. (maybe a wizard like Atom or Rimrook can shed moar light on this?)

Without knowing for sure, my guess would be a func_wall WOULD create clipnodes, because it creates a solid surface the player can touch, jump on top of, etc., where an illusionary obviously forms no barrier, so it creates no clipnodes.. (Again, my understanding of all this is pretty rudimentary, so if one of the site wizards could chime in to to confirm/displace this, it would be appreciated ;))

Did you try running clip -simple to see if it helped or hurt you? I found my SC map for map-a-game using too many clipnodes under -precice, but it compiles fine under -simple..

Map looks sweet btw.. can't wait to see it!

)

Without knowing for sure, my guess would be a func_wall WOULD create clipnodes, because it creates a solid surface the player can touch, jump on top of, etc., where an illusionary obviously forms no barrier, so it creates no clipnodes..

Exactly. And thus it's pointless to turn very small brushes or groups of small brushes or brushes that are one unit thick into func_walls. Turn them into illusionaries instead. They're to small to stand on, what's the point of making them func_walls?

It does made sense to me that func_walls would create clipnodes, but that condtradicts the test I did. The assumption I've been working on is that they create clipping in a different way, one that doesn't factor into the clipnode limit. For an eample, clipnodes being created substractively by the hull brushes, then func_walls being added back in additively. Maybe that would be slightly more resource-friendly? Idk, I'm just rambling. Only Gabe Newell and a few other Valvers could probably answer that question.

Anyway, based on what advice I've gotten here, I'm led to beleive that the sole purpose of func_walling small details is to reduce r_speeds. A better way of optimizing, if that is the case, would have to be taking Captain Terror and Mighty Atom's advice and making deatils func_illusionaries and covering them with simplified clip brushes; that would BOTH reduce r_speeds AND clipnodes. Thanks guys, and I'll jump on that.

I'll also try compiling with cliptype -simple when I get around to it.