GlymeraBluestone - Changelog

v23.0.0 (2026-06-26) — Chests on the funnel, event-driven redstone, fresh 3D icons

Fixed — chests can be placed on the funnel again

• Since the Hopper became a 3D funnel model (v17), you could no longer place a chest — or any block that needs solid ground beneath it — on top of the funnel (it would refuse to place / drop). The funnel is a custom model and, unlike the old full cube, no longer told the engine that its faces provide a solid supporting surface, so support-needing blocks had nothing to rest on. The funnel now declares full support on all six faces (exactly what the old cube did implicitly), so chests and similar blocks sit on it again.
• Purely a block-property change: item suction & routing, the container, the F-key filter window, pipe auto-connect shapes, redstone, recipe, model/look and lighting are all completely unchanged.

Performance — the redstone engine is now event-driven

• The signal engine used to rebuild the entire network from scratch every redstone tick (10×/second), whether or not anything had changed. On a large server with many built circuits this was a constant cost and flooded the log with "Task took…" warnings, even when every circuit was sitting still.
• It now only recomputes when something actually changes — a block placed/broken, a switch/button/plate/comparator toggled, an observer/pulse firing, or a delayed repeater/torch flip coming due. A built-but-idle contraption now costs essentially nothing (the Minecraft model: quiet circuits are free).
• Robustness is unchanged: chunk reload and server restart still re-register every device and trigger exactly one rebuild, so circuits always come back correctly — and a periodic safety rebuild (every ~5s) guarantees the network can never get stuck, even in an unforeseen case.
• Behaviour and timing of active circuits (wire range, repeater/torch delays, pulses, clocks) are identical to before — only the wasted idle work is gone.

Polish — fresh 3D inventory icons for every Bluestone item

• All Bluestone items now have cleanly 3D-rendered inventory icons instead of the old flat/placeholder ones. The Hopper finally looks like a funnel, the normal vs. sticky piston are now distinguishable (the sticky one shows its green slime head), and the Ejector/Applicator are turned so their distinctive face is visible. The same icons appear in the crafting bench. Purely cosmetic — no gameplay change.

v22.0.0 (2026-06-24) — Pipes, distribution & filtering

The first public update since v16 (the Lamp). It bundles everything built since then — animated pistons, a complete redstone-engine rewrite, the funnel-shaped hopper — plus the big new feature: a full pipe / conduit system with item distribution and per-block filtering.

NEW — a complete pipe / conduit system

• The lying (horizontal) Bluestone Hopper is now a proper metal pipe with flanged ends instead of a tipped-over funnel. Lay several in a row and they read as one continuous, flange-coupled pipeline.
• Auto-connecting fittings: a pipe looks at its neighbours and reshapes itself automatically — straight run, a rounded elbow around corners, T-junction, 4-way cross, and a capped end piece. Nothing to configure: just build, and it forms the right shape (and re-forms when you add or remove a neighbour).
• Item distribution at junctions: when a pipe feeds several outgoing branches, the next item goes to a random branch — 2 ways ≈ 50/50, 3 ≈ 33% each, 4 ≈ 25%. (A funnel placed under a cross is a valid 4th outlet.)
• Direction-aware flow: items never bounce backwards. A straight pipe filled from above (e.g. by a funnel) sends everything forward along its arrow, never back into a dead end. A small engraved arrow on straight pipes shows the flow direction.
• The upright funnel (opening up) keeps its vacuum ability — it still sucks up nearby loose items — while the lying pipe is a pure conduit that only moves items between containers.
• Everything persists across restarts and chunk reloads, including items in transit inside the pipes.

NEW — per-pipe & per-funnel item filter (Whitelist / Blacklist)

• Hold an item and right-click a pipe or funnel to open the Filter window. Click an item from your inventory to set it as a Whitelist (only that item may pass) or, with the mode button, a Blacklist (everything except that item). A block with no filter passes everything. Give each branch its own filter and you have a full sorting system.
• Right-click with an empty hand opens the block's normal container instead. Filters are saved and survive restarts and chunk reloads.

Pistons are now real animated 3D pistons (regular + sticky)

• A proper 3-part model that physically extends and retracts. The extended head is a solid block you can stand on — vertical sticky-piston columns work as elevators, and extended heads can wall off / mob-proof an area. A player standing where the head appears is nudged aside instead of being trapped. The head can't be mined and never drops a stray item.

Complete rewrite of the redstone signal engine

• One coherent power model (0–15) on a single synchronous tick. A short pulse now keeps its length through wire and chains of repeaters instead of dying at the first amplifier; torches invert correctly even from short sources (observers, pulse generators); back-to-back repeater chains all switch (no more "every second repeater stays dark"). Restart- and chunk-reload-safe — active circuits come back correctly.

