Create:Productionline

The second 1.0.3 snapshot: the whole line so far, for an in-game pass before the release cut. 1.0.3-snapshot.0.0.1 carried the recipe-refresh work alone; this one adds everything the line has produced since — the three redrawn machines (Production Computer in 0.0.0-dev.5, Scheme Loader with its fill bar and Dismantler in 0.0.0-dev.6), the normalised texture names, the GUI layout pass, the dismantler's decision table and the computer's private chat output. See the 0.0.0-dev.N sections below for the per-build detail. 1.0.2 remains the current stable release; a snapshot is a work in progress towards 1.0.3, not a finished line.

Fixed

• A carrier's build guide was written but never shown. The Production Computer writes the plan and the LineBuildGuide onto the same carrier (paper takes both), but the tooltip returned right after the plan block, so the guide could never be reached on exactly the items it exists for — and the three guide.* hint lines were dead text because of it. The tooltip now renders the guide block after the plan and uses those localised build instructions (belt first, one Deployer per material facing down, where the product comes out, and the return belt a repeating line needs), gated so a single-machine plan is not given assembly-line advice it cannot use. The stored LineBuildGuide payload is unchanged — it stays the machine-readable record carriers are recognised by.
• The Scheme Loader's bar grew from the wrong end. The six strips had been ordered left→right as bar_1 … bar_6, which inverts the author's layout: in the Blockbench export the rightmost strip (x=13) already carried bar_1 and the leftmost (x=3) carried bar_6 (with one mis-dragged placeholder in between). The bar now fills from the right, and each stage keeps the rightmost N strips (scheme_loader_bar_1 draws x=13, bar_2 adds x=11, and so on). The fill arithmetic is unchanged: segments = ceil(count * 6 / 16). Spotted in game — the direction is the one thing no headless check could have caught.
• All three GUIs had their contents laid out against the wrong reference. The backgrounds are hand-drawn and each has a recessed well near the top; the code had been placing cells and text by hand, so: the Scheme Loader's 2×8 grid sat flush left inside its well (an 18 px hole on the right, and the grid 2 px high vertically) with its first status line printed on the well's bottom edge; the Dismantler's two slots hugged the ends of their well (no margin at all, 1 px from the top) and its hint text was drawn at y=40, straight across the well and both slots; the Production Computer's three slots were 2 px high and its status list could grow to a fifth row on the player-inventory groove and the "Inventory" label. Every cell grid is now centred in its well, every text row starts below the well and stops above the groove or the button. The numbers live in one place (menu/GuiLayout) that both the menus and the screens read, and the self test asserts the invariants — a layout drift is invisible to every resource check we have and only shows up in game.
• A refused dismantle was silent. The button promised "materials back + mirror" but pressing it with an unmatched item, a plain intermediate, a missing recipe or too few items for one batch did nothing at all, with no clue why. DismantlerBlockEntity.revert() now returns a typed result (RevertResult.DONE / NOTHING_HELD / NO_PROVENANCE / RECIPE_MISSING / OUTPUT_MISMATCH / NOT_ENOUGH / NOT_REFUNDABLE) and the server answers the player who pressed it, privately, with the matching reason.
• The dismantler's hint overstated the scheme slot. It read "right slot = scheme" while the scheme is optional (a mirror snapshot is synthesised from the recipe when the slot is empty) and did not say where the refunds go — they are dropped beside the machine. Both languages now say the slot is optional, and that a scheme in the item slot is erased rather than refunded.
• A refund was not the inverse it claimed to be for recipes that consume their own product. The refund list dropped any input equal to the product, so 1 A + 1 B = 2 A consumed 2 A and returned only B — eating an A. The product now stays in the refund list, which makes the batch a true inverse (2 A -> 1 A + 1 B) and, as before, never lets a count > 1 recipe be farmed one item at a time. The self test dismantles a real doubling recipe and counts the dropped items. The refund is still a set of unique materials, one each rather than one per recipe slot — 2 planks -> 4 sticks hands back a single plank. That is deliberate and now documented in docs/usage.md and docs/security.md: what prevents farming is the batch rule (consume >= count), not the size of the refund, while an unfinished intermediate keeps counting per deploy step so nothing it absorbed is lost.
• Fluid-form ingredients vanished without a word. A fluid cannot exist as an item, so it can never be part of a refund — but the player used to get no hint at all that part of the recipe was not coming back. The dismantler now counts the fluid ingredients of the source recipe and says so (另有 N 项流体原料无法退还 / "Another N fluid ingredient(s) could not be refunded"). A pure-fluid recipe still refuses outright (NOT_REFUNDABLE) without consuming anything.

Added

• The Dismantler erases a written Line Scheme back to a blank one. A plan costs nothing to author — the Production Computer only writes onto the carrier, it consumes no materials — so a scheme that is no longer wanted should not be a dead item. Put one into the item slot and press Dismantle: the plan is erased and a fresh blank scheme takes its place. A blank scheme has nothing to erase and a mirror is a read-only snapshot; both are refused with their own message instead of being mistaken for a product that does not match the plan.
• The Production Computer reports its result in the player's chat. The panel can only show four rows between its button and the inventory groove, so the same status list (product, target output / repeat budget, material budget, plan size, embedded recipe count) is now also sent — privately, to whoever pressed Compute, never as a broadcast — as chat lines. The list is built once (menu/ComputerStatus) and used by both the screen and the server, so panel and chat can never drift apart. A long plan is no longer truncated away.
• Self test grew to 23 checks (was 20): GUI layout fits the drawn wells asserts that every slot grid is centred inside its well and that text starts below the well and stays clear of the button and of the player-inventory groove; Dismantler decision table, doubling refund, fluid notice places a real dismantler, runs a real 1 A + 1 B = 2 A recipe through it and counts the items that actually dropped; and Computer writes plan + guide onto both carriers drives a real Production Computer and asserts both carriers end up holding the plan and the build guide — the data side of the tooltip fix above.