---
title: "Fix: 'Couldn't open .wad' - Missing WAD Files for Clients"
excerpt: "Why a custom map throws 'couldn't open' WAD errors, how a .bsp references texture WADs, putting the WADs where clients can download them, and embedding textures so they never miss."
category: "errors"
tags: "wad, maps"
image: ""
read_time: "8 min read"
---
<p>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 <code>.bsp</code> map does not always contain its own textures — it can reference external <strong>WAD</strong> 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.</p><h2>1. Read the error and identify the WAD</h2><p>The message names the exact file:</p><pre>Couldn't open ns_boesmania.wad</pre><p>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.</p><h2>2. Know why it happens</h2><p>When a mapper compiles a <code>.bsp</code>, they choose whether textures are <em>embedded</em> 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 <code>halflife.wad</code>, <code>decals.wad</code>, and the <code>cs_*.wad</code> set ship with the game, so those never error. Custom WADs that came with a map pack are the ones that go missing.</p><h2>3. Put the WADs on the server and make them downloadable</h2><p>Place every custom WAD the map references in the game folder:</p><pre>cstrike/<wadname>.wad</pre><p>WADs live in the mod root (<code>cstrike/</code>), not in <code>maps/</code>. Then make sure clients can pull them: downloads must be enabled and the file must be on your fast-download mirror. In <a href="/tutorials/sv-allowdownload-settings">server.cfg</a>:</p><pre>sv_allowdownload 1</pre><p>and copy the same WAD into the matching path on your FastDL host, exactly as covered in the <a href="/tutorials/fastdl-setup-guide">FastDL setup guide</a>. 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 <code>sv_downloadurl</code> is set.</p><h2>4. The permanent fix: embed the textures</h2><p>The robust solution is to stop referencing external WADs at all by embedding the textures into the <code>.bsp</code>. 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 <code>.bsp</code>. 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.</p><h2>5. List the map's required files</h2><p>Ship a resource list so clients know what to download. A <code>.res</code> 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.</p><h2>Troubleshooting</h2><ul><li><strong><code>Couldn't open X.wad</code> on the server console</strong> — the WAD is not in <code>cstrike/</code>. Copy it there.</li><li><strong>Server is fine, clients miss textures</strong> — the WAD is on the server but not on the FastDL mirror, or downloads are off. Check <code>sv_allowdownload 1</code> and the mirror path.</li><li><strong>Only some players error</strong> — those players have <code>cl_allowdownload 0</code> set locally, or their download of the WAD failed; only they can re-enable it.</li><li><strong>WAD present but still errors</strong> — filename case mismatch on Linux (<code>Custom.wad</code> vs <code>custom.wad</code>). Match the case the map references exactly.</li><li><strong>Recurs on every new map pack</strong> — embed the textures into the <code>.bsp</code> so hosted maps are self-contained and stop depending on external WADs.</li></ul><h2>Verification</h2><p>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 <code>couldn't open</code> 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.</p>
