Cross-module Integration

Other modules reference EmakiItem items — in recipes, gems, strengthening, skills, and elsewhere — by item id with a source prefix. The Item module is a shared source for equipment, materials, consumables, and display items, and other modules reference it through CoreLib item sources; use the shorthand format emakiitem-item_id

Common integration points

Scenario	Recommended approach
Recipe material	Reference the EmakiItem id in item_sources
Equipment base	Store attributes, components, set data, triggers, and PDC in the item definition
Skill consumable	Check item source in skill conditions or actions
Gem or strengthen material	Use stable ids instead of display name or lore matching

Forge example

materials:
  - item_sources:
      - "emakiitem-shadow_ingot"
    amount: 3
    capacity_cost: 5

Gem example

In a gem definition, base_item_source builds the gem and the sibling item_sources recognises it; fill in both:

id: "ruby_t1"
display_name: "<red>Ruby I</red>"
gem_type: "attack"
base_item_source: "emakiitem-ruby_t1"
item_sources:
  - "emakiitem-ruby_t1"
socket_compatibility:
  - "attack"
  - "universal"

Socket item configuration uses the top-level item_sources, matcher, and slot_groups to decide which equipment can have sockets. All three are ANDed:

slot_groups:
  - "weapon"

item_sources:
  - "emakiitem-shadow_blade"

The old match block is no longer read; migrate it following Socket item definitions

Strengthen example

stars:
  1:
    materials:
      - item_sources:
          - "emakiitem-strengthen_stone"
        amount: 1

Item layer preview providers

The item layer preview SPI is owned by EmakiItemApi. Third parties register through EmakiItemApi.extensions().registerLayerPreview(owner, provider), and the returned handle implements AutoCloseable. See API for the interfaces and registry semantics

The built-in layer ids are strengthen and gem, registered by EmakiStrengthen and EmakiGem from their conditionally loaded integration packages. Those lifecycles listen for PluginEnableEvent / PluginDisableEvent and reflectively register the provider only while EmakiItem is enabled, degrading to a no-op when EmakiItem is absent so no hard dependency is introduced. When a module is not loaded, its layer appears as an unavailable placeholder while the other layers still compute; when troubleshooting, first check whether the target module is loaded

Skill PDC and the protocol module

Write convention: Item does not check whether EmakiSkills is enabled when writing equipment skill ids and forced equipment triggers. Those PDC keys are owned by emaki.jiuwu.craft.skills.api.pdc.EquipmentSkillPdcCodec in EmakiSkillsApi and shaded into Item's own jar, so the skill payload is still written and cleared even when EmakiSkills is not installed; EmakiSkills reads it once equipped

PDC and lore

Config convention: use PDC as the real data layer and lore as presentation only, so language, color, or external lore changes cannot break gameplay logic

Troubleshooting

• Item not recognized: confirm the EmakiItem stable ID was written to PDC
• Recipe material cannot be submitted: check that item_sources uses the correct source prefix
• Items created by external plugins are not equivalent to EmakiItem items unless they carry the matching PDC identity