Item Source

Use CoreLib Item Source to describe an item with a fixed source type plus ID, instead of relying on display names or lore; where to look up each source's ID is covered in its own section below

Supported sources

ItemSourceKind is a record rather than an enum, written namespace:id. A blank namespace becomes emaki. That design is deliberate: it lets a third-party plugin mint its own source kind. Whoever supplies the ItemSourceProvider declares the kind and its dash-shorthand prefixes in the same registration, using its own namespace

The eight built-in constants CoreLib implements itself all live in the emaki namespace:

Constant	Kind key	Aliases	Description
VANILLA	emaki:vanilla	vanilla, minecraft, mc, v	Vanilla Minecraft items; also the fallback for bare text
CRAFTENGINE	emaki:craftengine	craftengine, ce	CraftEngine custom items or blocks
ITEMSADDER	emaki:itemsadder	itemsadder, ia	ItemsAdder custom items
NEIGEITEMS	emaki:neigeitems	neigeitems, ni	NeigeItems items
MMOITEMS	emaki:mmoitems	mmoitems, mi	MMOItems items
NEXO	emaki:nexo	nexo, no	Nexo items
ORAXEN	emaki:oraxen	oraxen, ox	Oraxen items
ECOITEMS	emaki:ecoitems	ecoitems, eci	EcoItems items

There is deliberately no EMAKIITEM constant: its resolver lives in the EmakiItem module, so its kind and prefixes are declared there as ItemSourceKind.of("emakiitem:emakiitem"), with emakiitem and ei as config aliases

Type names are case-insensitive. Which sources you can actually use depends on which plugins are installed; an uninstalled source cannot create or recognise its items

Type aliases and dash-shorthand prefixes are not identical: the type: field accepts every alias above, while the dash shorthand accepts minecraft-, mc-, v-, craftengine-, ce-, itemsadder-, ia-, neigeitems-, ni-, mmoitems-, mi-, emakiitem-, ei-, nexo-, no-, oraxen-, ox-, ecoitems-, and eci- (there is no eco- shorthand)

Object format

The object format uses type plus identifier; both must be non-blank:

item:
  type: vanilla
  identifier: diamond

MMOItems requires a <type>:<item> identifier:

item:
  type: mmoitems
  identifier: SWORD:FLAME_SWORD

When resolving an object node, CoreLib checks item_sources first, then the string field item (parsed as dash shorthand), then a nested source, and only then falls back to type + identifier

Vanilla identifiers are normalised to lowercase and may only contain lowercase letters, digits, and underscores; a minecraft: namespace prefix is rejected

Dash shorthand format

Some modules — Cooking in particular — use the dash shorthand:

input:
  item_sources:
    - minecraft-diamond
    - emakiitem-flame_blade
    - craftengine-custom_block

The form is source-type-itemID, separated by a hyphen

Legacy colon format (not recommended)

# Not recommended: easily conflicts with namespace resolution rules
item: minecraft:diamond

Use the object format or the dash shorthand in your new configurations

Resolution priority

When several plugins can identify the same item, CoreLib tries resolvers in descending priority, breaking ties by resolver ID:

Resolver	priority
NeigeItems	102
CraftEngine	101
MMOItems	100
EmakiItem (registered by EmakiItem)	100
ItemsAdder	98
Nexo	97
Oraxen	96
EcoItems	95
Vanilla (fallback)	0

Unified item definitions

CoreLib GUI slots and EmakiItem base items share ConfiguredItemDefinition. In YAML the source lives at item.source:

item:
  source: itemsadder-custom_items:ruby_sword
  amount: 1
  components:
    custom_name: '<red>Ruby Sword</red>'

item.source accepts every ItemSource shorthand currently registered in CoreLib. EmakiItem validates that the resolver is available and can create the base item before caching a definition. For third-party sources, component application preserves source identity, PDC, and unknown components, and transfers only patches that the current Paper runtime can safely handle

Finding the ID for each source

Vanilla

Use the Bukkit Material enum name with underscores. Identifiers are normalised to lowercase, so either case is accepted as input:

diamond_sword, iron_chestplate, golden_apple, netherite_axe

The dash shorthand accepts minecraft-, mc-, and v-. See the Spigot Material docs for the full list

EmakiItem

Use the id field defined in plugins/EmakiItem/items/*.yml:

# items/flame_blade.yml
id: flame_blade

Reference it as the shorthand emakiitem-flame_blade, or in object form as type: emakiitem plus identifier: flame_blade

CraftEngine

Use the item ID registered with CraftEngine, which its own commands can list

ItemsAdder

Use the ItemsAdder namespaced ID, usually namespace:item_id:

item:
  type: itemsadder
  identifier: custom_items:ruby_sword

Nexo

Use the item ID registered with Nexo

MMOItems

Give both the item type and the ID in identifier, separated by a colon:

item:
  type: mmoitems
  identifier: SWORD:FLAME_SWORD

NeigeItems

Use the item ID from the NeigeItems configuration

Common use cases

Recipe materials

Forging, strengthening, cooking, and gem upgrading all need to recognise materials. Materials must be identified reliably, otherwise players may bypass a recipe with the wrong item or fail to submit the right one

materials:
  - item:
      type: vanilla
      identifier: blaze_rod
    amount: 3
  - item:
      type: emakiitem
      identifier: strengthen_stone
    amount: 1

Granting rewards

The action system or a recipe result may create items. State the source and ID explicitly so the reward is not granted as a plain vanilla item

actions:
  - 'create_item id=reward source=emakiitem-flame_blade amount=1'
  - 'send_item id=reward'

Condition checks

The condition system can check the item source of what the player holds, carries, wears, or has in a GUI input slot, to gate recipes, skills, sets, or quests

World station detection

Cooking can recognise blocks or related items through CraftEngine, ItemsAdder, Nexo, and similar ecosystems to implement custom stations. The same CE / ItemsAdder / Nexo item sources can also be handed to the place_block action to try placing them as custom blocks

stations:
  chopping_board:
    block_item_sources:
      - craftengine-cutting_board

Tool detection

Some stations require a specific tool to operate:

tool_item_sources:
  - minecraft-iron_axe
  - minecraft-diamond_axe
  - minecraft-netherite_axe

Why not to rely on display names

• A display name can be changed by an anvil, a plugin, or the language system
• Lore may be rebuilt by the Attribute, Forge, Strengthen, or Gem modules
• Colour codes, MiniMessage, and legacy colour symbols make text inconsistent
• Players may obtain a similarly named item some other way
• A display name can change on update while the ID stays stable

Advice

Use stable IDs for recipe materials, rewards, conditions, and station matching. Avoid judging items by display name or lore because they may be modified by other plugins or rebuilt by CoreLib Assembly

Writing IDs that contain hyphens

The dash format is not "split on the first hyphen"; instead the whole string is matched against the set of registered prefixes, and once a prefix hits, everything after it is taken as the ID. So an item ID that itself contains hyphens still resolves correctly:

# Resolves correctly: the emakiitem- prefix hits, so the ID is my-custom-item
item_sources:
  - emakiitem-my-custom-item

# The equivalent object format keeps source and ID apart, which is clearer
input:
  type: emakiitem
  identifier: my-custom-item

Only when the ID itself starts with another registered prefix does priority matter; switching to the object format then removes the ambiguity entirely