Fix the Map Leak Error: "leaked" When Compiling in Hammer

Q: Does func_detail seal a map?

No. func_detail is a brush entity and is ignored when sealing. Walls, floors and ceilings that close the map off to the outside have to be regular world brushes.

Fix a map leak: what the VBSP message "leaked" means, how to find the gap with the pointfile, and why a giant skybox around the map is not a solution.

Published 7 October 20265 min read

The message **** leaked **** means that the inside of your map is not sealed against the void: there is a path from an entity to the outside. In Hammer, load the pointfile via Map → Load Pointfile, follow the red line to the gap and close it with a solid world brush.

What a leak in the map geometry is

VBSP has to know what is inside and what is outside. To find out, the tool conceptually fills the map with air, starting from the entities. Everything this fill reaches counts as interior. The rest is void and gets discarded. If the fill reaches the void, there is no clear inside any more, and the log shows something like this:

**** leaked ****
Entity info_player_start (128.00 -64.00 32.00) leaked!

The entity named there is usually not the cause, unless it lies outside the map itself. It is merely the starting point from which VBSP found the way out.

The consequences go well beyond that one line. VBSP does not write a portal file, so VVIS cannot calculate visibility. Without visibility data, VRAD only works with direct light. The map often still loads, but it runs poorly and is lit incorrectly. How the three tools depend on each other is explained in the article on VBSP, VVIS and VRAD.

Finding the leak: load the pointfile and follow the red line

Compile the map. When there is a leak, VBSP creates a file with the extension .lin next to the VMF. This is the pointfile.
In Hammer, choose Map → Load Pointfile and confirm the suggested file.
A red line appears in the 2D views and in the 3D view. It starts at the entity from the log and ends in the void.
Follow the line in the 3D view to the place where it passes through the outer hull. That is where the gap is.
Close the gap, remove the line via Map → Unload Pointfile and compile again.

VBSP only ever reports one path. If the map has several leaky spots, repeat the process until the message is gone. You can jump straight to the coordinates from the log with View → Go to Coordinates.

Typical causes

Cause	How to recognise it	Fix
Gap between two brushes	The line runs through a narrow slit, often at corners or angled walls	Align the brushes to the grid until they close flush
Outer wall is `func_detail` or another brush entity	The line goes right through a wall that looks closed	Select the brush and move it back to the world with `Ctrl+Shift+W`
Displacement as the outer boundary	The line leaves through the terrain, downwards or sideways	Put a solid world brush with `tools/toolsnodraw` behind it
Entity outside the map	The log names an entity with coordinates in the void	Delete the entity or move it into the map
Broken brush	Map → Check for Problems (`Alt+P`) reports an invalid solid	Repair or rebuild the brush

Two points are easy to miss. First, only world brushes seal a map. Anything tied to an entity, such as func_detail, func_brush or a door, lets VBSP pass through at that spot. The same goes for displacements and models. Second, what counts for an entity is its origin. A prop can stand fully visible inside the map while its origin sits behind the wall in the void.

Why a giant skybox around the map is not a solution

A large hollow box around the entire map makes the message disappear, because the way out now ends at the wall of the box. The actual problem remains and comes back in a different form:

All the space between the map and the box counts as interior. VBSP cuts it into visleafs, and VVIS has to process every one of them. Compile time rises sharply.
VBSP normally removes every face that points into the void. With the box in place, the outer sides and back faces of your geometry stay, get lit and are rendered in game.
The visibility calculation achieves far less, because areas that would otherwise be separated can see each other through the outer space. The frame rate drops.

So place skybox brushes only where sky is actually visible, and keep them close to the map.

Avoiding leaks from the start

Build the outer hull from simple, large world brushes on the grid. Details go in front of it as func_detail.
Put a solid brush with tools/toolsnodraw under and behind every displacement.
Compile often. A leak that shows up right after a change is quick to narrow down.
On large maps, use the cordon tool to compile only a part and narrow down the area.

If the log contains other messages besides the leak, those are often follow-up errors. You can paste a compile log into the Map Scanner. It detects root causes, follow-up errors and matching fixes in VBSP, VVIS and VRAD logs. You can also look up individual messages in the error database. The article on reading a compile log shows how to read a log yourself.

FAQ

What does "leaked" mean when compiling?

The inside of the map is not completely enclosed by solid world brushes. VBSP found a path from an entity into the void. As long as that is the case, visibility data and complete lighting are missing.

Where do I find the pointfile in Hammer?

In the Map menu under Load Pointfile. The file with the extension .lin sits in the same folder as your VMF and has the same name. It is only created when VBSP actually found a leak.

Can I still play a map that has a leak?

Often yes, but it makes little sense. Without visibility data the engine renders far more than necessary, and the lighting consists of direct light only. A map with a leak is not fit for release.

Does func_detail seal a map?

No. func_detail is a brush entity and is ignored when sealing. Walls, floors and ceilings that close the map off to the outside have to be regular world brushes.