Pack Creation

Pack Creation

SkinEngine pack creation is easiest to understand if you split it into four separate systems:

  • pack.yml defines the pack entry shown in the GUI
  • configs/skins/*.yml defines actual cosmetic content
  • configs/decorative_items.yml defines helper item-models, usually for GUI visuals
  • configs/images.yml defines font-backed images and bitmap slices for titles and text graphics

That split is intentional. The plugin loads those systems separately, validates them separately, and uses them in different places at runtime.

What a full pack can contain

A full custom pack can contain:

  • pack.yml
  • configs/skins/*.yml
  • configs/images.yml
  • configs/decorative_items.yml
  • resourcepack/skins/...
  • resourcepack/images/...
  • resourcepack/decorative_items/...

The minimum working pack is smaller:

  • pack.yml
  • one skin file
  • one matching folder inside resourcepack/skins/

Everything else is optional and can be layered in later.

Read this section in order

If you are building a pack from scratch, this is the easiest reading order:

  1. Pack Workflow
  2. Pack Structure
  3. Pack Metadata
  4. Skin Files
  5. Skin Categories
  6. Skin Particles
  7. Decorative Items
  8. Images and Font Assets
  9. Example Custom Pack

Supported skin categories

SkinEngine currently supports these item keys in skin files:

  • sword
  • mace
  • trident
  • axe
  • pickaxe
  • shovel
  • hoe
  • spear
  • bow
  • crossbow
  • fishing_rod
  • shield
  • elytra
  • helmet
  • chestplate
  • leggings
  • boots

The plugin maps those from real Bukkit materials. The exact matching rules and state-specific resources are documented here:

What creators usually get wrong

Most pack problems come from mixing up the responsibilities of the three resource folders:

  • resourcepack/skins/ is for real skin resources
  • resourcepack/decorative_items/ is for GUI item-model assets
  • resourcepack/images/ is for font images and title graphics

If a pack feels messy, it usually means content from one of those systems ended up in the wrong place.

Build packs in layers:

  1. get one skin working
  2. add more categories
  3. add particles if the skin needs them
  4. add decorative GUI assets
  5. add title images and polish

That flow matches how the plugin itself is structured, and it makes troubleshooting much easier when something goes wrong.