A desktop editor for IVAO Aurora sectorfiles: open an .isc, see the whole
sector drawn on a map, edit it, validate it against the format and the IVAO
quality standards, and package the release.
Built with Tauri 2 (Rust) and React + deck.gl.
ISMS is an independent, unofficial tool. It is not made, endorsed, supported or reviewed by IVAO, and it speaks for nobody but its author. Aurora, the sectorfile format and the standards ISMS checks against are IVAO's; this is one person's reading of the documents they publish.
It is provided as is, without warranty of any kind. The author accepts no responsibility for any damage, data loss or rejected sector release that follows from using it. In particular:
- The validator can be wrong in both directions. Its rules encode one reading of the published format and the IVAO standards, and there is no conformance suite to check that reading against. A finding can land on a row that is perfectly valid, and a row that is not valid can go unreported. A clean run is not IVAO's approval, and a finding is not a verdict.
- A fix writes to your files. The repairs the validator offers — one finding at a time, or a whole rule at once across the sector — change rows nobody is looking at while they run. They are undoable and nothing reaches the disk until you save, but they are still your files.
- What ISMS parses is not necessarily what Aurora reads. A record it fails to understand, or draws in the wrong place, is a limit of this tool and not a statement about the file. Aurora is the only authority on what Aurora accepts.
Work on a Git checkout of the sector rather than on a live Aurora install, and read the diff before you commit it. That habit is what the one rule below exists to make possible.
The same notice is shown in the app on first run — Help ▸ About ISMS brings it back after it has been dismissed.
Loading a file and writing it back without edits produces a byte-for-byte identical file.
Sectorfiles live in Git and are reviewed by pull request. A tool that reorders lines, normalises whitespace or rewrites line endings turns every commit into a thousand-line diff and is useless to the people who have to review it. So ISMS never regenerates a file from a model: it keeps the original bytes, records the byte span every entity came from, and an edit replaces only that span. This is enforced by round-trip tests over a real sectorfile corpus, not by convention.
Everything else in the design follows from this.
Download the installer for the latest version from the Releases page:
ISMS_<version>_x64-setup.exe— NSIS installer, installs per-user, no administrator rights needed.ISMS_<version>_x64_en-US.msi— MSI, for deployment.
Windows is the only platform currently built. The code has no Windows-specific dependency; adding macOS and Linux to the release workflow is a matrix entry.
The installer is not code-signed, so SmartScreen shows a blue warning. Windows makes no distinction between unknown software and dangerous software: every unsigned binary gets the same screen. To install anyway, click More info and then Run anyway.
Signing it would need an Authenticode certificate from a recognised CA, whose private key must live on hardware or in a cloud HSM. An OV certificate would still leave the warning up until it earns SmartScreen reputation; only an EV one removes it immediately. Until ISMS is an official tool with an organisation behind the certificate, it ships unsigned.
The user guide is the manual: opening a sector, the panels, editing, tracing a shape on the render, managing the files of the sector, the validator's codes, and preparing a release.
The short version. File → Open .isc… takes any .isc; the include root is
derived from it as <directory>/Include, so nothing is hard-coded to one
division, and the sectors opened before are listed on the front page and under
Open. Opening resolves the full include graph — both the explicit F;path
directives searched along the [INFO] search paths, and the files auto-loaded
because they are named <ICAO>.<ext> for an ICAO declared in [AIRPORT]. The
project tree is on the left, the render in the centre, the source of whatever is
selected on the right, and the validator's findings along the bottom. Edits
change the in-memory buffer, the render and the diagnostics; nothing is written
to disk until you save.
crates/isms-parser/ The format. No Tauri dependency, tested in isolation.
src-tauri/ The Tauri shell: project, editing, files, AIP, release.
src/ React UI and the deck.gl canvas.
docs/ User guide, data inventory, format spec, IVAO standards.
scripts/ Release tooling.
All format knowledge lives in isms-parser, which knows nothing about the app.
Its modules map to the format: source (the raw buffer and its line index),
line (field tokenising, no allocation), records (section grammars),
coord, color, colorscheme, isc, graph, validate.
Two decisions worth knowing about before reading the code:
- Geometry crosses the IPC bridge as binary, not JSON. Madrid is ~110k
entities, and spelling every vertex out in decimal text on every open and
every group toggle was the single most expensive thing the app did. The
layout is documented in
src-tauri/src/wire.rs;src/api.tsdecodes it, and the two must be changed together. - File ids are positions in the include graph. Anything that adds or removes a file reopens the project, which renumbers them, which is why those operations return a fresh summary and clear the undo history.
npm install
npm run dev # Vite dev server
npm run tauri dev # the appcargo test --workspace # parser and backend
npm run typecheck # tsc --noEmit
npm run bundle # build the installers into target/release/bundle/The round-trip guarantee, the include-graph resolution and most validator rules
are asserted against a real sectorfile corpus — the 9 .isc roots plus
Include/ESnew, 725 files. It is not in this repository: it is a
byte-for-byte copy of a live Aurora install, so it is IVAO's data and not ours
to redistribute.
To run those tests, point ISMS_CORPUS at a sectorfile directory, or place one
at testdata/sectorfiles:
ISMS_CORPUS=/c/Aurora/SectorFiles cargo test --workspaceThe 63 tests that need it skip with a message when it is absent, so a plain
checkout still builds and tests green. Whatever you point it at must keep its
exact bytes: .gitattributes disables every line-ending conversion under
testdata/, because normalising CRLF there would leave the round-trip test
passing on corrupted data.
A full release build uses lto = true and codegen-units = 1 across the
workspace; it is slow and needs a lot of disk. CI does it on a clean machine.
Versions live in four files and must agree with the tag: Cargo.toml
(workspace), package.json, src-tauri/tauri.conf.json and
package-lock.json. Do not edit the last one by hand — regenerate it, or the
release build fails before it compiles anything:
npm install --package-lock-only # after bumping package.json
cargo check --workspace # updates Cargo.locknpm ci refuses to install when package.json and package-lock.json
disagree, which is exactly how v0.1.1 shipped without an installer.
Then write the entry in CHANGELOG.md under its own heading —
## [0.1.3] - 2026-08-04 — and move what is under ## [Unreleased] into it.
That section becomes the release notes on GitHub, so a tag whose version has
no entry fails the workflow within seconds of starting, before anything is
compiled.
node scripts/changelog-entry.mjs v0.1.3 # what the release will saygit tag v0.1.0 && git push origin master --tagsPushing the tag runs .github/workflows/release.yml: it runs the tests, builds
the installers and leaves a draft release with them attached, so the notes
can be written before anything becomes visible. Publishing the draft is what
makes the release — and what the in-app updater sees.
A run started by hand from the Actions tab takes the tag to release as an input; leave it empty to only check that bundling still works. The installers are also uploaded as workflow artifacts, so a failure to publish does not throw away a build.
Installing a newer version over an older one is all it takes; there is no need to uninstall first, and per-sector state survives because it lives in the configuration directory, not in the install. Going back to an older version works with the NSIS installer but not the MSI, which refuses to install over a newer one.
Tools ▸ Check for updates… asks GitHub for the latest release, and installs it after confirmation. It never runs on startup: the check is a network request, and an editor that reaches out before it opens a file is one people learn to distrust. It is disabled while there are unsaved edits, since installing restarts the app.
The update packages are signed with a minisign key whose public half is in
src-tauri/tauri.conf.json, and a package whose signature does not match is
refused. Signing is not optional: createUpdaterArtifacts is on, so a release
build with no key fails — after it has built the installers — rather than
quietly shipping unsigned ones.
| Secret | What it is |
|---|---|
TAURI_SIGNING_PRIVATE_KEY |
The whole contents of the private key file from tauri signer generate — one line of base64, nothing added |
TAURI_SIGNING_PRIVATE_KEY_PASSWORD |
Only if the key was generated with a password. Leave the secret out entirely otherwise: an empty value fails the decryption |
Lose the private key and installed copies will reject every future update:
they trust that key and no other, and the only way out is for everyone to
reinstall by hand. It lives in ~/.tauri/ on whoever generated it and nowhere
else, which is one disk away from that happening.
This key has nothing to do with Windows code signing — it does not stop SmartScreen warning about the installer. It only proves an update came from whoever holds it.
MIT — see LICENSE.
Aurora and the sectorfile format are IVAO's; this is an independent tool for working with them.