Fix: 'Could not open wad file' During Compile

Your compile stops early in hlcsg with:

Error: Could not open wad file mytextures.wad

This is the first tool in the chain telling you it cannot find a .wad the map depends on. hlcsg needs every referenced WAD to read texture data and decide what to embed. The WAD list comes from two places — the map's worldspawn "wad" key (the list the editor saved) and any -wad/-wadinclude flags you pass — and one of those paths does not resolve on the machine running the compile. The fix is to make the paths correct and present.

1. See which WAD it cannot open

The error names the file. That is the WAD whose path is wrong. There may be several such lines; fix all of them. The path in the error is exactly what hlcsg tried to open, so if it reads an absolute path from another PC, that is your clue.

2. Inspect the map's wad key

The editor stores the WAD list in worldspawn. In Valve Hammer this is Map → Map Properties → wad; the value is a semicolon-separated list of absolute paths saved when you set up the game config:

wad: "C:\games\cstrike\halflife.wad;C:\games\cstrike\cstrike.wad;C:\maps\mytextures.wad"

Every path in that list must exist on the compiling machine. If you moved the project, changed drives, or compile on a different PC than you edit on, these absolute paths break — hence the error. Update them to where the WADs actually are.

3. Prefer relative paths or -wad flags

Absolute paths baked into the map are fragile. Two robust alternatives:

• Copy every WAD the map uses into one folder next to the compiler and pass them explicitly, so the map's stored list is overridden by what you control:

hlcsg -wadconfig mycfg mymap
hlcsg -wadinclude mytextures mymap

• Or keep the WADs beside the .map/.bsp and use relative paths in the wad key. As long as hlcsg's working directory can reach them, they open. This makes the project portable between machines.

The compiler reads the wad key first; make sure it points at real files or strip the stale entries. See the compile parameters guide for how -wad interacts with the map's list.

4. Copy the WADs locally

The simplest reliable fix: gather halflife.wad, cstrike.wad, and every custom WAD into the folder you compile from, then set the wad key to those local copies. Now nothing depends on another drive or another PC. This is especially important when you compile on a build server or a friend's machine that does not have your original texture folders.

5. Remove references to WADs you no longer use

If you deleted a WAD from the project but its path is still in the wad key, hlcsg will fail trying to open a file that no longer exists. Open Map Properties and delete the dead entries from the wad list so the compiler only looks for WADs the map actually needs.

6. Watch for path separators and spaces

The wad key uses semicolons to separate entries and (on Windows) backslashes inside each path. A stray forward slash, a missing semicolon that fuses two paths into one, or a folder name with a space that the tool cannot parse all produce the same could-not-open error. If the path in the error looks subtly wrong — two WAD names run together, or a mangled directory — edit the wad key by hand in a text editor: the .map/.rmf stores it as plain text you can correct directly. Rebuild the list cleanly if it has accumulated cruft over many edits.

Common errors

• Error: Could not open wad file ...wad — the named path does not resolve. Fix it in Map Properties or copy the WAD locally.
• Path in the error is from another computer — absolute paths were saved on a different machine. Repoint the wad key or use local relative paths.
• Compile finds stock WADs but not the custom one — the custom WAD moved or was never copied to the compile machine. Put it beside the compiler.
• Fixed one path, another WAD fails — there are multiple entries; correct every path in the list.
• Removed a WAD but it still errors — its dead entry is still in the wad key. Delete the entry.

Verification

Re-run hlcsg alone and confirm it reads past the WAD-loading stage without the error, listing each WAD it opened. Then run the full chain and load the map to check textures resolve — a compile that could not open a WAD often produced black faces even where it limped through. If it compiles clean on your machine but you plan to build elsewhere, move the whole project (map + WADs + relative paths) to that machine and compile again to prove it is portable. For delivering the map afterwards, see wadinclude vs external WADs.