Getting the files

Help ▸ Game Data… shows the current source, and when there is none, the ways to get one:

• Download from Blizzard. Blizzard offers the standalone StarCraft map editor as a free download, and it carries both archives. The two are the trimmed StarEdit distribution rather than the game's own, which matters only in that they are enough: they extract to the same files a 1.16 install does, byte for byte. Note that the patch_rt.mpq in the same package is deliberately not applied — folding it in changes seven tables (units.dat, weapons.dat, upgrades.dat, techdata.dat, flingy.dat, iscript.bin, stat_txt.tbl) and would diverge from every other route.

  The zip is 101 MB and only two of its 152 members are wanted, so src/gamedata/zip.ts reads the archive's own directory over HTTP Range requests and inflates just those two with DecompressionStream("deflate-raw") — 82 MB transferred, no zip library. It goes through a Cloudflare Worker (scm-js/cloudflare-blizzard-forwarder) for one reason: download.blizzard.com answers with a certificate for *.cloudfront.net, plain HTTP is mixed content on an HTTPS page, and no route there sends Access-Control-Allow-Origin. The worker adds the header and forwards ranges; it holds nothing and redistributes nothing. The desktop build uses the same address — its renderer is an ordinary page and enforces CORS like any other.

• Use your own StarCraft files. Pick StarDat.mpq and BrooDat.mpq, or the folder holding them; on the desktop, search the computer or point at the StarCraft folder. Remastered installs have neither archive, so a Remastered-only user wants the download.

Either way the extraction runs here and the result is kept, so it happens once. The dialog also removes a copy, which puts the chain back to where it was.

The container image (docker/Dockerfile) carries no game data — Blizzard's files are not redistributable, so .dockerignore cuts the extracted trees out of the build context and the image's nginx answers 404 for all five of them. A container therefore starts on step 4 and asks, like the hosted build. To serve your own instead, mount an extracted tree over the paths step 1 probes:

docker run --rm -p 8080:80 \
  -v "$PWD/public/tileset:/usr/share/nginx/html/tileset:ro" \
  -v "$PWD/public/arr:/usr/share/nginx/html/arr:ro" \
  -v "$PWD/public/unit:/usr/share/nginx/html/unit:ro" \
  -v "$PWD/public/game:/usr/share/nginx/html/game:ro" \
  -v "$PWD/public/scripts:/usr/share/nginx/html/scripts:ro" \
  ghcr.io/scm-js/scm-js:latest

That is a copy on your own machine served to your own browser. Publishing such an image, or serving one from a public address, is redistributing Blizzard's data — see ATTRIBUTION.md.

One thing follows an install. The blank map the editor opens on was laid out before there was a tileset, and flatTerrain needs the CV5 to choose between a terrain's variations — with none it takes variation 0 for every pair, which is invisible under flat colours and becomes one megatile repeated across the whole map the moment the graphics arrive. relayBlankTerrain (src/hooks/useMapFileActions.ts) lays that map again with the real variations, and only that map: it does nothing once the map has been edited or came from a file (src/atoms/gameDataAtoms.ts#blankFillAtom remembers which fill needs it, tests/blank-fill.test.ts).

Extraction is the same code everywhere: src/gamedata/extract.ts is pure (a ReadMember over the archives in, a map of paths to bytes out), scripts/extract-*.mjs wrap it for Node, src/gamedata/extract.worker.ts runs it in a browser worker, and desktop/main.ts runs it in the desktop app's main process.