🪅 Custom Items

Anywhere a config asks for an item, you can name one from another plugin instead of a vanilla material. Buttons, inbox entries, letter items, server-mail attachments, the mailbox — all of them.

item: nexo:ruby
item: PAPER

material: is an alias for item:. They do the same thing.

Providers

Prefix	Plugin	Example
(none)	Vanilla	`DIAMOND_SWORD`
`nexo:`	Nexo	`nexo:ruby`
`oraxen:`	Oraxen	`oraxen:ruby`
`itemsadder:`	ItemsAdder	`itemsadder:pack:ruby`
`mythic:`	MythicMobs	`mythic:Excalibur`
`craftengine:`	CraftEngine	`craftengine:ruby`
`executableitems:`	ExecutableItems	`executableitems:mytool`
`hdb:`	HeadDatabase	`hdb:1234`
`head:`	Built in	see below

Each provider is detected at startup. One that is not installed is simply not registered — no errors, no configuration to turn off.

Player heads

head: needs no plugin at all:

Form	Gives
`head:Notch`	That player's skin
`head:self`	The skin of whoever is looking at it
`head:<base64>`	A texture value, the kind head sites hand you

head:self is resolved per viewer, so the same config line shows each player their own face.

Attachments

Server-mail attachments take the same ids, with an optional amount:

items:
  - BREAD:16
  - nexo:starter_sword
  - itemsadder:pack:token:5

The amount is the last segment, but only when it is a number. itemsadder:pack:token:5 is five of itemsadder:pack:token, while head:<base64> keeps its whole value — a base64 texture ending in digits is not mistaken for a stack size.

The blacklist

mail:
  blacklist:
    - minecraft:bedrock
    - nexo:crate_key

Same notation. A blacklisted item cannot be attached by a player.

When a provider is missing

An id that cannot be resolved becomes a barrier and logs a warning naming the id, rather than failing to load the menu.

A barrier on purpose: it is impossible to miss. A missing item that quietly became a stone button is a bug you find three weeks later; one that became a barrier is a bug you find immediately, with the id already waiting in your console.

Every supported provider is declared as a soft dependency that loads first, so this should not happen — but the fallback is there when it does.

Items already in the mail

Attachments are stored in a version-safe format, not as raw ids. A custom item sitting in an unclaimed mail survives:

a server restart,
a Minecraft version upgrade,
the item plugin being reloaded.

What it does not survive is the item being deleted from the other plugin's config. At that point the item no longer exists anywhere, and nothing the mail plugin does can bring it back.