What a pack is
redotcom/docs/specs/2026-10-25-pack-framework.md, redotcom/packages/viewer/src/packs/registry.ts:527-535, redotcom/packages/creator-contracts/src/packs.ts, redotcom/packages/creator-contracts/src/layout.ts:1508-1512, redotcom/packages/viewer/src/agent/testroomInstall.ts:29, redotcom/packages/viewer/src/agent/forgePacks.ts:17A zip, opt-in, kept on your device: the rules every pack lives by, and the earlier formats and v2 side by side.
Status: Format only. A v2 pack is checked and stored on your device; nothing in the game applies one yet. The earlier formats, compared below, each have their own status.
A pack in one paragraph
A pack is a zip (or a folder) of files plus one manifest: a JSON file that names the pack, its version, the game it is for, and every other file inside it with that file's size and SHA-256 hash. Before anything uses a pack, the game checks it against its manifest. A pack that fails the check is refused whole, with a list of the reasons.
The rules every pack lives by
These hold for every format, old and new (the pack-framework spec's opening section, and the contract's
PACK_FRAMEWORK_ADAPTATION):
- Opt-in. Nothing is loaded unless you choose it. With no pack switched on, the game is unchanged.
- On your device. You pick the files in your browser. The browser keeps them (in its own storage) and the game never uploads them, to its servers or anywhere else.
- Checked before use. Sizes, paths and hashes are checked first. Only a pack that passes is used.
- Data, never code. A pack holds data: images, models, sounds, JSON. Nothing in a pack is run as a program. A pack that wants a behaviour the engine has (a picture effect, a non-player character's patrol) names that engine feature in its manifest; the engine runs its own code (Pack anatomy, "Handler claims").
- Not in online lobbies. A Forge layout that needs a pack, uses a rules mode or is built on a pack's map is refused
in an online lobby (the contract's
onlineCreatorLayoutRefusal). Whether packs ever reach online matches is the project owner's decision, not made yet.
These are rules of this project, not of the original game: the original has no packs, so every pack format here is a browser adaptation, labelled so in its code.
Two generations of formats
The project has had packs since before the v2 format. Each earlier format has its own manifest and its own loader, and those loaders are still the ones that change what you see. The v2 format is the one format meant to replace them; today it is defined and checked but not applied.
| the earlier formats | the v2 pack | |
|---|---|---|
| formats | s2u-mod v1 (data overrides), texture packs, the model pack, HD texture packs | s2u-pack, format version 2 |
| manifest | each its own: mod.json, manifest.json, models.json, ... | s2u-pack.json at the pack's root |
| what it can hold | one kind of thing each: data files, one map's textures, glTF models, HD textures | any mix of the three kinds content, rules and system, with a role for every member |
| identity | its own id, if any | an id, a version and a hash of the manifest (PackRef) |
| dependencies | none | other packs by id and version range, or your own disc archives by hash |
| status | Test room only; HD texture packs held off until the owner lifts the hold (The earlier formats) | Format only (Pack kinds per kind) |
How the contract reads an earlier pack
The v2 contract can read three of the earlier formats as if they were v2 content packs, through an adapter that
builds the manifest they do not have (the pack-framework spec, "The three earlier loaders"):
- an
s2u-modv1 mod becomes the packmod.plus its id, its files roledata, intentgameplay-value; - the model pack becomes
model.current, version1.0.0, its files rolemesh, intentcosmetic; - a texture pack becomes
texture.plus the map's name, version1.0.0, its files roletexture, intentcosmetic.
Each is read with sides client and contract *. This is why a v2 pack's own id may not begin with mod.,
model. or texture.: those names belong to the adapters. HD texture packs have no adapter.
What happens when you import a v2 pack today
The game's local pack import accepts a v2 pack in two places: the solo test room while Build is allowed, and the
Forge editor (the viewer's testroomInstall.ts and forgePacks.ts). Testing a pack locally
walks through both. When you give it a pack:
- It finds
s2u-pack.jsonat the root, or inside the one folder a zipped directory adds. A lone zip is unpacked first. - It reads the members. The import accepts only some file types; Pack anatomy lists them.
- It runs the check against this build: its target disc, its engine contract version, the packs you already have.
- A pack that passes is stored on your device, with its identity and the check's report.
- It stops there. Asked to apply a v2 pack, the import refuses: "A v2 pack is stored, not applied: no live driver
applies one." (the viewer's
registry.ts, lines 527-535).
So a v2 pack you make today can be fully checked and kept, ready for when the game applies one, but it changes nothing you see or play. The one exception is a rules pack in the Forge, on Pack kinds.
Next
- Pack anatomy: the manifest and the members, part by part.
- Pack kinds:
content,rulesandsystem. - The earlier formats: the formats that change the game's look today.