This page follows one release from the /rp release command in game to players downloading the new pack. If your pack isn't in the pipeline yet, read Pack repository first. Releasing needs the permission architect.resourcePackAdmin, part of MCME-Architect.

There are two commands, for two separate decisions:

• /rp release builds the zips and publishes them as a GitHub release. Nobody gets them yet.
• /rp server points one Minecraft version's slot at a release. From then on, players get that release.

So you can look at a release before it reaches players, and going back to an older release is a single /rp server command.

Two stages: test, then production

Every pack goes through the same steps twice: once on the RP server, the test stage, then once on a main server, which is production.

flowchart TD
    dev["Push to development"] --> rel1["/rp release on the RP server"]
    rel1 --> test["GitHub release in the test repository"]
    test --> srv1["/rp server on the RP server"]
    srv1 --> check{"Looks right in game?"}
    check -- no --> dev
    check -- yes --> pr["Pull request: development to master"]
    pr --> rel2["/rp release on a main server"]
    rel2 --> prod["GitHub release in the pack's repository"]
    prod --> srv2["/rp server on the main servers"]
    srv2 --> players["Players get the pack"]

1. Before you release

• Push your work to the branch the stage builds: development for the RP server, master for production. At the start of every release the server brings its copy of the pack up to date with that branch on GitHub, and builds exactly that. Work that is only on your computer, or on another branch, isn't in the release.
• Pick a new version tag, for example v4.1.4. It becomes part of every download URL, so use only letters, digits, dots, dashes and underscores, starting with a letter or digit. The release refuses any other tag before it builds anything. Keep it short: each player's pack URL must fit in 100 characters, and today's longest are 96.
• Use a new tag for every release. On the RP server, reusing a tag replaces that release's zips; on production, a tag that exists is refused.
• Recommended: run the conversion on your own computer and read the warnings (see Pack repository). The server runs the same code.

2. Start the release

/rp release <pack> <version tag> <release title>

• Run it on the server of the stage you want: the RP server for a test release, a main server for production. It also works from the server console.
• The build runs in the background. You get a line when it starts, a line as each group of zips is done, and a closing message (see The result).

3. What runs on the server

MCME-Architect looks the pack up in its config, which says which release script builds it, which GitHub repository gets the release, and where on the server to run it. Operators set this up: see Resource pack server (operators only).

Before anything is built:

1. The release lock. Only one release runs at a time on each stage. A second /rp release while one runs is refused and starts nothing; the message says which release is running. Run it again once the first has finished.
2. ResourcePackScripts is updated to its branch on GitHub (development on the RP server, master on production). A change merged into ResourcePackScripts reaches the next release on that stage.
3. The release script starts, through a wrapper that keeps a log and a summary of every run.

MCME-Architect gives a release 30 minutes (operators can raise this per pack). A release still running then is stopped, with everything it started. A Human release takes a little over 5 minutes (see How long a release takes).

4. The release script, step by step

The release script first checks its arguments and asks GitHub whether the tag exists; on production an existing tag stops it there. Then it brings the server's copy of the pack up to date with GitHub. It only ever fast-forwards to what GitHub has: if the server's copy was edited, has commits GitHub doesn't, or isn't on a branch that follows one on GitHub, the release stops before building, and an operator fixes the server's copy.

Sodium packs: six zips

Used by Human, Mordor and Paths of the Dead. <Pack> is the pack's name in the config, for example Human. Each line in the first column is printed as the step starts, and shows up in chat.

Vanilla-only packs: two zips

Used by Dwarven, Rohan and Lothlorien. There is no conversion.

Checks before anything is published

• Each Footprints zip must differ from the zip it was made from, or the release stops: the footprints textures didn't make it in.
• The Lite zip must differ from the Vanilla zip. Every Lite conversion turns on the shader base's Lite mode, so the two always differ; the same files mean Lite mode didn't apply.
• Any failed step stops the release before it publishes: the pack's update, zipping, generateVanilla, a footprints texture, or the release note. Nothing from an earlier release is ever uploaded in its place.
• The release note is worked out from the zips' pack.mcmeta: it names every Minecraft version all the zips support, through ResourcePackScripts' pack_formats.json (88 is 26.2, 97 is 26.3). For example: "Version v4.1.5 for Minecraft 26.2 and 26.3". A pack format the map doesn't know is left out of the note.

