Vlatitude Archive: Compiling Last edited 1 year ago2019-04-25 02:41:19 UTC

You are viewing an older revision of this wiki page. The current revision may be more detailed and up-to-date. Click here to see the current revision of this page.

This article was recovered from an archive and needs to be reviewed

The formatting may be incorrect as it was automatically converted to WikiCode from HTML, it needs to be revised and reformatted.
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 (found in our files section (Link: files.php)) 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. 2. Vis 3. QBSP 4. QCSG 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.
User posted image
This article was originally published on 69th Vlatitude.
TWHL only archives articles from defunct websites. For more information on TWHL's archiving efforts, please visit the TWHL Archiving Project page.


You must log in to post a comment. You can login or register a new account.