Create:Productionline

Fixed

• Intermediates could not be dismantled at all. The intermediate branch keyed on our item (Generic Intermediate), so every Create-native transitional item — whose provenance is the SEQUENCED_ASSEMBLY component on the item itself — fell through to the finished-product path, where it could only ever answer "no recipe for it". The branch now keys on the component, which is what actually records provenance: anything carrying it is refunded from the sequence recipe it names (base + the steps that already ran), while our own item without the component is still refused as "no processing record". A refusal now also names the recipe it could not find. RecipeJsonReader.sequenceParts was hardened at the same time: an alternatives array resolves to its first usable entry, and when a recipe writes no ingredient at all the base is taken from the first sequence step's ingredients[0] — that slot is the item entering the line.
• The compute result never reached the player's chat. The run is queued for the next tick after the button press, so reading the status in the same tick always saw RESULT_EMPTY and sent the "how to use me" line instead of the outcome. The computer now remembers who asked (by UUID) and reports the real status — product, incremental marker, target output, material budget, plan size, embedded recipes — once the run has finished.
• A dismantle's materials landed on the floor. They now go into the inventory of the player who pressed Dismantle (anything that does not fit falls at their feet); only the no-player path — the self test, scripted use — still pops them at the block.
• A scheme that cannot avoid referencing itself did not say so. 1A + 1B = 2A and friends are incremental lines: they run from a single seed item, which the numbers alone never explained. The scheme tooltip and the computer's chat/panel now state it — 该物品无法避免自引用，已转换为增量配方.
• A material the line merely uses read as one it consumes. A Deployer holding an item applies it in USE mode, so a smithing recipe's base (the equipment being upgraded — the diamond sword on its way to netherite) stays on the line and is never consumed, yet the plan chain listed it like any other input. The computer now records those materials on the scheme (SchemeRoles, taken from the source recipe's own roles) and the chain marks them （不消耗）. The steps alone cannot express that difference, and nothing else knows the recipe's roles once the plan has been written.
• The Scheme Loader's title was pressed by its own panel. That background's well starts at y=13 (the other two start lower) and a glyph is 8 px tall: at y=6 the title's bottom row sat exactly on the well's top edge. The title moved up one row and the self test now asserts the clearance.
• The build-guide block is gone from the tooltip, by request: its hand-written hint lines were generic boilerplate ("belt first, one Deployer per material…") that said nothing about the plan at hand. The LineBuildGuide payload is still written — it is what makes a plain item a carrier — it is simply not rendered, and its four now-unused language keys were removed.
• Three machines never appeared in their own Ponder scenes. The scenes place their machine with setBlock and then revealed it with showSection, but a section shows what the structure schematic's backup holds — a block the scene placed at runtime is not in it, so the base plate appeared and the machine did not. Create's own scenes reveal runtime-placed blocks with showIndependentSection; the computer, the Dismantler, and the Scheme Loader scene's machine, lamp, belt row and two Deployers now do the same (and the loader hides them again through the returned section links).
• The Ponder panel was blank, and showed the half a scene has no use for. Only the background texture was drawn — but the backgrounds are just a border, a well and a groove: the slot frames, the title and the button are drawn in code by the screens, so the overlay read as an empty grey box. It also blitted all 176x196 px, including the player-inventory half that a Ponder scene has no inventory for. The panel now stops at the groove and draws what the screens draw into that half: one Create-style cell frame per slot (at slot - 1, as the screens do it), the stacks, the panel title, and the button — same position, same size, same vanilla button sprite as the real widget.
• A and D switched nothing in a Ponder scene. Chapter keys are the arrow buttons' shortcuts (Options.keyLeft / keyRight, i.e. A and D by default), and those buttons only exist for a component with more than one scene — PonderChapter itself is a stub in this Ponder version (getTitle() returns an empty constant and PonderUI's chapter field is only ever null). With one storyboard per machine there were three single-scene entries, hence no arrows and no chapter keys. The Production Computer and the Scheme Loader are now both registered for both items, so they are one entry with two chapters (writing the plan / loading it) that A and D page through; the Dismantler stays its own entry.
• The machines were still missing, because the scenes were placing blocks Ponder discards in silence. Scene code may only touch positions inside the block bounding box its structure schematic actually places: setBlock / modifyBlock run through ReplaceBlocksInstruction, whose first line is if (level.getBounds().isInside(pos)), and SchematicLevel computes that box from the blocks that were placed — not from the schematic's declared size. The schematics held the base plate alone (y=0), so the machines, the cabinet's lamp and the whole closing belt/Deployer picture, all at y≥1, were thrown away with no log line at all — indistinguishable from a scene that never drew them. They now live in the schematics and the scenes only show and hide them, which is how Create's own scenes are built (its ponder schematics carry the machines, the scene reveals sections of them). The three schematics are now generated by tools/ponder-schematics.js, which also writes down the two NBT traps in full, and the self test's new 24th check asserts the invariant from both sides: each scene's schematic holds the expected block at every position that scene shows, hides or modifies, and that position lies inside the box the schematic's blocks span.
• The closing picture was a still life. The belt-and-Deployers panel showed the shape of a line but nothing ran: no power source, no motion. Ponder does run Create's kinetics — setKineticSpeed writes the speed onto the kinetic block entities of a selection, which is how Create's own scenes start a belt (DeployerScenes does setKineticSpeed(select().layer(1), -32F)) — so the loader schematic now carries a Creative Motor beside the belt's first pulley (at (0,1,0) facing south, the axis a belt travelling along x is turned by), and the scene sets the speed on the motor and the belt, drops the base item onto the running belt and lets each Deployer reach down onto it and retract again, with a success flash. The line reads as a powered line now, not as a diagram of one.
• The Deployers were one cell too low to reach the belt, and the belt carried nothing. A Deployer acts on the position two blocks in front of itself, so the cells at y=2 facing down work the plate at y=0 and never touch the belt at y=1 — exactly the "leave one cell empty" the author described from a real sequenced assembly. They now hang two cells above the belt (schematic grown to 5x4x5), holding the material they add, and the belt carries the whole story: the base goes on under the first Deployer, which turns it into a Generic Intermediate (this mod's own unfinished-line item), and the second — waiting at the belt's last cell, where an item stops by itself, so the picture cannot drift out of step with the belt speed — finishes it into the product. Base, intermediate and product all travel the belt.
• The narration boxes ran across the GUI panel. Ponder anchors a speech box to the pointed position (min(0.75 * width, projectedX + 50), projectedY + 3), and the scenes pointed at topOf(machine), which projects to roughly 40% of the screen height — the panel's own band. They now point at the machine's near-bottom corner (the side facing the camera, just above the plate), which drops the boxes to about two thirds of the height, and the panel moved up to the top edge (y=6). Both boxes and panel are clear of each other in every scene, with the projection worked out from Ponder's own transform rather than by eye.
• Nothing ever appeared on the belt. A belt placed from a schematic does not know which of its segments is the controller — that link is per-instance state and is lost when the ponder level is restored from its backup — and createItemOnBelt then does nothing at all: no item, no error, no log line. Create fixes exactly this in CreatePonderPlugin.onPonderLevelRestore via PonderWorldBlockEntityFix.fixControllerBlockEntities; our plugin now implements the same hook. The item is also inserted the way Create's own scenes do it: at the belt's start cell, passing the side the item comes from (a belt facing east takes items from the west), and the first Deployer now waits above that very cell, so base and hand start in position instead of relying on a guessed travel time.
• The redstone signal had no wire to travel along, and the wire it got could not stay powered. The narration promises that an active cabinet emits a redstone signal, but the lamp simply appeared already lit. The schematic now carries redstone dust between the cabinet (2,1,2) and the lamp (4,1,2) — spelled with the two connection flags, so it draws as a straight run rather than a dot. Raising its power from the scene does not work and never would: a redstone wire recomputes its own strength on any neighbour change (updatePowerStrength), and the ponder world contains no redstone source, so the wire was put straight back to 0 in the same tick — the lamp lit up (its state did change, and it notified the lamp) and the wire stayed dark, which is exactly what was reported. Both states are now baked into the schematic, so the wire arrives already carrying the signal.
• The belt could not hold an item, because our schematics carried no block-entity data. Create's own Ponder schematics ship block-entity NBT on every kinetic block, and a belt's carries Index, Length, IsController and Controller — with the item Inventory on the chain head. Without them a segment has no place in its chain and no inventory to insert into, so createItemOnBelt inserted "successfully" and nothing ever appeared or moved. The generator now writes that NBT for every belt segment (schematic coordinates are world coordinates here, so the controller link is exact rather than stale like Create's authored-in-world values), and the belt also carries its speed, so the line is running the moment it appears.
• The items ride the belt's own inventory, because runtime insertion never showed one. Even with the controller hook and the full block-entity NBT in place, createItemOnBelt produced no visible item in game — the belt's inventory is the shape that works: BeltInventory.write / TransportedItemStack.serializeNBT (Item, Pos in belt cells, Offset, InSegment, InDirection, Locked), which the scene drives directly (see the next entry) and which the schematic can also carry, Locked being exactly the state Create uses for an item a Deployer is working on.
• The wire is powered by the cabinet itself, at full strength. SchemeLoaderBlock#getSignal already reports 15 while its block entity is active, so the scene now marks the cabinet active (its block entity NBT carries that flag) and only nudges the wire afterwards: the vanilla power calculation then finds a real source next door and the wire settles at a genuine 15, instead of a value the scene wrote by hand. That also removes the earlier order-dependency, and the light comes on with it.
• The item glides instead of twitching, and only one product comes out. The line no longer releases the item to the belt midway: it stays locked — Create's own "being worked on" state — and the scene writes its position in small steps (five per cell over the ticks the belt itself would need), so nothing fights over where it is. At the end it is handed back to the belt, which carries it off the tail and drops it by itself; the item entity this scene used to spawn on top of that was the second product.
• The item glides, and the signal is shown on the machine instead of on a wire. Two fixes from the author's pass: the item's PrevPos is now the position it had on the previous tick (the belt's renderer interpolates lerp(partialTicks, prevBeltPosition, beltPosition), and writing both to the same value left it nothing to interpolate — the jumps), and it steps once per tick rather than once every three. And the redstone lamp now sits on top of the cabinet rather than at the end of a wire: a vanilla redstone wire was tried twice — baked at 15, then powered from the scene — and rendered dark both times, while the lamp's own state change always showed, so the wire is out of the picture. The cabinet is still marked active (which is what SchemeLoaderBlock#getSignal reads) and the lamp is switched on, so the step shows the machine lighting its own lamp.
• Every step across both Ponder entries now uses one cue vocabulary. The author asked for the operation steps to be unified: if a click is a highlighted button, every click should be, and each kind of action should use the best expression available. The four expressions, applied in the computer chapter, the cabinet chapter and the Dismantler alike: "this item goes into that slot" → the slot's own pulsing frame in the panel, a beat, then the item appears in it; "press this button" → the button's pulsing frame, a beat, then its effect (the panel's contents change and the machine flashes); "look at this part of the block" → narration pointing at the world position (only the bar and the redstone lamp steps are about the block); "something appears" → no cue, the change is the cue. Ponder's overlay().showControls(...) is now unused throughout, because it can only anchor to a block and every action these machines ask for happens inside the panel that block opens. The vocabulary is written down in ProductionLineScenes' class comment and in MachineGuiElement, next to the shared frame both highlights draw.
• The cue for "press it" now points at the button, and the last dismantler step has one. Ponder's own click cue (overlay().showControls(...)) can only be anchored to a world position, so it landed on the block — but the block is merely what opens the GUI, while the action the narration describes is the button inside it (the author's point). The panel element can draw a pulsing frame around its own button, and the scenes now use that instead: the Dismantler highlights 【拆解】 for each of the two presses the story shows and again for the last step (the intermediate case, which previously had no cue at all), and the Production Computer highlights 【计算】 for its step.
• English narration back inside the documented budget: production_computer.text_5 was 107 characters, over the 100 the narration table allows for English, and is now 93.
• The narration now comes up before the line starts, and follows the author's revised script: "用序列 装配的方式按照方案上的提示搭建产线，并为设施提供原料" / "Build the line the scheme describes as a sequenced assembly, and keep it supplied".
• The closing line is now the whole process, and it runs the right way round. Three corrections the author gave from the game, all of them right: an east-facing belt carries items east only at a negative speed (getDirectionAwareBeltMovementSpeed negates the movement on the x axis, which is why Create's own compacting.nbt ships facing:east with Speed:-32), the picture and the sample scheme take raw iron rather than ore (minecraft:iron_ingot_from_blasting_raw_iron), and the two Deployers belong on the second and fourth cells of the five-cell belt. The scene drives the belt's own Inventory NBT (BlockEntityDataInstruction saves, applies and reloads the block entity, so a rewrite takes effect at once): raw iron is fed in and held, released for a cell, held under the first Deployer — which turns it into a Generic Intermediate — carried two cells to the second, turned into the product, and taken off the end with a dropped item beside it. Positions are written explicitly rather than estimated from belt speed, and Locked holds an item under a hand.
• The wire would not light up, because a redstone wire recomputes itself. RedStoneWireBlock recalculates its strength in onPlace as well as on neighbour changes, and the ponder world has no redstone source: baking power=15 into the schematic did not survive placement, and setting it at runtime was undone by the lamp's own state change notifying the wire back. The step now lights the lamp first — that update reaches a wire still sitting at 0, which does not care — and raises the wire's strength afterwards, with no neighbour left to change it, so the wire keeps its 15 and re-bakes bright.

Added

• Generated recipes are retired, not deleted, when they leave the union. An item crafted on a line outlives the line: the Dismantler refunds an unfinished intermediate from the recipe that gave it its provenance, so deleting that recipe the moment its scheme left the loader turned every leftover intermediate into scrap — reported in game as "找不到它来源的序列配方 cpl:…". The pack now moves retired files to <world>/cpl_retired/ (outside datapacks/, so nothing loads them again) and the reader falls back to that folder when the live pack no longer has the recipe. Intermediates orphaned before this change stay unrecoverable unless their scheme is put back once, which regenerates the file.
• Ponder tutorials for the three machines (the ponder key — W by default — on a machine). The Production Computer and the Scheme Loader are the two chapters of one entry, writing a plan and then loading it, and the Dismantler is an entry of its own; all three sit in the machines tag in the ponder index. Each scene carries its own structure schematic at assets/create_productionline/ponder/<id>.nbt, which is what draws the checkered base plate and holds every prop the scene shows — the machines, the cabinet's lamp (lit, so the narration's "emits a redstone signal" is what you see) and the closing belt-with-two-Deployers picture. Those files are generated by tools/ponder-schematics.js, added here so the binaries have a readable source; they are gzip-compressed vanilla structure NBT, and size plus every block's pos have to be a TAG_List of TAG_Int — written as TAG_Int_Array they load as an empty structure with no error at all, which is what left both earlier attempts blank. The narration is the author's own wording, one showText per row of his table, in create_productionline.ponder.<sceneId>.header / .text_<n> — numbered by the order the scene shows them. A panel in the corner shows the machine half of the matching GUI with the items the scene places in it.