Skip to content

Configured Custom Items

Configured custom item support is available in the current technical-preview line. It lets a server owner define an item in items.yml, choose its Bukkit base material, and optionally add matching rules such as CustomModelData, display name, and lore.

The first version is designed for configured custom items, not automatic detection of every custom-item plugin. In practice, that means the server owner defines an item in items.yml, tells DynaTrade which Bukkit base material it uses, and optionally adds matching rules such as CustomModelData, display name, and lore.

What The Feature Is Meant To Do

DynaTrade's current public item model is based on Bukkit Material names such as DIAMOND, COAL, or IRON_INGOT. That works for vanilla items, but resource-pack items often use a normal base material like PAPER and change the client-side texture through CustomModelData.

Configured custom item support adds a safer identity layer:

  • DynaTrade can price custom_ruby as its own market item.
  • The actual Minecraft item can still be a PAPER stack.
  • A resource pack can render that PAPER stack as a Ruby when the configured model data is present.
  • Buying the market item gives the player the configured base item with the configured metadata.
  • Selling only succeeds when the player's item matches the configured identity rules.

This lets custom economy items participate in the same dynamic market as vanilla items without treating every plain PAPER item as valuable.

Example

A configured custom item can look like this:

items:
  custom_ruby:
    material: PAPER
    custom-model-data: 1001
    display-name: "Ruby"
    match-display-name: "Ruby"
    lore-match:
      - "A rare custom gemstone"
    base-price: 250.0
    category: MINING
    description: "A resource-pack-backed ruby traded through the market."

In that example:

  • custom_ruby is the market key players would use in commands.
  • material: PAPER is the real Bukkit item type.
  • custom-model-data: 1001 is what a resource pack can use to show a Ruby texture.
  • display-name is the name shown by DynaTrade.
  • match-display-name and lore-match are sell-side safety checks.
  • category: MINING controls market grouping and category text; it should not replace the configured item icon.

How It Should Look In /market

The market GUI is expected to render the configured item stack, not just the category icon.

For the Ruby example:

  • without a resource pack, players would see a PAPER item named Ruby
  • with a resource pack that maps PAPER + CustomModelData 1001, players would see the Ruby texture
  • the item would still be grouped under its configured category, such as Mining
  • the category affects organization and lore, not the custom item texture itself

If the resource pack is missing or the client did not accept it, the server can still create the item correctly, but the player may only see the base material.

Buy And Sell Behavior

The intended behavior is:

  • /buy custom_ruby 1 creates the configured item stack and applies normal DynaTrade buy pricing.
  • /sell custom_ruby 1 checks the player's inventory for matching items and applies normal DynaTrade sell pricing.
  • A plain base item should not count as the custom item if matching rules are configured.
  • Full inventories should use the same pending delivery system as normal buys.
  • Analytics, price history, and GUI listings should treat the custom key as its own market item.

This keeps market accounting attached to the custom key, not merely to the base material.

Matching Rules

Matching is expected to be strict and predictable:

Rule Meaning
Base material The item must use the configured Bukkit Material.
CustomModelData If configured, the item must carry the exact same integer value.
Display name If configured, the item name must match exactly.
Lore If configured, lore lines must match exactly and in order.

If a match field is omitted, that field is not checked. Server owners should configure at least one strong match field, usually custom-model-data, to avoid accepting plain base-material items.

External Item Provider Foundation

DynaTrade also includes the foundation for future external item providers. It can represent an item with a provider ID, namespace, and external item ID; providers can report their availability and capabilities; and matching fails closed when more than one provider recognizes the same stack.

This foundation does not automatically discover or trade third-party plugin items yet. It is an integration boundary, not a completed ItemsAdder, Oraxen, MMOItems, or MythicMobs connector.

What This Does Not Promise

The first public version is not intended to mean universal custom-item compatibility.

Not promised in the first version:

  • automatic ItemsAdder item discovery
  • automatic Oraxen item discovery
  • automatic MMOItems item discovery
  • automatic MythicMobs item discovery
  • full NBT matching
  • full component matching
  • modded item ecosystem support

Those belong to later compatibility work after the configured custom item path is stable.

Current Public Status

Configured Bukkit-backed custom items are available in the current technical preview. External provider identity support is present as a safe foundation only; concrete third-party integrations remain future work.