Craft Queue

You get one queue per station. The queue is serial and single-line: only the head entry advances, and the rest wait in line

Entry States

State	Occupies queue length	Description
WAITING	Yes	Submitted and waiting in line
RUNNING	Yes	At the head, advancing its duration
PENDING_CLAIM	No	Finished, but the output could not be delivered; waiting to be claimed

PENDING_CLAIM deliberately does not occupy queue length. Otherwise, a player whose warehouse and inventory are both full would be blocked by their own undelivered output and unable to queue anything. Pending claims have their own ceiling: limits.max_pending_claim, defaulting to 100

The Three Sources of Queue Length

Source	Relation to base length	Configured in
Base length	The starting point	queue.base_length in config.yml, overridable per station
Permission tier	Replaces it	emakistation.queue.<n>, requires queue.permission_tiers: true
Paid purchase	Stacks on top	Bought on the queue page, see Paid Queue Slots

Your highest numbered tier wins; with no such permission the base length is kept. Purchased slots stack on top of the effective tier, and queue.max_length clamps the result

Tiers replace while purchases stack, so a tier granted later never swallows the slots a player paid for

Progression

queue.progress_mode decides how the head is timed:

Value	Behaviour
offline	Follows real time; the timer keeps running while the player is offline
online	Only accumulates while the player is online

offline only means "the timer keeps running", not "delivery while offline". EmakiStorage refuses any write for an offline player, so entries that come due while offline are merely "due"; settlement happens at your next login

Only one advance timer runs for the whole server, controlled by queue.tick_interval (default 20 ticks) -- there is not one timer per queue

Boundary for old queue saves

QueueStore has source-level defaults for missing material identity fields, but this cycle did not verify cross-version recovery of old queue YAML or persisted saves on a live Paper or Folia server. Back up data/ and sample-test queue entries, material identities, and pending outputs on the target server before upgrading

Duration

One craft's duration comes from the recipe's duration_seconds, multiplied by the station-level or global speed_multiplier. Set duration_seconds to 0 or leave it out, and the craft completes immediately without entering the queue

Cancellation and Refunds

/emakistation cancel <station> <index>

Index numbers in commands and in the window start at 1 (the API's index parameter starts at 0)

The refund fraction comes from the station's queue.cancel_refund_rate, and materials and any currency already paid use the same rate. Refunds always go back to the channel each material came from, regardless of the station's output routing

Refunds are not prorated by progress. In a serial single-line queue only the head has progress, and per-entry progress accounting for an almost non-existent case is not worth it. This is an intentional simplification

A partial refund still reports success and carries the shortfall as a Partial reason key

You cannot cancel an entry in the PENDING_CLAIM state; the attempt is refused with station.cancel_pending_claim

Claiming Outputs

/emakistation claim

One call claims every deliverable pending output you own across all stations. Entries that still cannot be delivered simply stay pending instead of failing the whole call, so it is safe to run this command any time

Administrative Operations

/emakistation admin queue <...>

This one requires emakistation.admin

Failure Reason Keys for Cancel and Claim

Cancelling from a command, the window or the API can return: station.queue_not_loaded (queue data not loaded yet), station.queue_entry_missing (no such index), station.cancel_pending_claim (the entry is pending-claim), station.cancel_vetoed (vetoed by StationCraftCancelEvent), and station.refund_partial (a partial refund was refused; the call still reports success and carries the shortfall)

Claiming can return station.queue_not_loaded; on success it reports the number of entries actually cleared, and entries that still cannot be delivered remain pending-claim