Since there are many new mappers here - I recommend doing some research on basics of compiling a map.
may be a starting point. BJP's Q1Tooltips
and his Vis readme
contain some useful information for troubleshooting and general knowledge, too.
I'm posting this, because in recent releases I noticed some levels were leaking and/or unvised or only fastvised, and that may have been due to a lack of understanding and possibly the uncritical use of compiling GUIs or in-editor scripts. Maybe run each of the tools in a command prompt window at least once to see what happens, or look for log files in the corresponding directories, e.g. qbsp.log. I'm critical of GUIs and script for reason that there's a risk of them swallowing important warnings and error messages which then go unnoticed for the unaware user.
On leaks/VIS: the basic idea is that a map must be air-tight, completely sealed off to the "outside", otherwise QBSP will report a leak. Another way to recognize a leak is by noclipping outside of the level, and if you can't see the interior but instead the backsides of the outer walls, you know something's wrong.
In this case, QBSP will generate a .pts file
. When placed alongside the .bsp in the maps directory, you can use the pointfile console command to display a dotted line leading from towards the leaking spot. Some editors can load the .pts file as well. When located, it can be plugged; usually it's obvious and straightforward, though occasionally it can be quite obscure. More often than not a map has several leaks, so you may have to repeat the process.
Once the map is properly sealed, and only then, QBSP will generate a .prt file. It contains information on the vis portals the level is made up of, so to speak. This file is required for VIS to calculate the visibility of the world ('what is visible from where', so the game doesn't have to render the whole map at once)- without it, VIS cannot run.
There are two command line switches for VIS that matter here: -fast which does a quick but sloppy calculation used for testing purposes, and -level 4 which runs a slow and precise calculation = the one you must use for the final release. Depending on the size and structure of the level, this can take a while (although with multithreading tools and detail brushes, it's not much of a problem these days). A fullvis is important. Don't listen to people saying it's not because modern systems can handle it and so on!
To get an idea about how it works, you can check in game: using Fitzquake or Quakespasm, load one of the original maps and type r_showtris 1 in the console, then walk around and see how stuff appears and disappears if it's sufficiently blocked by other geometry.
By the way, the .vis file is just an autosave of the current state of the VIS process (because you can stop and resume it if necessary). After the job is done, the file is useless. Don't include it in your release.