The container

A scenario is a flat run of sections, with no header of its own. Each section is a four-character name, a 32-bit length, and that many bytes of data:

The next section starts straight after the data. Sections may come in any order, and the game does not need them in the order StarEdit writes them (the order of this reference). A name the game does not know is skipped.

All numbers in every section are little-endian. Unsigned unless a layout says i32. Positions are in pixels, and a tile is 32 pixels square. Player slots are numbered from 0 for Player 1 to 11 for Player 12. Text is never stored in a section itself: a section holds a string number, the position of the text in the string table, and 0 means no text.

Repeated sections#

The game reads the sections one after another into fixed places in memory, so a section that appears twice is not simply replaced by its second copy. Each section's page says which of these applies to it:

• Only the last copy counts. Most sections.
• Every copy is written over the start of the same fixed-size space, in file order, so a later copy replaces only as many bytes as it carries. A second MTXM half the size of the map rewrites the top half of the terrain and leaves the bottom as the first copy had it. The terrain sections, the fog and the locations work this way.
• Every copy counts. The records of all of them are one list, in file order: two TRIG sections are one longer trigger list. Units, sprites, doodads, triggers and briefings work this way.

Odd lengths#

A length can be shorter or longer than the section needs, or run past the end of the file, or be negative, which makes the game read backwards from where it is. Map protectors use all of these, since each is something the game reads one way and a careless editor another. Protected maps goes through them and how to read such a file, and Opening and saving maps says what scmJS does with one.