GlymeraBluestone - Changelog

v16.0.0 (2026-06-22)

New block: the Bluestone Lamp

• A redstone-lamp-style light block. It looks the same from all six sides and stays dark until it receives a signal — then it lights up in a clean blue glow and illuminates the surrounding area (full light level 15). Remove the signal and it goes dark again.
• Reacts to every signal source, directly and through wire: button, lever, pulse generator, repeater, comparator, pressure plate and Bluestone Torch. Any adjacent powered Bluestone carrier turns it on.
• One item in the creative menu. Only the dark lamp is shown and placed; the lit version is an internal block the plugin swaps in automatically while powered (the same two-state technique the wires, repeaters and torches already use). Named "Bluestone Lamp" everywhere.
• Crafting: 4× Bluestone Wire + 1× White Rock Crystal Block at the Workbench (Tier 3).
• Behaviour is self-contained in Bluestone — no other plugin required. The lamp persists across restarts and chunk reloads like every other Bluestone device, and only updates its block when the on/off state actually changes (no per-tick churn).

v15.0.0 (2026-06-19)

Fixed: the plot protection from v14 now reliably takes effect

• The plot-border protection added in v14 needed GlymeraPlotWorld declared as an optional dependency to actually run — without it the guard silently did nothing. It is now active: pistons and the Applicator are reliably confined to their plot.
• If GlymeraPlotWorld is not installed, Bluestone behaves exactly as before (the protection simply does nothing).

v14.0.0 (2026-06-19)

New: plot protection for block-moving devices (on plot worlds running GlymeraPlotWorld)

• On a GlymeraPlotWorld plot world, pistons and the Applicator can no longer affect blocks across a plot border — never push a block onto the road or into a neighbouring plot, and the plot's own border can no longer be pushed away. The Applicator likewise won't place or break across the border.
• Merge-aware: within a set of merged plots everything still works across the opened seams; only the outer edge of the group is protected.
• Applies to everyone, including OPs. Outside a plot world — or on servers without GlymeraPlotWorld — nothing changes.

v13.0.0 (2026-06-19)

Pistons are now true Minecraft-style pistons

• Pistons and Sticky Pistons used to simply relocate a block. They now behave the way you expect:
  • Creatures in the path are pushed along instead of being ignored — a block can no longer be shoved straight "into" an animal.
  • Plants and fragile blocks break and drop when a piston pushes them (or pushes a block into them) instead of being silently moved. Crops, cacti, flowers and the like drop their items.
  • Chests, furnaces and other containers stop the piston (just like vanilla), so their contents can never be lost.
  • Nothing floats anymore: when a piston pulls a block out from under a plant, torch or sand, that block now reacts (drops or falls) instead of hanging in mid-air.
• A row of up to 12 blocks is still pushed, and a creature standing in front of the row is carried along too.

v12.0.0 (2026-06-14)

Fixed: Hopper could duplicate items when pulling from single-slot processing benches

• The Bluestone Hopper could endlessly duplicate items when extracting the output of certain processing benches — most visibly the native Salvage Bench, and any third-party "single input slot, no fuel" processing block. The finished product was copied into the hopper (and on into the chest behind it) but was never removed from the bench, producing an infinite stream of free items.
• Root cause: when an output slot held a stack (quantity > 1), the hopper decremented the source by writing the reduced stack back with setItemStackForSlot(quantity - 1). A processing bench's output container rejects that write — it is add-filtered, since you cannot place items into an output slot — so the item silently stayed in the bench and also landed in the hopper. Furnaces almost never showed it because their output is usually a single item, which took the working pure-removal path.
• Fix: the hopper now extracts items with the engine's atomic move (moveItemStackFromSlot). A move is a single remove-and-add transaction — it cannot duplicate, and if the source refuses to release the item, nothing happens at all (no duplicate, no item loss).
• No behaviour change for chests, furnaces, or any source where extraction already worked correctly — they keep running exactly as before. Pushing items into benches is unaffected.

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)

• 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.

Notes

• Internal: the bench's input/output containers fire a change event on every mutation, which re-runs the recipe auto-detection — so externally fed items are picked up on the next tick with no UI interaction needed. No logic changed for the existing chest path; it was only refactored to share the transfer loop.

v9.0.0 (2026-06-04)

Item Display Names — now actually working

• All 33 items now have proper, human-readable English display names. Previously the items showed their raw translation key in-game (e.g. server.items.BluestoneWire.name) — long, code-like, and giving no hint about the item's function. This was the subject of player feedback.
• Root cause: the localization catalog Server/Languages/en-US/server.lang had its keys written with a server. prefix already (server.items.BluestoneWire.name=…). The engine derives a namespace from the filename (server.lang → server.) and prepends it, so the keys became server.server.items.BluestoneWire.name — which never matched the item, so the raw key was displayed. Fixed by writing the keys without the server. prefix (items.BluestoneWire.name=…), exactly as every working plugin does (Backpack, Talismans, Beacons).
• Names follow their redstone-equivalent function: Bluestone Wire, Bluestone Torch, Bluestone Lever, Bluestone Button, Bluestone Pressure Plate, Bluestone Repeater, Bluestone Comparator, Bluestone Observer, Bluestone Piston, Bluestone Sticky Piston, Bluestone Pulser, Bluestone Applicator, Bluestone Ejector, Bluestone Hopper. The technical orientation variants reuse their base block's name.
• Server-side verification: the 33 "server.items.Bluestone… does not exist in server.lang" boot warnings are now gone (0) — the names resolve correctly.

Creative Inventory Cleanup

• The 19 technical orientation variants are flagged "Variant": true and are hidden from the creative item library (the native Hytale mechanism for connected/variant blocks). The creative menu shows only the 14 base blocks — one entry per block, no duplicates. Placement still selects the correct orientation automatically.

Localization

• All names live in the single universal fallback locale Server/Languages/en-US/server.lang. Hytale falls back to en-US for any client language (verified), so every client — English, German, Portuguese, any — sees the same clean English names. No per-language file is needed.
• Removed the obsolete/non-standard Server/Item/Language/*.json and the broken Server/Languages/de-DE/server.lang (it had the same double-prefix bug and unwanted German names).

Plugin Logic

• Asset-only update — no logic changes. The 31 compiled classes are byte-for-byte identical to v7.0.0. Placement/orientation conversion, redstone signal propagation, all block behaviors and crafting recipes are unchanged.
• Version bump also invalidates the client-side asset cache, so the corrected names/visibility take effect on reconnect.

Notes

• An unfinished, never-shipped source edit was discarded during this work: a Break_Container / Open_Container interaction on the Hopper/Ejector/Applicator blocks that referenced a non-existent asset and would fail asset validation. If openable-container behavior is wanted later, it needs a proper interaction asset (separate task).
• v8.0.0 was a same-day internal iteration that edited the wrong localization file (Server/Item/Language/*.json); it never left the dev server. v9.0.0 supersedes it.

Earlier versions

• v7.0.0 and earlier predate this changelog. GlymeraBluestone provides a redstone-style logic system for Hytale: Wire, Repeater, Comparator, Observer, Piston, Sticky Piston, Lever, Button, Pressure Plate, Pulser, Hopper, Ejector, Applicator and Torch, with automatic block-orientation handling on placement.