Fix: 'Couldn't open .wad' - Missing WAD Files for Clients

You add a custom map and players either drop on connect or load in with missing textures and a console full of WAD errors. A .bsp map does not always contain its own textures — it can reference external WAD texture packages by name, and if a client (or the server) cannot find a referenced WAD, you get the error and broken visuals. The fix is to make sure every WAD the map names is present and downloadable, or to embed the textures into the map so nothing external is needed.

1. Read the error and identify the WAD

The message names the exact file:

Couldn't open ns_boesmania.wad

or the client-side variant complaining it cannot find a WAD the map wants. The named file is a texture package the mapper referenced at compile time but did not include with the map. Note that a map can reference several WADs; fix them all, not just the first one printed.

2. Know why it happens

When a mapper compiles a .bsp, they choose whether textures are embedded in the map or left as references to external WADs. If they reference external WADs (common for shared texture sets like the stock CS and Half-Life WADs, and for custom texture packs), those WAD files must exist alongside the map on both the server and every client. Standard WADs such as halflife.wad, decals.wad, and the cs_*.wad set ship with the game, so those never error. Custom WADs that came with a map pack are the ones that go missing.

3. Put the WADs on the server and make them downloadable

Place every custom WAD the map references in the game folder:

cstrike/<wadname>.wad

WADs live in the mod root (cstrike/), not in maps/. Then make sure clients can pull them: downloads must be enabled and the file must be on your fast-download mirror. In server.cfg:

sv_allowdownload 1

and copy the same WAD into the matching path on your FastDL host, exactly as covered in the FastDL setup guide. If the WAD is on the server but not on the mirror, the server itself renders the map but connecting clients still error — they download from the mirror, not from the game server, when sv_downloadurl is set.

4. The permanent fix: embed the textures

The robust solution is to stop referencing external WADs at all by embedding the textures into the .bsp. If you compile or recompile the map, wad-include the custom textures so they are baked into the map file. Tools that repackage a finished map can also merge the referenced WAD textures into the .bsp. An embedded map is self-contained: it carries its own textures, so no client can ever be missing a WAD, at the cost of a larger map file. For a public server where you cannot control what mappers did, embedding the maps you host is the reliable path.

5. List the map's required files

Ship a resource list so clients know what to download. A .res file next to the map naming the WADs, models, and sounds it needs makes the download explicit rather than relying on the engine to infer everything. This is especially worth doing for map packs with several custom WADs.

Troubleshooting

• Couldn't open X.wad on the server console — the WAD is not in cstrike/. Copy it there.
• Server is fine, clients miss textures — the WAD is on the server but not on the FastDL mirror, or downloads are off. Check sv_allowdownload 1 and the mirror path.
• Only some players error — those players have cl_allowdownload 0 set locally, or their download of the WAD failed; only they can re-enable it.
• WAD present but still errors — filename case mismatch on Linux (Custom.wad vs custom.wad). Match the case the map references exactly.
• Recurs on every new map pack — embed the textures into the .bsp so hosted maps are self-contained and stop depending on external WADs.

Verification

Load the map on the server and confirm the console is clean of WAD errors — that proves the server has every referenced WAD. Then connect from a fresh client that has never seen the map (delete it locally first) and watch it download; if it loads with correct textures and no couldn't open spam, the download path works end to end. For a map you embedded, the definitive test is to rename or remove the external WAD from the client entirely and confirm the map still renders every texture — if it does, the map is truly self-contained.