GlymeraBluestone - Changelog

v10.0.0 (2026-06-09)

Hopper now feeds and empties Processing Benches (furnaces, campfires, etc.)

• The Bluestone Hopper can now automate processing stations, not just chests. Previously the hopper only moved items between blocks that expose a native ItemContainerBlock (chests and similar). It now also recognises any Processing Bench (ProcessingBenchBlock) and reads/writes its input, fuel and output containers directly. Fully automatic, ongoing smelting/processing — exactly like a Minecraft furnace + hopper setup.
• Supported stations (all native "Processing"-type benches): Furnace, Campfire, Salvage Bench, Tannery. Detection is generic via the bench's component, so any future processing bench Hytale adds is covered automatically.
• Crafting benches are intentionally NOT supported (Workbench, Weapon/Armour/Alchemy/Arcane/Cooking/Loom/Farming/Lumbermill/Builders/Furniture/Trough). These have no persistent item container — crafting happens only in a player's open UI with a manually chosen recipe — so there is nothing to inject into or extract from. This is an engine limitation, not a missing feature.

Position decides input vs. fuel (Minecraft-style routing)

• A hopper pushing into a bench from ABOVE → the item goes to the Material/Input slot. Pushing from the SIDE → the Fuel slot (falls back to Input on benches that have no fuel slot, e.g. Salvage/Tannery).
• This resolves the dual-purpose ambiguity: items like sticks and wood logs are both valid fuel AND a smelting ingredient (charcoal). A pure item-type rule would mis-sort them; the hopper's physical position decides instead.
• A hopper pulling from a bench only ever takes from the OUTPUT container — finished products (and the charcoal extra-output), never raw ingredients or fuel. Pulling from a full furnace also unblocks it (a full output pauses processing).
• Chest ↔ bench works in any combination: a hopper can pull from a chest on one side and feed a furnace on the other, or pull a furnace's output into a chest. Each side is resolved independently (chest first, then bench).

Orientation now follows where you look (all orientable blocks)

• Vertical orientation is decided by the player's look direction when placing, not by how far above/below your body the block lands. Look steeply up (>70°) → the up-facing variant; look steeply down (>70°) → the down-facing variant; look roughly level → a horizontal block oriented by your facing. Previously you had to float 3+ blocks above/below the spot, which was unintuitive (and barely discoverable).
• Applies uniformly to every orientable Bluestone block that has up/down variants: Piston, Sticky Piston, Observer, Pulser, Comparator, Ejector, Applicator, Torch — plus the Hopper (down-only, no up variant). One shared helper, one consistent ~70° threshold.
• Technically: the look pitch lives in the player's HeadRotation component (the body TransformComponent only carries yaw), and the look vector is built with the engine's own Vector3dUtil.setYawPitch — the exact same path the engine uses for its block raycast — so the up/down decision matches where the crosshair actually points. No new textures: the up/down variants already existed; only the trigger changed.

Multi-block targets (double chests, the 2-tall furnace)

• The hopper now resolves multi-block structures to their origin block. Big objects (a double chest = Chest_Large + a "filler" cell; the furnace, which is 2 blocks tall and wider than 1 cell; large benches) occupy neighbouring cells with filler blocks that carry no container/block-entity — the real ItemContainerBlock/ProcessingBenchBlock lives only in the origin cell.
• Previously, if the hopper pointed at a filler half, it found nothing and did nothing — e.g. a hopper sitting on top of a furnace (it points at the furnace's upper filler cell) or a hopper at the filler half of a double chest silently failed. Fixed by resolving every target position through getBaseBlock(...) before looking up the container — fillers map to their origin, normal blocks are unchanged. Covers double chests, the tall furnace and any future multi-cell container automatically.

Robustness

• No item loss on wrong placement. Each bench slot validates inserts itself (canAddItemStackToSlot — Input only accepts valid ingredients, Fuel only accepts fuel), so a mis-routed item simply stays in the hopper instead of being lost or clogging the wrong slot.
• Skips a bench while a player has it open (mirrors the existing chest "being viewed" guard), avoiding UI desync.
• Transfers run on the world thread (the hopper tasks already wrap their work in world.execute(...)), so writes are serialised against the engine's own processing tick — no races.
• Transfer rate unchanged: 1 item per hopper tick, like Minecraft.