Embedding WADs vs Using -wadinclude

Every CS 1.6 map references textures that live in WAD files, and one compile decision determines whether players see your custom textures or a wall of purple-and-black checkerboard: are those textures embedded in the BSP or shipped as external WADs? The -wadinclude switch on hlcsg is how you choose per-WAD. Getting the rule right keeps your map self-contained without bloating it to nothing.

1. How hlcsg finds textures

hlcsg is the first compile stage. It reads the WAD list saved in the map (the wad key in the worldspawn, set by your editor) and, for each texture the map uses, pulls the pixels from whichever WAD contains it. By default it does not copy those pixels into the BSP — it only records the texture names, and the client is expected to have the same WADs locally to supply the images. That is an external WAD: small BSP, but every client needs the file.

2. What -wadinclude does

-wadinclude tells hlcsg to bake the textures from a named WAD directly into the compiled BSP:

hlcsg mymap -wadinclude mytextures.wad

Only the textures the map actually uses from mytextures.wad are copied in — not the whole WAD. The result is a self-contained BSP: a player can download just the .bsp and see every custom texture with no extra files. The cost is size — each embedded texture adds its bytes to the map, so a texture-heavy map can grow by several megabytes. You can pass -wadinclude multiple times, once per WAD you want baked:

hlcsg mymap -wadinclude bricks.wad -wadinclude custom_signs.wad

The match is on the WAD filename as it appears in the map's WAD list, so the name you pass must match exactly (case-insensitive on Windows tools, be careful on Linux compilers).

3. The modern rule

The practice experienced mappers follow:

• Embed your custom WADs with -wadinclude. These are textures nobody else has, so baking them in guarantees the map looks right for everyone and you do not have to distribute loose WAD files or push them over FastDL.
• Keep the standard CS WADs external — halflife.wad, cstrike.wad, decals.wad, liquids.wad, xeno.wad, and friends. Every client already has these because they shipped with the game. Embedding them just wastes megabytes duplicating textures the player already owns.

So a typical de_ map that reuses cstrike.wad walls plus a handful of custom brand textures should embed only the custom WAD and leave cstrike.wad external.

4. Clean up the WAD list before you ship

A common mistake is leaving a dozen WADs in the map's WAD path that the map does not use. Even external, those names get written into the BSP's WAD list, and if a client lacks one it can trigger a missing-texture warning for textures the map never actually references. Compile with -wadautodetect (or prune the list in your editor) so the BSP only lists WADs it genuinely uses. This is also why -nowadtextures exists — it forces all used textures into the BSP and writes an empty WAD list, the maximally self-contained option, at the maximum size cost.

Common misconceptions

• "-wadinclude copies the whole WAD." No — only the textures the map uses from that WAD. An unused texture in the WAD adds nothing.
• "Embedding the standard WADs makes the map more compatible." It only makes it bigger. Clients already have halflife.wad and cstrike.wad; duplicating them wastes download bandwidth.
• "Purple checkerboard means the map is broken." It means a texture is missing — either an external WAD the client lacks, or a texture name that was in the WAD list at compile but not embedded. Embed the custom WAD or ship it.
• "WAD name doesn't matter for -wadinclude." It must match the filename in the map's WAD list. A typo means hlcsg silently includes nothing from it.
• "-nowadtextures and -wadinclude are the same." -wadinclude is selective per WAD; -nowadtextures bakes everything and clears the external list entirely.

How to check what ended up in the BSP

After compiling, the quickest test is the real one: copy only the .bsp to a machine that does not have your custom WAD, load the map, and look for missing textures. If the custom textures render, they are embedded; if they checkerboard, they were left external and you need -wadinclude or to ship the WAD. You can also open the BSP in a tool like Wally or a BSP viewer and inspect its texture lump — embedded textures appear with pixel data, external ones as name-only references. Keep the BSP lean by embedding only what is genuinely custom, and let VIS optimization handle runtime performance separately — texture embedding affects download size, not r_speeds.