EmakiStation

EmakiStation is the general-purpose crafting station module of the Emaki series. It turns "submit materials against a recipe, queue the craft, collect the output later" into a configurable GUI station, and additionally ships a fully independent dismantling station.

The crafting side is a three-page window (recipe catalog → material preview → craft queue) with a serial queue. Materials are spent from a merged inventory-plus-warehouse pool, with the warehouse participating once EmakiStorage is installed. Outputs are routed to the warehouse or the inventory; when neither can accept them the entry becomes pending-claim, and nothing is ever dropped or destroyed.

Basic Information

Item	Value
Module version	1.1.0
API coordinates	emaki.jiuwu.craft:emaki-station-api:1.1.0
Main class	emaki.jiuwu.craft.station.EmakiStationPlugin
Main command	/emakistation
Aliases	/estation, /est
Required dependency	EmakiCoreLib
Optional dependencies	EmakiStorage, PlaceholderAPI
Descriptor baseline	api-version: "1.21.8", folia-supported: true
Java	Java 25
Main permissions	emakistation.use (default true), emakistation.purchase (default true), emakistation.dismantle (default true), emakistation.reload (op), emakistation.debug (op), emakistation.admin (op)

The POM/runtime/API and default config.yml version is 1.1.0. The internal AppConfig.CURRENT_VERSION = "1.0.2" is a configuration-migration structure constant; the two serve different purposes and must not be conflated.

Feature Pages

Page	Contents
Commands and Permissions	The 9 subcommands, 6 permission nodes and two access-permission prefixes of /emakistation.
Configuration	The queue, limits, storage, persistence and gui sections of config.yml.
Station Definitions	Layouts, permissions, queue parameters, material channels and output routing in stations/<id>.yml.
Recipe Definitions	Ownership, materials, outputs, duration, currency cost and the two condition gates in recipes/<recipe>.yml.
Craft Queue	The three sources of queue length, serial progression, cancellation refunds and the pending-claim state.
Paid Queue Slots	The tiers, per-slot pricing and three switches of queue_costs.yml.
Dismantling	Independent dismantle stations plus input_source, rolls and weighted pool rolling.
GUI Templates	Slot types of the four GUI templates and the "type: must be explicit" rule.
API and Integration	The facade, query and operation layers of emaki-station-api and their thread constraints.
Event API	StationCraftSubmitEvent, StationCraftCancelEvent and StationCraftCompletedEvent.

Core Capabilities

• Unordered set matching: a recipe only looks at material kinds and totals, never at placement. There is no shaped concept. item_sources is an "any of these" set whose amount is counted across the whole set, so 30 coal plus 34 charcoal satisfies a requirement of 64.
• Merged inventory and warehouse supply: when both channels are enabled, materials come from a merged pool spent inventory-first. Players see no channel toggle; the "owned" figure in the window is already the combined total.
• Serial single-line queue: one player has one queue per station, and only the head advances. waiting and running occupy queue length while pending_claim does not.
• Three sources of queue length: the base length, the emakistation.queue.<n> permission tier, and paid purchases. The tier replaces the base length, purchased slots stack on top, and the result is clamped by max_length.
• Outputs are never lost: when every configured target is full, the entry turns into pending-claim and waits for /emakistation claim or the in-window button.
• Dismantling is fully independent: dismantle station ids are unrelated to crafting station ids and load from their own stations_dismantle/ and recipes_dismantle/ directories. It is not a fourth page of a crafting station.

File Layout

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

plugins/EmakiStation/
├─ config.yml
├─ queue_costs.yml
├─ stations/
│  └─ blacksmith.yml
├─ recipes/
│  └─ example_recipe.yml
├─ stations_dismantle/
│  └─ example_dismantle_station.yml
├─ recipes_dismantle/
│  └─ example_dismantle_recipe.yml
├─ gui/
│  ├─ station_catalog.yml
│  ├─ station_preview.yml
│  ├─ station_queue.yml
│  └─ station_dismantle.yml
└─ lang/
   ├─ zh_CN.yml
   └─ en_US.yml

Path	Description
config.yml	Main configuration: queue defaults, capacity limits, warehouse channel, persistence, GUI throttling.
queue_costs.yml	Paid queue slot tiers. A business data file: released once when missing, never overwritten by version upgrades.
stations/<id>.yml	Crafting station definition. The file name matches id.
recipes/<recipe>.yml	Crafting recipe definition. One recipe per file; ownership is declared recipe-side via station_ids.
stations_dismantle/<id>.yml	Dismantle station definition, unrelated to crafting stations.
recipes_dismantle/<recipe>.yml	Dismantle recipe definition with an input item and a weighted output pool.
gui/*.yml	Four window templates: recipe catalog, material preview, craft queue, dismantle window.
lang/*.yml	Command, window, precheck and console messages.

Getting Started

1. Put EmakiCoreLib-*.jar and EmakiStation-*.jar into the server plugins/ folder.
2. Do not put emaki-station-api-*.jar into plugins/; the API Jar is a compile-time dependency for developers only.
3. After the first start, review plugins/EmakiStation/config.yml and the example station stations/blacksmith.yml.
4. Open the example station:

/emakistation open blacksmith

5. Inspect your queue and claim outputs:

/emakistation queue
/emakistation claim

6. Reload after editing configuration:

/emakistation reload

Usage Notes

• channels.backpack and channels.storage must not both be false, or the station is refused at load time. A station that opens but can never be used is worse than a startup error.
• channels.default is a retained key that no longer has any effect. Once the channels were merged there is no such thing as "which channel you are on"; it only remains so old configuration files do not report an unknown key.
• Besides storage.enabled: true, the warehouse channel also requires EmakiStorage to provide the emakistorage:atomic_batch capability. Without it there is no fallback to withdrawing item by item, because that would make materials flash through the player's inventory.
• progress_mode: offline only means "the timer keeps running", not "delivery while offline". Entries that come due while the player is offline are merely due; settlement happens at their next login.
• All three layout files (layout, preview_layout, queue_layout) must exist. A missing one raises missing_layout in the startup precheck.
• Material allocation is greedy with no backtracking. When one item can satisfy several requirements it goes to the one declared first, which in rare cases makes a theoretically valid recipe fail to match. Splitting the recipe avoids it.