The Hopper is now a funnel

• The upright hopper uses a funnel shape (wide collecting mouth, narrowing body). Function, recipes and item routing are unchanged.

Polish

• Programmatic state changes (pistons extending, doors, lamps, pipe shapes) no longer spawn stray "block broken" particles.
• The Hopper's item extraction uses an atomic move, so it can never duplicate items when pulling from single-slot processing benches (Salvage Bench, etc.).

v20.0.0 (2026-06-23)

Internal code cleanup (no functional change)

• Removed the legacy signal-propagation code that v19 had kept dormant as a fallback while the new redstone engine was being validated. The new engine is now the sole signal system. Behaviour is identical to v19 — wire, repeaters, torches, sources, pistons and all devices work exactly the same; this release just drops ~1350 lines of unused code.

v19.0.0 (2026-06-23)

Complete rewrite of the redstone signal engine

• The whole signal system was rebuilt from the ground up around one coherent model: a single power field (0–15) updated by one synchronous redstone tick, instead of many independent timers racing each other. The practical payoff: a signal now travels through wire AND chains of repeaters with its duration preserved — a short pulse stays a short pulse all the way down a repeater chain instead of dying after the first amplifier.
• Redstone torches now invert correctly even from short/transient sources (observers, pulse generators): the inverted signal propagates cleanly through a full chain of repeaters behind the torch, end to end.
• Repeater chains placed back-to-back all switch correctly — no more "every second repeater stays dark", and a short or inverted pulse now runs through the entire chain instead of getting stuck after the second amplifier.
• Levers, buttons, pressure plates, observers, pulse generators and comparators all feed the new engine; pistons, sticky pistons, hoppers, ejectors, applicators and lamps react to it. The 15-block wire range and repeater amplification are unchanged.
• Restart- and chunk-reload-safe: the engine rebuilds the whole network from its sources every tick, so an active circuit comes back correctly after a server restart or chunk reload — no stuck-on wires, no frozen pistons. Wire, repeaters and pistons are now remembered from the moment you place them.
• Behaviour-only release: blocks, recipes, models, plot protection and item routing are all unchanged.

v18.0.0 (2026-06-23)

The extended piston head is now solid (regular + sticky, all directions)

• When a piston extends, its head is now a physical block you can stand on and that blocks movement — instead of the non-physical head from v17. This works for the regular and the sticky piston in all six facings (the four horizontals plus up and down). A vertical sticky-piston column can now lift you like an elevator, and extended heads can wall off / mob-proof an area.
• The order of operations is unchanged and safe: the piston first pushes or drops whatever is in its path, then the solid head moves into the now-cleared cell. It also stays extended for as long as a signal is applied and retracts the moment the signal drops — exactly as before.
• A player standing exactly where the head (or a pushed block) appears is now nudged one cell along the push direction before the solid block materialises, so you can never get sealed inside it. Creatures were already pushed in v17; players are now handled too.
• The head still cannot be mined or clicked — its interaction target stays tiny on purpose, so it never drops a stray item and the piston's state never desyncs.
• Pure behaviour upgrade: the redstone/wiring logic, push/drop rules, plot protection and chunk persistence are all unchanged.

v17.0.0 (2026-06-22)

Pistons are now real 3D pistons that visibly extend (regular + sticky)

• Both the Piston and the Sticky Piston now use a proper 3-part model — base + a metal arm + a wood head — instead of a flat cube. On a signal the head physically extends into the cell in front (the arm fills in behind it); when the signal is gone it retracts again. The Sticky Piston's head carries a green slime splotch.
• All directions are supported just like before (the four horizontal facings plus up and down); the head always extends the way the piston points.
• The head is non-physical (no collision) and is treated as empty by the push/pull logic, so it never interferes with what the piston is moving. Breaking the piston base removes its head, and pistons can no longer be pushed by other pistons (they're solid anchors now).
• The old flat "extended" texture effect was removed in favour of the real moving head.
• Pistons are driven by wire and repeaters (a stable signal). Hooking a lever, button or pulse generator directly onto a piston no longer toggles it — route those through wire (this avoids a visual flicker from momentary/pulsing sources). An extended piston also self-checks and retracts as soon as its signal drops, so it can never get stuck extended.

The Hopper now looks like a real funnel

• The Bluestone Hopper uses a funnel-shaped model (wide collecting mouth, narrowing body) instead of a cube. The down-hopper opens upward; the directional hopper lies on its side and faces the way you place it. Function, recipes and item routing are unchanged.

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.