The marketplace no longer asks a running table to wait for its next launch. A GM can add a content pack or install a mod while everyone remains connected, and the world server tells each client what changed through the same authoritative channel that owns the rest of the session.
What changed
- An install written behind the running server
- An acknowledged command to the world that is already open
- Store category choosing the installer
- A persisted mod, content-pack or unavailable install contract
- A pack trusted after its URL was approved
- Raw bytes checked against the approved id, version and hash before import
- New mod state after a relaunch
- Each connected client stages the sandboxed mod, then keeps or replaces its working copy
One storefront, separate lifecycles
Systems, mods, sheets, maps, collections and audio remain useful ways to browse the store. They are not six interchangeable package formats.
A published version now carries an install descriptor alongside its editorial category. Mods are
sandboxed SDK bundles with a mod.json. Maps and collections are declarative content packs. Sheet
packs may provide a compiled sheet only for a runtime type declared by that same pack. Audio packs
import assets, but do not promise playlists, stingers or playback. System packages can be listed and
inspected, but have no install button yet because the current system registry runs trusted setup code
inside the world server.
That distinction also appears before publication. Creator Studio sends the category the creator
chose through inspection and publication, then reports the package kind, install kind,
compatibility, direct dependencies and limitations before Review. A generic module is installable
only when it contains a valid root pack.json; module code is neither imported nor executed.
Why the running world acknowledges the install
For an open world, the control plane resolves the creator's immutable version, entitlement,
compatible systems, direct dependencies, requested grants, origin and artifact hash. It mints a
short-lived token for the initiating GM, joins the existing world endpoint, sends the existing
install command, and waits for the matching modules or contentPacks broadcast.
The world server remains the only writer of the running registry and its YAML manifest. A success message therefore means the authoritative process observed and broadcast the exact change. If the world stops during the command, the control plane rechecks its state and safely uses the next-launch path. If the world remains open but never acknowledges, the marketplace reports a retryable failure instead of claiming the install worked.
This reuses protocol 23. No message or patch shape changed, so PROTOCOL_VERSION does not move in
this release.
Declarative packs arrive ready for a GM decision
When a pack is added, every connected client receives the new desired-content list immediately. The Content panel updates in place, and GMs get an import prompt without reconnecting. Players do not get that prompt. Imported types, documents and assets then travel through the ordinary server-authority and projection rules, including document visibility.
Before the first mutation, the client hashes the fetched pack.json bytes and checks the approved
hash, id, version, schema, system compatibility, direct dependencies and sheet-to-type
relationships. A preflight failure creates nothing. If an unexpected failure occurs partway through
an import, Aether removes the documents and types created by that attempt where possible and leaves
the pack unstamped so the GM can retry. Content-addressed asset blobs may remain as harmless,
reusable orphans.
Dependencies are deliberately direct and explicit. A missing requirement is shown on the world selector and blocks the install; Aether does not silently install a dependency tree or solve ranges transitively.
Sandboxed mods replace only after staging
A modules broadcast asks each connected client to fetch and sandbox-load the pinned mod with the
grants the GM approved. Upgrades stage their panels, tools, bindings, iframe and bridge resources in
a temporary registry. The prior version is removed only after staging succeeds.
One client's load failure does not uninstall the world record or interrupt clients that loaded the mod successfully. The affected client keeps the previous working version when there is one and shows the local error with Retry. A GM can also disable or uninstall the mod through the existing authoritative actions.
Content, Roll Tables and Player View share a frame
The Content panel now gives desired packs, URL and file import, export, loading, failure, retry and remove states one consistent hierarchy. Roll Tables has a named empty state with its create action. Player View has a header and explicit no-player, unsupported, loading, selected-player and error frames. The latter two changes are visual only; no roll or projection behavior moved into the marketplace work.
What it does not do
Third-party systems still cannot become a world's ruleset. That needs a separately sandboxed or declarative system-definition model, versioned migrations and its own ADR before hosted Aether can offer it safely. Audio content imports assets only. A contributed sheet cannot override a system's built-in type, and one listing cannot combine executable mod grants with content-pack import consent. Creators publish those as separate packages.
This release also does not add a transitive dependency solver or system-version ranges. Compatible systems are exact ids because a running world does not yet advertise a system package version.
Try the loop
Open Creator Studio to inspect a .zip bundle or .aetherpack.json, or browse the
marketplace and choose a world you run. A running world's Content panel or Mods
dialog should change without a stop, launch or reconnect; a stopped world receives the same pinned
version on its next launch.
