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.jsonpreviously 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
HeadRotationcomponent (the bodyTransformComponentonly carries yaw), and the look vector is built with the engine's ownVector3dUtil.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.