How a pack works

IDs and namespaces

Everything RP Engine holds has one ID, and it looks like a Minecraft resource location:

mypack:ruby
mypack:furniture/chair

Lowercase a-z, digits and _ . - /. An uppercase letter is refused rather than quietly folded, because MyPack and mypack are one ID to us and two to the client — and finding that out in game is much worse than finding it out at load.

The ID is the reference#

An ID is not a label the plugin looks up in a table. It goes verbatim into the item's model reference, which is what makes the whole scheme work:

mypack:ruby  →  assets/mypack/items/ruby.json       the item definition
             →  assets/mypack/models/item/ruby.json the model
             →  assets/mypack/textures/item/ruby.png yours

Only the last one is yours to ship. The other two are generated, and the paths fall out of the ID.

What this buys, and what it costs before 1.21.4

Since 1.21.4 an item's model is chosen by a string, so the ID is the path: nothing is allocated, there is no counter, there is no collision table, and adding content cannot renumber anything that already exists. Two packs from two different people work side by side with nothing to configure.

Before 1.21.4 the game matches a model by a number out of a shared pool. RP Engine runs there and allocates those for you, keeping them in model-numbers.json — but the guarantee above is the thing that cannot survive it, so packs from two sources can clash and that file must never be edited or deleted. Minecraft versions has the detail.

Namespaces#

The namespace is the folder name under content/. That is the whole rule — there is nothing to declare and nothing to register.

Two packs collide only if two people pick the same folder name, and that is caught at load with both sources named, rather than one silently overwriting the other.

Reserved#

minecraft and realms are refused.

Content defined there would write a reference that resolves to vanilla assets, and fail in game as a missing texture with nothing pointing back at your pack. If you want to replace vanilla art, that is what overrides/ is for — named for what it does, so the risk is visible while you are doing it.

Store IDs, never what they resolve to#

The one rule worth carrying into your own configs.

An ID is stable for ever. What it resolves to — a model path, a codepoint, a character — is derived, and derived things move when content around them changes. Icons are the sharp case: they are handed codepoints in ID order, so adding one shifts every icon after it, and anything that saved the character rather than the ID is now showing a different picture.