Packs, the gallery and your library

How pieces travel: packs, zips, the gallery everything is published to, the library you keep, and composed packs.

A piece lives in a pack: a resource pack for the model, the textures and the names, and a datapack for the piece file, its recipe and its fittings. One folder can be both. The editor makes them, finds them and zips them; the game loads them from resourcepacks/ and a world’s datapacks/. A pack is the only thing the game installs, and so the only thing an install list ever names.

Zips

Export Pack… writes a zip with the folder’s contents at the root, the way the game wants it. Import zip… unpacks one into a pack of yours, finding the pack inside however it was zipped and refusing to write outside the destination.

The gallery is everything published: the packs that ship with the editor, each hosted by its author, and every pack an account has made public here. It is one list, served as gallery/index.json, and it is what the editor installs from on both platforms — Packs… › From the library…. Offering a pack is done from its page in your library: upload it (Packs… › Upload to your library… in the editor, or the zip on the library page), cut a version, and Offer this pack to the gallery; a maintainer reviews each piece once, and the pack is listed when the last of them is through.

The same list has always answered at library/index.json, and always will: every desktop plugin derives the whole site address from that one setting, so the URL cannot move.

Your library

The gallery is everything; your library is your selection out of it. It holds four things:

  • Packs you author. Uploaded as zips or saved straight from the editor, each with versions, private by default. Unlisted has a link; public goes to the review queue and, once approved, to the gallery with a thumbnail per piece. These are the only thing that draws on your storage.
  • Packs you saved. Someone else’s published pack, kept as a reference to a version rather than a copy.
  • Pieces you saved. A bookmark naming a pack and a piece. It costs nothing, so a library can hold a thousand of them — and a piece whose author reserved every right can be kept and worn here even though it can never be copied into a pack of your own. Bookmarking is looking; copying is publishing.
  • Sets you saved. A whole outfit, referencing pieces rather than holding them.

Your library is served in the same shape as the gallery, at api/me/library.json, so the editor’s Your library source reads both the same way — on the web through your session, on the desktop through a device token you approve in the browser. A shelf is an install list: what is on it is what a game gets.

No account is needed to have one. Without one, the packs and pieces you save and the outfits you keep are a shelf in your browser — the same references, the same pages, kept on your machine and sent nowhere. You can export it to a file and import it again, here or anywhere. Signing in offers to keep exactly what is on that shelf in a library instead, and only takes what you say yes to.

What an account adds is what a browser cannot do on its own: publishing a pack to the gallery, hosting one (quota, versions, review), a link to a set and the rendered picture of the figure wearing it, linking a repository or a Drive file, signing the desktop plugin in — and the same shelf on a second machine. Packs you author are account-only for the same reason: they are hosted here.

Clearing your browser’s site data throws away a shelf that has never been signed in, which is what the export is for.

A pack can also be linked rather than hosted: a GitHub repository, through an app installed on that one repository, or a zip on Google Drive, through the one file you pick. The site keeps only the manifest and the thumbnails and fetches the pack when asked. Both are set up under Connectors.

Identity: registering your pieces here

A piece in a save is named by its id, and an id is a name you chose — so the moment you rename one, move it into another pack, or hand it to somebody else, every save wearing it is pointing at a name nothing answers to. The mod keeps such a piece rather than dropping it (the armor holds it, does not draw it, and gets it back when the pack arrives), but “kept” is a floor, not a plan.

So the library issues every piece a uid: a lineage identifier, minted once, that stays with the piece through every rename, every move and every redraw. Two things follow, and neither asks anything of you:

  • You never make one up. Upload a pack here, or save one from the editor, and any piece without a uid gets one. Everything you download back — the zip, the export, the pack the editor opens — carries it written into the piece’s own file, so from then on it travels with the content wherever the content goes. A uid you invented yourself, or copied from somebody else’s piece, is the one thing that can bind a save to the wrong piece; if a piece already has one, it is kept exactly as it is and nothing here overwrites it.
  • Uploading again is recognised. The uids in the files are matched against what the library already holds, so a pack whose textures you redrew arrives as the pieces it is, not as strangers with new names. Which is also how your library can say “this is the piece in the Wild Hunt”, or “a newer version of this is over there”.

Two more things the library does with it:

It will not let you break a save quietly. Cutting a version that stops publishing an id the pack published before is refused, with the ids named. If it is a rename, the site can usually see where the piece went and offers to write the former_ids line into it — armor wearing the old id then finds the new piece by itself, with no action from the player. If it is a real removal, that is allowed, but you say so by name.

It knows a replacement from a stranger. Pieces do not merge: the last pack to load wins the file. A pack of yours carrying armorpieces:circlet replaces the mod’s circlet for anyone who installs it, and armor already wearing it picks yours up with nothing to migrate. Take the mod’s piece into a collection or a pack of your own, edit it, and keep the id; the library recognises it and gives your version the same lineage, because it is that piece redrawn rather than a new one.

The authoring guide has the file-level detail: former_ids, uid, and what the game does when something really is missing.

Composed packs

Build a pack makes one zip of what you picked, on the server, from any pack whose license allows it, with every license repeated on the download page. Two identical selections are one file. A composed pack is for your own use and your own server; re-uploading one elsewhere is not permitted.

Edit this page