EmakiAccessory

EmakiAccessory is the accessory slot module of the Emaki series. Install it and players get their own accessory panel -- a separate GUI (graphical user interface) window that occupies no vanilla equipment slot, while accessories worn in it still provide attributes and skills

The panel can have multiple pages: parts.yml defines the global parts and slot instances, pages/*.yml decides which parts each page enables, and gui/accessory_gui.yml describes the layout. Each page stores its own copy and never overwrites another, but only the currently enabled page produces attributes, skills, and set piece counts (how many pieces of one set are worn). You do not need to configure extra slots in EmakiAttribute or EmakiSkills -- accessory attributes and skills connect to those modules automatically

Basic Information

Item	Value
Module version	1.1.8
API coordinates	emaki.jiuwu.craft:emaki-accessory-api:1.1.7
Main class	emaki.jiuwu.craft.accessory.EmakiAccessoryPlugin
Main command	/emakiaccessory
Aliases	/eaccessory, /eacc
Required dependency	EmakiCoreLib
Optional dependencies	EmakiItem, EmakiAttribute, EmakiSkills, PlaceholderAPI
Descriptor baseline	api-version: "26.1", folia-supported: true
Java	Java 25
Main permissions	emakiaccessory.use (default true), emakiaccessory.reload (op), emakiaccessory.debug (op), emakiaccessory.admin (op), emakiaccessory.admin.edit (op), emakiaccessory.page.secondary (op, example page permission)

Feature Pages

Page	Contents
Commands and Permissions	Subcommands, page retrieval, administrative commands, and the 6 permission nodes of /emakiaccessory
Configuration	Slot sources, durability switch, death drops, deduplication, and persistence in config.yml, plus the fields of pages/*.yml
Parts and Slots	Part definitions in parts.yml, slot instance expansion and orphaned slots
Accessory Sets	Members, slot criteria, piece thresholds and effects in sets/<set>.yml
GUI Template	The four slot types and page switching cells of gui/accessory_gui.yml
Attributes and Skills	How accessory attributes reach EmakiAttribute and skills reach EmakiSkills
API and Integration	The facade and query layer of emaki-accessory-api and their thread constraints
Event API	AccessorySetBonusChangeEvent

Core Capabilities

• Separate accessory panel: the accessory panel is its own GUI. It occupies no vanilla equipment slot and shares no slot with EmakiItem equipment
• Multiple pages with isolated storage: pages/*.yml defines the pages, and the same slot instance id holds a separate accessory on each page without overwriting
• Only the enabled page contributes: accessories on other pages keep their data but stop providing attributes, skills, and set piece counts; the page_enable cell switches the active page
• Pages can be permission-gated: a non-empty page permission is matched verbatim. Losing it clears no data and does not switch pages; the player recovers items with /eacc retrieve <page>
• Parts expand into slot instances: a part configured with count: 2 in parts.yml expands into the slot instances ring_1 and ring_2, with one window cell per instance
• Attributes parsed by the same code as equipment: accessory attributes go through EmakiAttribute's own parser, so an accessory and a helmet carrying identical data produce identical numbers, with parent-attribute expansion and range-spread companion keys coming along
• Thresholds are cumulative: set tiers stack. Wearing 3 pieces activates the 2-piece and 3-piece tier at the same time, not one instead of the other
• Accessory sets never mix with equipment sets: accessory sets only count pieces inside accessory slots while EmakiItem only counts the equipment slots. One item may belong to both, and each side counts independently
• Orphaned slots keep their data: you can shrink count, delete a part, or remove a part from a page without deleting anything. Accessories in a slot that page no longer declares become "orphans" and appear in that page's orphan area for retrieval. The check is per owning page, so accessories on other pages are never treated as orphans
• Administrators can view and edit: /eacc admin view is a read-only view, while /eacc admin edit additionally requires emakiaccessory.admin.edit
• Only explicitly declared accessories are accepted: an item must declare the accessory slots it may enter through EmakiItem's accessory_slot effect. The declaration is written to item PDC (plugin-defined data, the hidden fields a plugin stores on an item) under emakiitem:accessory_slots. Items without a declaration, or whose declaration does not match the cell, cannot be placed; a stored item that no longer matches is returned to the player's inventory with a message when the window closes
• Condition and durability gating: accessories are gated by their own EmakiItem definition condition, and once durability is exhausted their attributes, skills and set piece count all stop applying while the item stays in its cell with a status marker. Durability deduction is controlled by durability.enabled and is disabled by default

File Layout

After the server has run, EmakiAccessory mainly uses the following files:

plugins/EmakiAccessory/
├─ config.yml
├─ parts.yml
├─ pages/
│  ├─ main.yml
│  └─ secondary.yml
├─ sets/
│  └─ example_set.yml
├─ gui/
│  └─ accessory_gui.yml
└─ lang/
   ├─ zh_CN.yml
   └─ en_US.yml

Path	Description
config.yml	Main configuration: slot sources, durability switch, death drops, deduplication, persistence
parts.yml	Accessory part definitions, deciding which slot instances exist globally
pages/<page>.yml	Accessory page definition. The id comes from page_id, not the file name; parts decides which parts that page enables
sets/<set>.yml	Accessory set definition. One set per file; the file name is not used for identification
gui/accessory_gui.yml	Accessory panel window template, shareable across pages
lang/*.yml	Command, window and console messages

Getting Started

1. Put EmakiCoreLib-*.jar and EmakiAccessory-*.jar into the server plugins/ folder
2. To make accessories grant attributes and skills, also install EmakiAttribute and EmakiSkills, and define the accessory items with EmakiItem — remember to declare the slots they may enter with type: "accessory_slot" inside the definition's effects, otherwise they cannot be placed
3. Do not put emaki-accessory-api-*.jar into plugins/; the API Jar (the interface package developers compile against) is a compile-time dependency only and never runs on the server
4. After the first start, review plugins/EmakiAccessory/parts.yml, pages/main.yml, and gui/accessory_gui.yml
5. Open your own accessory panel:

/eacc open
/eacc open secondary

6. Inspect all pages and the currently enabled one:

/eacc pages

7. Reload configuration, parts, pages, and sets after editing:

/eacc reload

Usage Notes

• After you change parts or count in parts.yml, place a cell with type: "accessory_slot" and the same key name in gui/accessory_gui.yml for every expanded slot instance, otherwise players cannot use that slot. Also make sure the target page declares that part in its parts list
• Attributes, skills, and set piece counts only count the currently enabled page. Accessories on a page take effect only after the player switches to it
• unique: true (only one copy of the same accessory per page) is judged by EmakiItem's item definition id where available, and compared within one page only. It does not switch off when EmakiItem is absent; it falls back to vanilla material matching, so two accessories of the same material count as duplicates
• pieces[].item in accessory sets also depends on EmakiItem definition ids; the whole set is inactive when EmakiItem is absent
• A part id must not end with _<number>, which would collide with slot instance ids
• /eacc retrieve <page> takes back every accessory on that page (declared slots and orphan slots alike), which makes it the fallback when a page cannot be opened
• /eacc admin edit only works for online players; /eacc admin clear cannot be undone and is written to the log, so confirm before running it
• EmakiSkills is an optional dependency: without it, accessory and set skills simply do not apply while the module enables normally (the skills integration is loaded reflectively by class name)