scmJS docs

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.