What gets into each zip, and why the top level of your repository matters, is on Pack repository.

5. The result

In game, the closing message says how the release went:

• published, with its first three warnings if it had any. Its Put it live: line has a button for each Minecraft version the release note names; a click fills in /rp server <Pack> <tag> <version> for you to send. [Open on GitHub] opens the release.
• published, but its checks found problems: look at the run before you put it live.
• failed, with the release's last ERROR: line, which says why.
• didn't start, with why: another release is running, or the release system on that server needs an operator.
• stopped after the time limit.

A releaser who left the server gets the message when they next join it, unless the server restarts first. Every message is explained in Troubleshooting.

On GitHub, the release appears at https://github.com/<owner>/<repo>/releases/tag/<tag>, with its zips. gh release create publishes the release before the zips are uploaded, so if the upload fails, the release is there without all of them, and the ERROR: line says what to do.

The run summary. For every run the wrapper records the steps and how long each took, every zip with its file count, the warnings and errors, and a status:

The summary flags a zip that is empty or wasn't finished, a zip with under 90 % of the files the same zip had in the pack's last good release (usually a conversion that broke half-way), and a missing GitHub release, even when the script itself ended without an error. Operators can read the full log of every RP server run.

6. Put the release on a server

/rp server <pack> <version tag> <Minecraft version>

For example /rp server h v4.1.3 26.2. It needs architect.resourcePackAdmin.

1. The plugin downloads each zip of that release, works out its SHA-1, and writes the download URL and the SHA-1 into the pack's slot for that Minecraft version. Dots become underscores, so 26.2 is the slot 26_2. Minecraft checks every download against the SHA-1.
2. Which zips it uses depends on the pack: for a Sodium pack, <Pack>-Vanilla.zip, -Vanilla-Footprints, -Sodium, -Sodium-Footprints, -Lite and -Lite-Footprints; for a vanilla-only pack, <Pack>.zip and <Pack>-Footprints.zip.
3. If a zip is missing from the release, that variant keeps its old URL and SHA-1, and the plugin says so.

• Type the Minecraft version as the game names it: 26.2, 26.3, 1.21.4. The plugin refuses a version it doesn't know, and lists the ones it does.
• /rp server remove <pack> <Minecraft version> takes a slot out of a pack. A pack's last slot can't be removed.
• /rp calcsha <pack> downloads the zips again and stores fresh SHA-1s for the newest slot; /rp calcsha <pack> all does it for every slot. Use it after a release's zips were replaced under the same tag.
• Several servers share one config file. The command writes that file, but servers that share it and didn't run the command keep their copy in memory. Run /rp server on each of them, or run /architect reload on the others afterwards.

7. Players get the pack

Which pack. Each area of the world gets its pack through RP regions, which staff draw with /rp create. A player with automatic switching on (the default) gets the region's pack when they walk into it. Players can also choose a pack with /rp <pack>, for example /rp h.

Which zip. Within a pack, the plugin picks:

• the client type: sodium for players who join with the MCME modpack, vanilla for any other client, and lite only when chosen with /rp client lite;
• the variant: light (the normal pack), or footprints with /rp variant footprints;
• the slot: the newest slot whose Minecraft version is not newer than the player's. A 26.3 player gets the 26_2 slot until the pack has a 26_3 one.

If the pack has nothing for the player's choice, for example a Sodium player in a vanilla-only pack, the first option listed in the config is used.

When. Players get a new zip when they join the network, when they walk into a different RP region, and when they use /rp <pack>, /rp reset, /rp client or /rp variant. Nothing pushes a new release to players who are already online. /rp <pack> -force resends the pack to you, even if the URL hasn't changed, which is handy for checking a release yourself.

How long a release takes

Measured on the RP server in September and October 2026:

Almost all the time goes to generateVanilla baking the .obj models, once for Vanilla and once for Lite. Zipping and uploading take seconds, and a vanilla-only release takes a few seconds in all.

Changing the release scripts

The launcher, the release scripts and the wrapper are in ResourcePackScripts under automation/, and the server runs them from its checkout without editing them. A change goes through a pull request into development, reaches the RP server's next release, and reaches production after a development → master pull request.

The lines the scripts print (the step lines, WARNING! and ERROR: lines, the release note: line and others) are read by MCME-Architect to build its chat messages and buttons. Change one only together with MCME-Architect. The full list is in What MCME-Architect reads.