Vlatitude: Compiling Last edited 5 years ago2019-04-25 11:33:42 UTC

Make map. Compile Map. Play Map. Seems simple, huh? Well, no. A lot can happen along the way: leaks, invalid brushes, too many faces, etc. Plus, you have all of these other options that come with the compile tools: -extra, -fast, -smooth, etc. How does it all come together? What does this do? What did I do wrong? This tutorial is here to help you out, my friend.

First Thing's First

DO NOT use WorldCraft to compile your maps. WorldCraft was designed for Quake levels, not Half-Life ones. Valve only modified WorldCraft to accept the new HL format. It allocates waaaay too many system resources to compiling, which not only slows the compile process, it gives you bizarre errors in larger levels. Use The H.L.C.C (or Batch Compiler; found in our files section) to do all the work. Export the .rmf file to a .map file, then compile as usual. The H.L.C.C cuts compiling times by about 5-10% (depending on map size and complexity, also your computer speed) and it also gets rid of many of the problems that WorldCraft might have caused.

When you just made some minor changes, don't do a full compile. You will save A LOT of time by doing a fast vis. Never use a fast vis on the final version of your map, or it will choke up all but the most powerful rigs if played online.

For single player maps, don't place the info_nodes until you are putting the final touches on your map. Every time you change something in your map, the node grid must be rebuilt. Depending on your computer, the size of the map, and the amount of the nodes it can take a lot of time. This gets annoying when you must rebuild a graph 50 times while you're trying to get a light fixture to look right.

Extra Options

I bet you probably said to yourself: "Self, how did those Valve guys manage to get that looking like that?! I've done the same thing and it looks different!" Its probably just an illusion, or rather, an extra option in the compile tools.

1. QRAD (Quake Radiant Tool): AKA "The program that does all those colored lights.
   • - extra: What this does is make all your lights look cooler than standard lighting. It also adds quite a bit of time to your compile times. Use this on the last few compiles, as your lights sources will double in the process.
   • - verbose: This option tells you exactly what the program is doing. Pretty useful if you want to see how your lights are made.
   • - smooth: Smoothes out all of your corners. Put in a nice number like 80. It does add a little bit to your compile times, so use it during the last few compiles.
   • - ambient r# g# b#: Sets the ambient light level for your map. You can specify the brightness in the red, green, and blue spectrums. I have personally never used this.
   • - bounce #: The value input here will determine how many times light will bounce (refract).
   • -chop #: This sets the size of the light patches. Higher numbers results in lower quality lighting, but can speed up the testing process.
   • -coring #: Sets all switchable light surface intensities less than the inputted number to 0. This helps reduce the number of surfaces affected by any switchable light.
   • -dump: Writes QRAD info to text files.
   • -gamma #: Pre-adjusts the gamma values of the light maps, defaults to 0.5. Higher values result in more contrast and light intensities being cut off sooner.
   • -inc: Saves vary large files that contain the calculated bounce info. If you change no geometry or light positions, you can use this parameter. It saves huge (40+ meg) files which, if you adjust light intensities or your .rad file, are used the next time you run QRAD. This translates into huge time savings if you're only tweaking light values.
   • -lights: Specifies a .rad file. QRAD will look for lights.rad by default in the directory that qrad.exe is run from.
2. Vis
   • -fast: This makes the whole Vis process much faster, but a great deal less efficient. Never use this on a final compile.
   • -V: Verbose mode (print out what's going on).
   • -Thread #: For multiple CPU systems.
3. QBSP
   • -leakonly: Using this parameter causes QBSP2 to only perform a leak test and will output a leak file if one is present
   • -notjunc: If used, t-junction edges won't be broken. Not for use on final compiles.
   • -threads #: For multiple CPU systems, you can specify here how many CPUs to use
   • -v: Verbose mode.
4. QCSG
   • -glview: Creates a .gl file. Each .gl file contains a number of planes, the number of points in each plane, the points used to define each plane, and the total light on that plane.
   • -nowadtextures: Include the texture bitmaps in the bsp, don't do run time loading of them from the .wad file.
   • -onlyents: If you use this parameter, only the entities in a bsp will be updated with the properties of those in the map
   • -threads #: For multiple CPU systems. Same as above.
   • -v: Verbose mode.

Errors

Probably the most common thing seen is people asking what the LEAK LEAK LEAK error is when they compile. In a nutshell, a leak is when part of the Void is exposed or in contact with an entity. You want to make sure everything in your map is completely sealed off. If you have a func_wall for a wall (something you don't usually want anyways) and it's an outside wall, you'll have a leak. Never put any point based entity (lights, monsters, etc.) out in the void. Always make sure they are in the map.

TIP: Never enclose your map in a box. It will shoot the r_speeds thorough the roof.

Invalid brush errors are another semi-common error. It happens when you make a brush that is too complex. If you make a 10,000 sided cylinder, it's going to annihilate the Half-Life engine. Also if you make a brush and draw a straight line through it and it crosses more than two sides of the brush, it is invalid (see the picture below). A great amount of angles can also create a brush that's too complex.