The archive
A .scm or .scx file is an MPQ archive, the container format Blizzard used for its
games' data. The scenario itself is one member of that archive, always named
staredit\scenario.chk. Everything else in the archive is extra: custom sounds, custom
graphics, files another editor or a plugin put there. The editor keeps those members and
writes them back on save, so a map with its own sound files comes out of the editor with
them still inside. A bare .chk file, the scenario with no archive around it, opens too;
some tools pass scenarios around that way.
An archive names its members in a (listfile), and protectors often remove it. The
editor then finds the members the scenario itself refers to — its sound table, the
trigger script members — by asking for them by name, so a protected map's sounds are
still listed and editable. Anything left that it cannot name is carried across a save
exactly as stored, at the same place in the archive, so the game finds it as before;
the Save dialog says how many such members there are. Two things follow from
carrying them that way: the archive keeps the sector size it came with (zlib's larger
sectors are not used), and a bare .chk cannot hold them. A member the editor can name
but not decode is kept the same way.
The Save dialog decides how the scenario is stored in the archive:
| Option | What it means |
|---|---|
| PKWARE | The compression StarEdit uses and every Blizzard map is stored with. Every version of the game reads it. |
| zlib | Smaller. Read by 1.16.1 and Remastered, not by older builds. |
| None | The largest, readable by anything. |
| Encrypt | StarEdit's own light encryption of the member. It hides nothing from a map editor; it is there for files that other tools expect encrypted. |
A map is written back the way it was opened: the editor reads how the scenario was stored and offers the same layout, so a map that came in as PKWARE goes out as PKWARE. A new map gets StarEdit's layout, PKWARE and encrypted, with 4 KB sectors. A member stored with a method the editor can read but not write (bzip2, for one) is written back with whichever layout the dialog shows.
The same dialog can leave things out of the file. Each extra archive member has a tick. So do the editor-only sections of the scenario, explained under What the game reads and what it skips, and so do sections the editor does not recognise and bytes left after the last section. None of those ticks change the map you have open, only the file being written.
Built maps#
A plugin can put a compiler between the map and the disk; the eudplib plugin does, for
scripts that need Remastered's extended triggers. The file then holds two scenarios.
staredit\scenario.chk is the compiler's output, which is what the game reads.
scmjs\source.chk is the map as the editor shows it, and scmjs\build.json records
which steps ran, which archive members they added, and the SHA-256 of the built scenario.
Both are zlib-compressed whatever the dialog's compression says, since the game never
opens them.
Opening such a file gives back the map from scmjs\source.chk, so the trigger list
shows your triggers and not the generated ones. That only happens while the built
scenario still has the recorded hash. If another editor or a protector has changed it
since, the editor cannot tell which of the two you mean, so it opens the file as it
stands, says so, and leaves both members where they are. A bare .chk is never built.