API reference

The open map: what it says, and the three ways of writing to it — edit (terrain and objects, one undo entry), update (the tables every dialog's OK writes) and sections (raw bytes). Opening, saving, exporting and closing are here too.

The settings dialogs' tables, read-only; document.update writes them.

Reading triggers, and the pure helpers that make them presentable. Writing goes through document.update.

Reading the terrain: the tileset's paintable types, the ISOM lattice, flood regions, blend candidates and the symmetry mode. Painting goes through document.edit.

The loaded tileset graphics: whether they are there, and the decoded files behind them.

What is selected on each object layer, the marked area, the active layer and the locked ones.

Cut / Copy / Paste: the clip, its parts, and pasting — what the clipboard layer does.

The file formats behind File ▸ Import / Export: .trg and the strings text.

The palettes' current picks — the terrain brush, the unit, sprite and doodad, the fog mode — and the placement options a plugin that places things should honour.

The names behind the numbers a map stores, so a plugin that shows raw values need not carry the game's tables itself. The per-map ones (string, location, switch, player) read the open scenario and answer a placeholder without one; the rest are the editor's own tables — the same names StarEdit shows.

StarCraft's <XX> text control codes: what they mean, and what a string looks like drawn.

Reading the open map: what is under a point, what lies in a rectangle, and the editor's own analyses — Check Map's issues, Tools ▸ Statistics, the Ctrl+F search and the string usage map the String Editor is built on.

Everything here is a read: nothing changes the map, and nothing throws without one (an empty list, or null).

The game's own tables, as the editor decoded them: units.dat and its neighbours. names gives the labels, this gives the numbers — hit points, costs, build times, weapons, flags, the sprite and image each unit draws through.

Everything is null until the tables are loaded (load), and stays null when the game data was never extracted.

Which set of game files the editor draws from — the game's own or a mod's — and installing, switching and removing sets.

Bit masks, special unit ids and the pixels-per-tile every record is written in.

The pictures the viewport draws, for a plugin's own lists and previews: the same cached canvases, so asking for one costs nothing after the first time. Everything is null when the graphics it needs were never extracted — a plugin shows a name instead.

The map view: where the viewport is looking, how far in, and what it draws over the terrain. A plugin that finds something needs this to show the user where it is.

Everything a plugin puts on the screen: the status line, toasts, dialogs, floating panels, confirm / alert / prompt / progress, a map tool that owns the pointer, a passive overlay drawn over the map, and picking an area or a tile.

Items in the editor's menu bar. A path whose last segment names no submenu makes one.

Items in the right-click menus of the map and the terrain palette.

Key combinations, tried before the editor's own and never while a text field has focus.

Named things a plugin can do, so a menu item, a hotkey, a context entry and another plugin all reach the same one. menu.add, contextMenu.add and hotkeys.add take a command id in place of a run.

Live objects one plugin holds out for others to use, found by name and watched for arriving.

The plugin's words in the editor's language: its own catalogues, and a t over them.

Listeners are notifications: they run after the change, in the order the plugins were activated, and cannot veto or reorder one another. A listener that rewrites the map in response (through document.sections) simply raises a fresh "document" event with reason "replace", which every other listener sees in turn.

Editing the map in front together with other editors: every change to it is handed out as an op for the plugin to carry to them, and theirs come back in, in the order a server puts them. The scmjs.dev plugin's shared maps are built on it; the transport, the server and who may join are the plugin's.

A small key-value store of the plugin's own, kept in the browser's local storage under the plugin's id and listed with everything else in Preferences ▸ Browser storage.