GlymeraBlueStone

A complete redstone-style automation system for Hytale — wires, pistons, hoppers, repeaters, observers, torches, pressure plates, ejectors, applicators and more.

File Details

GlymeraBluestone-11.0.0.jar

  • R
  • Jun 11, 2026
  • 270.68 KB
  • 48
  • 0.5

File Name

GlymeraBluestone-11.0.0.jar

Supported Versions

  • 0.5

GlymeraBluestone - Changelog

v11.0.0 (2026-06-11)

  • Fixed: the autonomous-block registry is now world-bound. autonomous_blocks.json previously stored only coordinates, and the chunk-load rebinding keyed pending devices by chunk X/Z alone. On servers with more than one world this had two consequences: a chunk loading in ANY world at the same chunk coordinates could delete the persisted entry of a device in another world (wires/repeaters/hoppers silently lost their persistence e.g. when someone entered a lobby world), or restore a device into the wrong world if a matching block type happened to sit at the same coordinates there.
  • Every persisted device now carries its world name; restore and removal only happen in the matching world.
  • Legacy entries from v10 and older self-heal: they are adopted by the world where the expected block is verifiably present, and are never deleted based on a foreign world's chunks.
  • Fixed: wire/repeater segments no longer stay stuck "active" after a server restart or chunk reload. The active block state used to be burned into the world; after a reload nothing told the segment to turn off until the next signal happened to pass through. Every wire/repeater that ever carried a signal is now remembered and forced back to idle when its chunk loads - BEFORE the signal sources (pressed levers, pulse generators, torches, pressure plates) re-assert the real state through the normal propagation logic. Pistons and other actuators are deliberately not reset: they only move when the re-asserted signal actually differs from their current position, so no spurious retract/extend cycling on reload.
  • No gameplay changes - wires, repeaters, pistons, hoppers, ejectors, applicators, torches, plates and pulse generators behave exactly as before.

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)