Resource packs

Exporting

You never have to export to test a pack. Pushing to a linked player never produces a file you have to handle, so export is for taking the pack elsewhere: a launcher, a server host, a friend, a marketplace listing.

What you can export#

The Export dialog splits these two ways, because only half of them are resource packs.

Default Pack — a pack you install or serve yourself, no plugins involved:

Plugin Support — not resource packs. On a server running one of these, the plugin builds the pack, and what you're downloading is the content it builds from:

All six are built on demand from what's currently in the editor. There's no build step to remember and nothing to re-upload between edits.

On Bedrock#

Bedrock is a different game with a different pack format, so the .mcpack is a conversion rather than a copy. What converts:

What doesn't, because Bedrock has no way to draw it: GUI screens, the HUD, shaders, dialogs, emotes, per-face block splits and item variants. Each asset's own page says more under On Bedrock.

ItemsAdder#

If your server already runs ItemsAdder, it builds and serves the resource pack itself — so what you want from us is the content, not a second pack. This export is your whole pack as ready-made ItemsAdder content, with the config files written for you.

contents/<your-pack>/
  configs/items.yml            models and 2D items
  configs/font_images.yml      icons
  resourcepack/assets/
    <your-pack>/               your items' models, textures and icons
    minecraft/                 the vanilla files your pack replaces

Everything goes wherever ItemsAdder expects that kind of thing:

Sounds aren't included.

The zip already contains contents/, so merge it into plugins/ItemsAdder/ — dropping it inside the existing contents/ gives you contents/contents/ and ItemsAdder finds nothing. Then on the server:

/iazip                                  rebuilds the pack (this reloads too)
/iaget <namespace>:<item>               gives you one
/iagive <player> <namespace>:<item>     gives somebody else one

The namespace and item ids are in configs/items.yml — info.namespace, and each key under items:. Both are lowercased with non-letters turned into underscores, so a model called "Floating Sword" in a pack called "My Pack" becomes /iaget my_pack:floating_sword.

Items ride on PAPER because it has no vanilla behaviour to inherit. Change material per item in items.yml if you'd rather one behaved like the item it looks like. Models that use a vanilla texture keep pointing at minecraft: on purpose — that texture is already in every client, so it isn't copied.

Icons get a new character, chosen by ItemsAdder — not the one shown here. Both it and we assign characters from Unicode's private-use range, and both start at the same place, so keeping ours would land on top of an emoji you already have and you'd see that instead. Reference the icons by their ItemsAdder placeholder.

The vanilla replacements apply to everyone. Reskinned blocks, item sprites and GUI screens change how the game looks for every player on the server, which is a different decision from adding an item. They're all under resourcepack/assets/minecraft/; delete any you don't want and run /iazip again.

Both kinds of GUI come through, differently. A screen that replaces a vanilla file — the player's inventory, the Escape menu, the HUD — needs nothing: open the screen and it's there.

A screen drawn over a plugin-opened menu is positioned by negative space in front of the image. ItemsAdder spells that :offset_N:, so the export writes each overlay as a font_image and puts its ready-made title string in the README.txt:

:offset_-176::gui_bank_vault:

Give that to whatever opens the menu — ChestCommands, DeluxeMenus, your own plugin, or our /gui. The offset is measured from the sheet's own pixels, so re-export after editing a GUI rather than reusing an old title.

Animated models come through as static: ItemsAdder doesn't play keyframes. The export lists which ones in its README.txt so nothing goes missing quietly. Models that hadn't finished generating are left out and listed the same way — export again once they're done.

Model Engine#

Model Engine rigs animated models onto entities — hitboxes, mounts, mob behaviour — which is a great deal more than our own plugin's playback does. This export gives it your models as Blockbench blueprints.

blueprints/
  your_model.bbmodel
  another_model.bbmodel
README.txt

One blueprint per model — the per-part sub-models our own animation playback uses are internal and aren't exported.

Copy the .bbmodel files into plugins/ModelEngine/blueprints/, then:

/meg reload                    loads them; it reports how many it found
/meg summon <model>            summons one to look at

If ItemsAdder runs on the same server, it owns the resource pack, so tell it to fold Model Engine's in. In ItemsAdder's config.yml:

merge_other_plugins_resourcepacks_folders:
  - "ModelEngine/resource pack"

Then /meg reload, /iazip, and rejoin. Without ItemsAdder, merge that folder into whatever pack your server already sends. A pack pushed from here is not that pack and can't be — Model Engine only generates those textures once it has loaded the blueprints.

Models only. Model Engine has nothing to do with block textures, item sprites, GUI screens or icons — those belong in the Java zip or the ItemsAdder export. Textures are embedded in each blueprint rather than shipped beside it, because Model Engine builds its own resource pack from the blueprints it loads, so an image outside the file is one it never sees.

Two limits worth knowing before you build on it:

Bones are flat. Our bones don't nest, so no blueprint has a bone inside a bone. Rigs animate correctly but can't do arm-inside-shoulder chains until the editor's model format gains nesting. A model you never grouped still works — everything goes into one root bone, since Model Engine needs at least one.

A hitbox bone is written, sized to the model's own bounds. Model Engine warns Missing hitbox without one and its hitbox renderer needs it. Redraw the cube in Blockbench if you want a different collision box. mount and p_* seat bones are not written — those are decisions about how an entity is ridden, which geometry can't imply.

Vanilla textures are embedded for you. Model Engine's pack contains only what the blueprints carried, so a model referencing minecraft:block/stone would otherwise have nothing to render — those images are fetched and packed into the .bbmodel alongside your own. If a texture genuinely can't be found, the face is left out of the blueprint rather than written untextured, because an untextured face stops its whole bone from rendering. The README.txt names any model that happened to.

Animations don't play on their own#

Model Engine won't start an animation just because the blueprint has one, and it has no command to play one either — /meg is reload, summon, disguise, undisguise, trait and debug, and that's the whole list. A summoned model standing still is correct behaviour, not a broken export.

What it does do is auto-play a handful of names as entity states. Its wiki lists idle, walk, jump, death and spawn.

Any other name needs something to drive it: MythicMobs mechanics, Model Engine's API, or a separate command plugin such as MEGAnim — which is not part of Model Engine and has to be installed first.

The triggers you picked in Animate mode don't come across. On loop, on right click, on range are our plugin's concept and mean nothing to Model Engine. The README.txt lists each model's animation names as exported, which is what MythicMobs wants typed.

Installing it#

The Java .zip goes in your resourcepacks folder:

# Windows
%APPDATA%\.minecraft\resourcepacks
 
# macOS
~/Library/Application Support/minecraft/resourcepacks
 
# Linux
~/.minecraft/resourcepacks

A server serves it the ordinary way, from server.properties, and that needs nothing of ours installed. A Bukkit, Spigot or Paper plugin can do the same through the resource pack API, if you'd rather send it per player or swap it at runtime. The .mcpack installs itself when opened.

There's no runtime dependency on us in any exported file. It keeps working if you never open the Studio again, animated models excepted.