SCNexus 0.1.0 released

The previous stable release was 0.0.21, published in December 2024. The 0.1 line has since been developed through a series of snapshots, during which the interface, campaign management and custom content management were rewritten. 0.1.0 is the first stable release of that line, and the most substantial change in almost two years.

Three areas account for most of it: a new interface, a new underlying architecture, and rebuilt campaign and custom content management. Each is described below, followed by the Workshop, weekly mutations, replays and the Assistant.

What a stable release means

During the snapshot period, the layout, the configuration format and the install records were all subject to change, and every upgrade required reading the release notes first. 0.1.0 settles these: subsequent 0.1.x releases will contain fixes and small additions only, without further wholesale rework.

For users still on 0.0.21, this upgrade spans roughly two years and changes how the application is operated. Reading the documentation after upgrading is recommended.

A new interface

A sidebar replaces the previous column layout. Navigation, buttons, dialogs and notices now share a single set of components and colours, and the light or dark theme can follow the system setting.

Settings, previously spread across several locations, are consolidated into one page: game directory, feature switches, logging and privacy are configured in the same place.

A new underlying architecture

The application structure and the data handling beneath the interface have been rewritten as well.

The main process is divided into modules by domain — campaigns, custom content, content packages, replays, the Workshop, settings, updates, the Assistant. The renderer communicates with it only through the explicit interfaces exposed by the preload layer: interfaces are declared one by one, per domain, and arbitrary channel invocation is not available. Arguments and call origins are validated at runtime in the main process; type declarations are not treated as validation.

Content package handling is a single pipeline: scan, classify, parse, plan install targets, detect conflicts, write. Writing is performed as a transaction, so a failure part-way through returns the files already written to their previous state rather than leaving a partially installed directory.

Configuration and install records use a persistent structure with defaults, validation and version migration, so data from earlier versions is migrated on upgrade.

Campaign and custom content management

The rework of campaign and custom content management centres on recognition.

A source no longer has to contain a descriptor. Once an archive or directory is added, the application locates the resources from its Maps / Mods structure and determines the install targets itself: no manifest has to be written in advance, and the result does not depend on how any particular directory level is named. Nested directories are handled in the same way.

The campaign type is derived from the map paths: maps directly under Maps/Campaign correspond to Wings of Liberty, swarm (including evolution) to Heart of the Swarm, void and voidprologue to Legacy of the Void, and nova to Nova Covert Ops. Differences in the casing of resource paths are normalised by the application, so the packager's conventions no longer matter.

Where a descriptor is present, it takes precedence: a source containing package.json is handled under the SCNexus package standard, one containing metadata.txt under the CCM package standard, and a source containing neither goes through automatic recognition.

Where recognition cannot decide, the application states the reason — several candidate package roots, an ambiguous campaign type, resources outside the standard Maps / Mods hierarchy — instead of reporting a bare failure.

Results are updated when files change. After a project is renamed or files are added or removed, the directory is rescanned and whatever is already installed is left in place; in earlier versions the same changes marked the install record as invalid.

The campaign library lists category, install method, content size and disk usage at the same level, without opening a detail page. The source can be chosen before installing, and conflicts are resolved item by item. Before the active content is switched, the application verifies that the current selection is still usable.

Workshop

The website provides each work's description, version history, and the formats and dependencies it requires, so the decision can be made before installing. Uploading is handled by the creator centre, which maintains several versions, saves drafts and shows review status.

Each creator has five works by default, with a limit of 300 MB per work. That covers most campaigns but is not a hard ceiling: creators who need more may apply to an administrator, who allocates the quota case by case.

Weekly mutations

The CN, US, EU and Asia regions each show this week's mutators and map. Entries can be searched by mutator name or description, and community ratings are shown. Data follows server-side verification, and the client indicates whether an entry has been confirmed; where it has not, a rotation estimate is shown instead.

Replays

Replays are organised by StarCraft profile and by type (melee, campaign, challenge). Imported replays are copied into the corresponding directory rather than merely indexed. The list can be searched by file name, map, player or path, and selected replays can be exported as an archive.

Match data falls into four states: fully parsed, partially parsed, unsupported by the current version, and corrupt. The first two show players, races and duration, and some builds also provide economy charts. The feature is not intended as a full review tool; it establishes the basic facts of a match without launching the game.

Note that the replay directory is not watched: after files are added or removed outside the game, use Refresh or Scan directory.

Assistant

The Assistant provides a controlled local connection for AI clients on the same machine. It can query application state, campaigns, projects and download tasks, and can carry out operations that modify files, such as switching, restoring and uninstalling.

It is disabled by default. Once enabled, a connection requires an access token, which can be regenerated at any time and invalidates the previous one immediately. Operations that modify files require confirmation each time by default, and automatic approval can be granted per operation. The 500 most recent operations are retained, without recording request contents.

A token is equivalent to permission to read local data and modify campaign files. Grant it only to clients you trust.

macOS

The macOS build enters the first stage of support: the game installation is detected, and resource directories are recognised even where Maps and Mods differ in case. The package is currently neither signed nor notarised, so the first launch must be allowed in System Settings → Privacy & Security. Some features remain limited, and we do not yet consider it the equal of the Windows build.

Before upgrading

1. Back up. Install records and settings are migrated to the new format; the migration normally requires no manual step, but copy the campaign and custom content directories first.
2. Download. The installer is available from the home page and is 64-bit only. Users coming from 0.0.21 should keep the old version installed until the new one has been confirmed to read existing campaigns, then remove it.
3. Rolling back. Returning to 0.0.21 requires the backed-up directories: the older version cannot read the new install records.

The complete list of changes is in the changelog, which also records each snapshot. Usage questions are covered in the documentation, including installation, campaigns, custom content, replays and the Assistant.

What comes next

Three priorities follow 0.1.0: continue the macOS work until it matches Windows; extend replay parsing to further protocol versions so that fewer matches remain partially parsed; and refine the Workshop and creation flow, from upload through review to updates.

Feedback

The documentation, the legal pages and the common flows were reviewed before this release, but omissions remain possible. Problems can be filed in GitHub issues, or reported through the QQ group and Discord. Security issues should not be reported publicly; the process is described on the Contributing page.