Craft Queue

One player owns one queue per station. The queue is serial and single-line: only the head advances while later entries wait.

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 deadlocked by their own undelivered output and unable to queue anything. Pending claims are bounded by their own ceiling, limits.max_pending_claim, which defaults 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.

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

Tiers replace while purchases stack so that granting a player a tier afterwards does not swallow the slots they 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 the next login.

There is exactly one server-wide advance timer, controlled by queue.tick_interval (default 20 ticks), not one timer per queue.

Duration

A single craft's duration comes from the recipe's duration_seconds, multiplied by the station-level or global speed_multiplier. A duration_seconds of 0 or omitted completes immediately without entering the queue.

Cancellation and Refunds

/emakistation cancel <station> <index>

Indexes 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, applied identically to materials and to any currency already paid. Refunds always return to the channel each material came from, independent 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.

Entries in the PENDING_CLAIM state cannot be cancelled; the attempt is refused with station.cancel_pending_claim.

Claiming Outputs

/emakistation claim

One call claims every deliverable pending output the player owns across all stations. Entries that still cannot be delivered stay pending instead of failing the whole call, so this command is safe to run unconditionally.

Administrative Operations

/emakistation admin queue <...>

Requires emakistation.admin.