Diagnostics Simulation en

中文 | English

CPU simulation verdicts

--simulate feeds the replayed plan into an offline cluster that mirrors the AE2UEL crafting CPU (CraftingCPUCluster) operation by operation, answering one question before a real order is placed: would a real CPU deliver this plan, or stall?

Verdicts

Verdict	Meaning
COMPLETE	a real CPU delivers the full requested amount
STALL S1	emitable residue: after delivery (or forever) entries "expected for free" are never fulfilled — the CPU stays busy indefinitely
STALL S2	starvation: a pattern's input ran out of the CPU inventory and no in-flight return can cover it (with per-input blocked evidence)
STALL S4	idle: no runnable task and no awaited return, yet delivery is short

A START-phase check S3 (extraction gap) additionally reports plan-required items missing from the snapshot stock.

Out-of-game CLI

java -cp ae2_vm_112-<version>.jar:ae2_vm_112-<version>-replay-shim.jar com.ae2vm.replay.ReplayMain trace.json.gz [--no-diff] [--no-simulate]

On Windows use ; as the -cp separator. The replay-shim jar ships with every release and bundles hand-written stubs of the few Minecraft/AE2 surfaces the replay touches plus a JSON parser — no real Minecraft jar, no mod jars needed.

Exit code	Meaning
0	the replayed plan matches the recording (and the simulation found no stall)
1	the plan diff shows differences (direct evidence of a calculation-layer problem)
2	failure (usage error / corrupt trace etc.)
3	the simulation classified the plan as a stall

Trace integrity is verified automatically: a broken hash chain or an edited payload prints a WARNING and continues with the verified prefix. When the recording and replay versions differ you get a "differences are evidence, not verdicts" note — cross-version differences are themselves evidence.

Semantics reference (simulator vs the AE2UEL CraftingCPUCluster, operation by operation)

The simulator state machine has four fields: tasks (remaining pushes per pattern), inventory (the CPU's local stock), waitingFor (expected returns), finalOutput (the delivery target). Key semantics:

AE2UEL behavior	Simulator behavior
every craft extracts ALL condensed inputs by exact key, full per-craft amount (processing patterns: no fuzz, no input classes; the damage-fuzzy fallback is craftable-only)	same: canCraft exact SIMULATE → exact extraction; slot alternates count only for craftable patterns
injectItems is waitingFor-gated with exact matching: returns nobody waits for are refused whole	same: refusals counted and shown in the verdict
returns matching finalOutput are delivered and never enter the inventory	same: delivery only comes from finalOutput matches
other awaited returns go to the CPU inventory (intermediates circulate)	same
a successful push registers condensed outputs in waitingFor	same (the virtual provider returns one step after the push)
addEmitable pre-registers "expected for free" entries in waitingFor	same (the data source of S1)
the CPU inventory is a closed local cache: only what setJob pre-extracted plus returns — no network fallback	same (the root cause of "plan feasible ≠ CPU-executable")
storeItems dumps leftover inventory back to the network on completion/cancel	not modeled: post-completion network interaction cannot change the verdict
operation budget (accelerators) / busy-medium skipping / power	not modeled: they affect pacing, not deadlock classification
submitJob's availableStorage byte-capacity check	not modeled: capacity treated as unlimited (insufficient capacity is already refused with a message by the real system)

This replication was validated by an operation-by-operation audit against the AE2UEL source; it directly proved that plans with "root output feeding its own schedule" or ring nets without startup inventory always stall a real CPU — when the simulator says STALL, that is not a simulator problem, the plan genuinely cannot run.