GlymeraBluestone - Changelog

v148.0.0 (2026-09-24) — Rotated copies keep their direction (repeater, counter, timer)

• Fixed: a copied circuit pasted after /rotate (90, 180 or 270 degrees around the vertical axis) had every repeater, counter and timer still pointing the way the original did. The structure itself landed in the right place, but these three parts store their orientation in the block variant (the W/EW variants), and the game's rotate tool only turns a block's rotation index, never its variant. So a pasted repeater kept passing its signal east while its row now ran north, the wires next to it did not connect (the loose wire ends in the Discord screenshots) and the lamp behind it stayed dark. Pistons, observers, hoppers, comparators, torches, beam sensors, ejectors and applicators read the rotation index and were already right.
• When a pasted part registers, Bluestone now works out which way it really points (variant plus rotation index) and converts it to exactly the form a hand placement produces: north and south as the base variant with rotation 0 or 2, west and east as the W/EW variant with rotation 0. Delay (D2–D4), counter target (C2–C6), timer stage (S2–S8), the visible state and the marker holding the counter/timer values are kept. Pasted wires get rotation 0 back as well, like hand-placed wires; their arms are computed from the neighbours as before.
• Nothing changes for hand-placed parts: they already have that form, so the check writes nothing. Copies pasted with 147 or earlier stay as they are — paste them again.
• Harness: new scenario pasterot (a source box with repeater EW, counter C3, timer S2, a piston with a stone in front and a wire corner, copied at 0/90/270/180 degrees through the builder-tool code path; 48 checks on ids, rotation indices, wire shapes, lamps and the piston's push direction; 147 fails 3 of the original 18 probe checks, 148 passes all). SimLab 0.21.0 adds copypaste --rot and fillbox.
• Reported by dissy_ on Discord (2026-09-24) with annotated screenshots.

v145.0.0 (2026-09-17) — Copied circuits work: parts report themselves (builder-tool paste, cut, fill, prefabs)

• Copied circuits work. Builder-tool copy/paste, prefab pastes, fills and undo place blocks without the event a hand placement fires, so Bluestone never heard about pasted parts: the copy looked right and stayed dead (CurseForge report by dissy614). Every Bluestone part now carries a tiny marker the game itself creates whenever the block appears, however it got there. Bluestone is told the position, waits half a second and registers the part exactly as it would after a server restart: wires start idle, levers and power blocks assert their state, a pressed lever keeps its copy running, an extended piston stays consistent. Everything travels with the copy: what is part of the block anyway (facing, repeater delay, timer length, counter target, note pitch) and what used to live only in Bluestone's own files — pulser speed, note block volume, counter count, the rest time of a running timer and pipe/hopper filters. Bluestone mirrors these values into the marker, the builder tools copy the marker, and the copy reads it when it registers. Beam sensors find their partner again and observers take a fresh snapshot on their own.
• Whoever pastes owns the copy. Parts pasted with the builder tools belong to the player who pasted them (break protection as for hand-placed parts). If the game does not tell who pasted (prefab spawners, world generation, a future change in the builder tools), the copy simply has no owner, as before.
• Parts removed by builder tools are forgotten. Cut, fill, undo or another plugin deleting a Bluestone part used to leave a dead entry in the registry until the chunk reloaded. The same marker reports the removal.
• No scanning, capped work. Nothing runs while nothing changes. Reported cells are checked in portions of 100 per world tick; pasting about 4,000 wires at once cost 44 ms of work in total, spread over many ticks; deleting 4,900 cost about 110 ms spread over a second (measured headless). About 100 bytes of memory per part.
• Existing builds: parts placed before this version get their marker the first time their chunk loads after the update, so old machines can be copied too. Block ids, states and recipes are unchanged.
• Pasting a machine exactly over itself no longer leaves stale visuals: replaced parts are re-synced from the signal engine.
• Lamps now switch without replacing their block entity (same look, less work per switch).
• Internal: the plugin was split into modules (no gameplay change, no block or recipe change). The signal-engine host, applicator, hopper/pipe system, sensors (observer, daylight sensor, beam sensor, comparator), ejector/incinerator, note block and pistons now live in their own source files, and the one rule "may Bluestone touch this cell right now" (a player nearby and the chunk in memory, or ticking for item transfers) is a single helper used by every scanner and timer instead of a dozen hand-written checks. This is what makes fixes like 144's chunk sleep hard to get wrong again. Verified with the full headless harness (31 scenarios) before and after.
• Test harness: 37 scenarios / 251 checks green on Hytale 0.6.6 (copy/paste scenarios additionally on 0.6.3), plus an upgrade test (build with 144, switch to 145, copy the old machines) and a negative control (the copy tests fail on 144). 31 scenarios / 189 checks were green before and after the module restructuring; protate and ejector now clear their off-platform lanes first (leftovers from earlier runs had made both flaky).

v144.0.0 (2026-09-15) — Circuits sleep while their chunk is unloaded: no more load/unload carousel

• Fixed: every chunk containing a Bluestone part outside all players' view distance was loaded and unloaded again every 8–10 seconds, forever. The signal engine polled its sources ten times a second and rebuilt each circuit every 5 seconds by reading blocks; on Hytale 0.6 a block read from the world thread reloads an unloaded chunk (and keeps it ticking while it is in memory), and a chunk nobody looks at is dropped again 7.5 seconds later. Measured on a headless server without any player: a chunk with a single daylight sensor was reloaded 19 times in 150 seconds, a chunk with a single hopper 16 times, a chunk with only stone once. Every cycle cost a disk read, the pre-load hooks of all plugins and a save — on slower hardware that shows up as Took too long to run pre-load process hook … GlymeraBluestone in the log (reported on Discord).
• Fixed: parts could come back from a chunk reload showing the wrong state (a torch dark although its input is off, a lamp off although it is powered): a state written into a chunk that was just being unloaded could be lost after its save. On chunk load Bluestone now re-applies the engine's current state to wires, torches, repeaters, counters, timers and lamps in that chunk, and wires at the chunk border get their connection arms.
• Changed: a circuit sleeps while any of its chunks is not in memory — exactly the rule that already applied beyond 192 blocks. It keeps its state (counters, timers, delayed flips) and resumes the moment the chunk is loaded again. Daylight sensors, observers, beam sensors, comparators, pressure plates, pulsers and the incinerator ember follow the same rule. Hoppers, pipes and carts already did. The door discovery that runs on chunk load no longer peeks into neighbouring chunks either. Tip: a machine that lives inside one chunk wakes up as one piece; a machine spanning several chunks waits until its last chunk is loaded (usually a few blocks of walking later).
• Cost: one map lookup per chunk per circuit per tick; nothing is read or written in unloaded chunks any more. Machines inside a chunk loader's area are unaffected (their chunks stay in memory).
• Harness: new scenario chunksleep (torch → wire → lamp plus a daylight sensor five chunks away from the arena: the chunk must unload and stay unloaded, zero chunk loads are logged, after a reload lamp and torch show the right state, and a lamp forced off behind the engine's back is restored on the next chunk load). New SimLab probes gsim bs load / chunkmem / loadtrace and the standalone probe harness/chunk_carousel_probe.sh (before: 19/16/1 loads, after: see report).
• Contains v143 and earlier.

v143.0.0 (2026-09-14) — One Pulser: no hidden Up/Down variants any more

• Fixed: a Pulser could keep blinking without feeding its wire. Since v10 a Pulser placed while looking steeply up or down silently became a separate Up/Down block — indistinguishable in game (same model, texture and name). On those, F cycled through 13 steps and swapped the block type twice along the way; at that swap the Pulser was dropped from the signal engine and only its blinking timer was re-registered. From then on it blinked but powered nothing until it was broken and placed again.
• Changed: the Pulser is one block. Placing it always gives the same block whatever you look at, and F cycles the familiar 7 steps: 0.5 s, 1 s, 1.5 s, 2 s, 2.5 s, 3 s, off. Existing Up/Down Pulsers in worlds keep their block id and keep working; they now behave exactly like the normal one. The directional output those variants once had was already inactive — every Pulser feeds all six sides.
• Harness: new scenario pulseud (Pulser placed from above, full F cycle including off/on, legacy Up/Down block; the wire must keep pulsing throughout).

v142.0.0 (2026-09-13) — The Bluestone Bench: one crafting station for every Bluestone part

• New: Bluestone Bench — a crafting station of its own, two blocks wide like the Workbench, in the Bluestone look: masonry pedestals, an iron top with rivets and a glowing signal strip, a back rail with three signal lights, and a lamp, a repeater board, a coil of wire and a wrench on the table. Open it and every Bluestone part is in one tab, no Workbench tier needed.
• Changed: all 30 Bluestone recipes moved from the Workbench to the Bluestone Bench. The Bench itself is crafted at the Workbench, Crafting tab: 6x Wood Trunk, 4x Rock, 3x Greater Essence of Life (every ingredient obtainable in Adventure mode).
• Config: benchRecipeEnabled (default true). Set it to false to remove the Bench recipe at the next server start; placed benches keep working, and the block itself never disappears from a world. The recipe lives in a small asset pack next to the jar (GlymeraBluestoneRecipes), written by the plugin.
• Contains v141 (ordinary blocks next to a circuit are seen by the signal engine at once) and earlier.

v141.0.0 (2026-09-13) — Ordinary blocks next to a circuit are seen by the signal engine at once

• Fixed: a plain block placed, broken, or pushed/pulled by a piston next to a circuit was noticed only after up to 5 seconds. Solid blocks carry signal (a repeater feeding a stone, a lamp behind a wall), but only Bluestone components told the engine that something had changed; an ordinary block was caught by the engine's 5-second self-check alone. Reported by dissy614 (CurseForge, v140 on 0.6.5) for a stone pushed between two repeaters. The engine now re-evaluates the affected circuit on its next tick: hand-placed, broken, pushed and pulled blocks all react within a fraction of a second.
• Unchanged: which blocks conduct. Wood still insulates, components are still piston-proof.
• Cost: nothing while idle. A block placed far from any circuit costs 27 map lookups and no more; near a circuit it triggers one recompute of that circuit, which the engine ran every 5 seconds anyway. Measured: one recompute of a 2,000-part circuit ≈ 0.6 ms, of a 10,000-part circuit ≈ 2.2 ms (headless bench, lower bound).
• Harness: new scenario pvan (hand-placed, broken, pushed, pulled, wood insulator, 15 checks). The unfixed v140 fails the four "within 1 s" checks and passes every "after 6 s" check — exactly the backstop.
• Contains v140 and earlier.

v140.0.0 (2026-09-11) — Pistons keep the orientation of the blocks they move

• Fixed: a block pushed or pulled by a piston was turned to its default facing (south) — bookshelves, roof pieces, stairs and other directional blocks lost their orientation on every move. Reported by Chattonne (Discord, 2026-09-10), who ran into it building a secret door out of bookshelves. The engine stores a block's facing separately from its id, and the piston only carried the id. It now reads the rotation at the source cell and writes it together with the block at the destination — for a single block, a chain of up to 12, a honey-glued group, and the sticky piston's pull-back. Blocks with the default facing take exactly the old path; the extra work per moved block is one chunk lookup and one integer read.
• Note: ores and other blocks with RandomRotation still look different after a move — the client picks their look from the position, nothing is stored server-side.
• Harness: new scenario protate (a 6-block chain of bookshelves and stairs with mixed rotations, sticky push and pull) — checks id and rotation index at every cell.
• Contains v139 and earlier.

v139.0.0 (2026-09-10) — Doors listen even when the signal arrives through a block

• Fixed: a door did not react to a pressure plate or pressure block buried in the floor in front of it, and a door that was broken and placed again stopped reacting altogether. Signal has always travelled through an ordinary solid block (a buried plate powers the floor block under the door, the floor block powers the door), but a door only became a signal listener when a component was placed directly next to it — the block in between hid it. Doors are now registered when a component is placed next to them or behind a conducting block, when a door is placed next to (or behind a block from) an existing component, and again when a neighbouring chunk loads. Placing order and re-placing no longer matter.
• Changed: a signal-opened door now opens away from a player or creature standing in its swing cell when the other side is free — the same rule the hand-operated door uses. Before, the door could swing into whoever stood in front of it (typically on a buried pressure block, whose swing cell is free), push them off the block and close again.
• Contains v138 and earlier.

v138.0.0 (2026-09-10) — Pressure Block, and signal-opened doors no longer delete what is in their way

• Fixed: a door opened by a signal deleted whatever stood in its swing cell — a pressure plate, wire, even a stone block — without dropping anything. When a door opens, the game reserves the cell the door swings into. Opening by hand checks first that this cell is free, and otherwise opens the door the other way or leaves it shut. The signal path skipped that check. It now runs the same check as the hand path: blocked on the preferred side → the door opens to the other side; blocked on both sides → it stays shut until the next signal edge. Grass and flowers in the swing cell drop as items, exactly as when the door is opened by hand.
• Audit of every other place where Bluestone changes a block: nothing else writes into a foreign cell. Pistons refuse to push components, the applicator only places into empty cells, and no Bluestone block's own hitbox reaches beyond its cell.
• New: Pressure Block (BluestonePressurePlateBlock) — the pressure plate as a full solid block. Step onto it and it emits a full-strength signal on all six sides — into wire, lamps, doors or a piston right below it — for as long as something stands on top; the plate on top lights blue and a blue band runs around the sides. Piston-proof and owner-protected like every other component. Recipe: 1x Bluestone Pressure Plate + 4x Oak Log at the Workbench (Tools, tier 3).
• Contains v137 and earlier.

v137.0.0 (2026-09-07) — Piston and pressure plate recipes use oak logs

• Fixed: the piston and the pressure plate could not be crafted in adventure mode. Both recipes asked for Tree Bark. That item exists in the game files, but no player can obtain it: its only source is a bark scraper used on an oak log, and the bark scraper has no recipe and never drops (unfinished vanilla content, unchanged since 0.5). Both recipes now take 1x Oak Log (Wood_Oak_Trunk) instead — the block you get when you chop an oak.
• Piston: 3x Ore_Iron, 2x Stick, 1x Oak Log
• Pressure Plate: 2x Ore_Iron, 2x Ore_Copper, 1x Oak Log
• Every other Bluestone ingredient was checked against the game data the same way; all 23 remaining ingredients have a real adventure-mode source (recipe, block drop, furnace by-product or creature drop).
• No functional changes. Contains v136 (Note Block) and earlier.

v136.0.0 (2026-09-06) — Note Block: Bluestone makes music

• New block: Bluestone Note Block. Every rising edge of a signal next to it plays one note. Press F to open its panel: a pitch slider (25 notes, two octaves F#3 to F#5, note name shown), a volume slider (10–100 %) and a Play button. Every slider move plays the note right away, so you tune by ear; the world stays visible behind the panel and the note glyph on the block lights up with every note. Pitch and volume are stored with the block and survive restarts and chunk reloads.
• The full block underneath picks the instrument (Minecraft convention; every one is a native full block you can get in adventure mode): wood planks or trunks = bass, stone = bass drum, sand / gravel / dirt / grass / mud / snow = snare, mushroom block = guitar, gold bricks = bell, crystal blocks = chime, ice = hi-hat, bone block = xylophone, anything else (or air) = harp.
• All 225 notes are synthesized and ship inside the plugin (about 1.2 MB, no client mod), normalised to the same perceived loudness across instruments and pitches. Notes carry 45 blocks with distance falloff.
• Works with every signal source: lever, button, pulse generator, repeater chains, counter, timer, observer, pressure plate, daylight sensor, beam sensor. A chain of repeaters with a note block at every step plays a melody; a pulse generator into a stone-based note block is the simplest metronome.
• Owner protection as for timer and counter: only the owner (or an admin) opens the panel; anyone's signal plays the note.
• Recipe: 2x Bluestone Wire + 4x Hardwood Planks at the Workbench (tier 3).
• Fixed for every component: when a player who is not the owner tried to break a Bluestone block, the break was correctly refused — but the block was still unregistered from the signal engine (deaf until the chunk reloaded), a piston lost its head, and the owner entry was cleared so the next attempt went through. All break handlers now check the owner protection themselves before touching anything.
• Headless harness: new scenario note; full regression 77/77.
• Contains v135 (owner check for flipping sticky pistons and observers), v134 (Update 6), v133 and earlier.

v133.0.0 (2026-08-26) — Every seed bag plants, alchemy seeds on crystal soil, and the empty applicator picks up what F picks up

• Every seed bag now plants what it plants in your hand. The applicator used to guess the crop block from the seed's name, which only worked for the 38 field crops: grass, sunflower and all 34 tree seed bags did nothing, and the apple seed bag would even have placed the wrong block. It now reads the target straight from the seed item's own data — the same place the game looks when you plant by hand — so grass seed, sunflower seed and every tree seed bag go into tilled soil like any other seed, and plants from future updates or other mods work without a plugin change.
• All nine alchemy seeds go on crystal soil. The soil rule is now taken from the seed itself too: seeds the game plants on crystal soil (Health, Mana and Stamina, all three tiers) need crystal soil in front of the applicator; everything else needs tilled farmland. Before, Stamina was wrongly held to the farmland rule and never planted.
• The empty applicator also picks up what F picks up. Grown alchemy plants, rubble piles, coral shells and other small blocks that a player collects with F (blocks with a harvest entry but no growth stages) are now taken by an empty applicator the same way: the block is removed and its harvest drops fall in front of the applicator. Unripe stages are still left alone; chests, furniture, benches and doors are untouched (none of them has a harvest entry).
• Tools in the magazine behave exactly as before; an applicator holding anything other than a seed keeps its previous behaviour in every case.
• Contains v132 (empty applicator harvests like F), v131 (restore on the world thread), v130 (timer), v129 (beam sensor) and earlier.

v132.0.0 (2026-08-26) — An empty applicator harvests like an empty hand

• An applicator with an empty magazine now harvests the ripe plant in front of it the way a player does with F — apples on the tree, berry bushes, eternal crops and every other plant that regrows after harvesting: the harvest drops fall at the plant and the plant stays and starts regrowing, exactly as the game does it. One-shot crops (wheat, corn, …) drop their harvest and are removed, as when a player harvests them by hand. Before, the applicator only knew how to break a block with a tool, which destroyed regrowing plants for good — an apple tree could be picked exactly once.
• Only a plant that is actually ripe is harvested (the game marks only the final stage as harvestable); an unripe plant is left untouched, so an observer under an apple can trigger the applicator freely.
• "Empty" means empty: as long as anything lies in the magazine — including a broken tool waiting for repair — the applicator behaves exactly as before (tools break the block, seeds plant, buckets pour). A harvesting machine that should never break a plant simply keeps its magazine empty; a machine that should clear plants keeps a tool in it.
• No other block interactions are triggered (no doors, chests, levers or portals) — the empty applicator only harvests.
• Plot guard applies as for breaking: no harvesting across a plot border.
• Verified in game against the game's own drop tables: 10 apple harvests → 10 apples + 5 life essence, 10 eternal tomato harvests → 21 tomatoes + 55 essence, 10 normal tomato harvests → 19 tomatoes + 66 essence with the plant removed each time — exactly the numbers a player gets by hand.
• Contains v131 (restore on the world thread), v130 (timer), v129 (beam sensor) and earlier.

v131.0.0 (2026-08-25) — Machines start the moment you arrive, not a minute later

• Fixed: after a server restart (or the first visit to an area) Bluestone — and every other plugin's timers — stood still for a long time. Restoring a chunk's Bluestone parts was done on the server's single shared scheduler thread, and every block it looked at there had to wait for the world thread. That cost about 0.4 seconds per part: a machine of 142 parts froze the scheduler for a full minute, a large build for many minutes — and with it minimaps, bees, irrigation, plot guards and the Bluestone clock itself, while TPS looked perfectly healthy. Without Bluestone in the area nothing needed restoring, which is why such servers felt "fit" immediately.
• The restore now runs on the world thread in small batches per tick (the scheduler only triggers it). Measured on the same 142-part machine: scheduler busy for 61 seconds before, not even a single sample after; the machine, counter state and a running timer all came back instantly and correctly after the restart.
• Neighbour lookups across chunk borders (wire arms, doors) now skip chunks that are not loaded yet instead of forcing them; the neighbour chunk's own restore completes the border wires when it arrives. No configuration change, no data change.
• Contains v130 (timer), v129 (beam sensor), v127, v126 and earlier.

v130.0.0 (2026-08-25) — Timer: turn any pulse into a signal of 15 seconds to 10 minutes

• New block: Bluestone Timer. A rising edge at its back starts a countdown and its front outputs a full-strength signal for exactly the set time; when the time is up, the output drops. Press F to cycle the setting: 15, 30, 45, 60, 120, 180, 300 or 600 seconds. The setting is engraved as a number on the board and stored in the block itself.
• One shot, no stretching. Further pulses during the run are ignored, and a signal that is still standing when the time runs out does not restart it — the timer only fires again after the input has dropped and risen once more. That makes it predictable behind a button, an observer or a pulse generator (a 1-second pulse generator in front of a 15-second timer gives one clean 15-second signal every 15 seconds).
• Runs survive restarts and reloads. A timer that is mid-run when the server restarts continues where it left off (accurate to one second); a signal that is still standing at boot never triggers a phantom start. Like the pulse generator, the countdown pauses while no player is within range of the machine.
• Directional like the repeater and counter: input at the back, output only at the front; wire docks only on those two sides. Repeaters, counters and timers chain directly. Cannot be pushed by pistons.
• The hourglass on the board shows the state: sand at the bottom while idle, sand at the top with a glowing trace while running.
• Recipe: 2 iron ore + 2 copper ore + 1 sand (workbench tier 3).
• Contains v129 (beam sensor), v127 (comparator front-only output), v126 (observer/counter memory across restarts) and earlier.

v129.0.0 (2026-08-22) — Beam Sensor: a tripwire of light between two sensors

• New block: Bluestone Beam Sensor. Place two sensors facing each other on the same row (up to 15 blocks apart, horizontal only) and a thin red beam spans between them, humming quietly. Any creature, player or object whose body crosses the beam breaks it: the beam vanishes for a moment and both sensors output a full-strength signal from their back face for as long as the line is blocked. No filtering by creature type, no distance or direction, no damage — what you build behind it is up to you.
• Real hitboxes against a real line. Detection checks each entity's actual hitbox against the beam line (centre of the cell, at sensor height), 20 times a second. The height you mount the sensors at decides what triggers: on the ground everything does; one block up a chicken walks underneath while a cow or a player does not; two blocks up only the big ones. That is what makes it useful for telling creatures apart by size.
• Any block between the two sensors breaks the line: no beam, no signal. Water and other fluids neither block nor trigger it — flowing liquids are invisible to the beam.
• Sensors pair automatically on placement (the nearest facing sensor wins); breaking one side releases the other. Pairs survive restarts and chunk reloads and reconnect as soon as both sides are loaded.
• Sound: a quiet laser hum at both lenses while the beam stands (about 5 blocks), silent while interrupted. Sound "Laser" by freesound_community via Pixabay (Pixabay Content License).
• Cost: one spatial query per pair, only while a player is nearby, no world reads per check — less than a single pressure plate. The beam itself is a client-side visual and leaves nothing in the world.
• Recipe: 1 observer + 2 copper ore + 1 red crystal → 2 beam sensors (workbench tier 3).
• Contains v127 (comparator front-only output), v126 (observer/counter memory across restarts) and earlier.

v127.0.0 (2026-08-22) — Comparators output to the front only

• A comparator no longer powers the container it is measuring. The comparator fed all six neighbours like a lever, but the block it reads always sits behind it — so a filled ejector powered its own comparator, which powered the ejector, which fired. The same loop could trigger any hopper, applicator or piston standing behind or beside a comparator. The comparator now outputs only through its front face, exactly as in Minecraft; measuring from the back is unchanged.
• Note: wire or devices attached to the sides of a comparator no longer receive a signal from it. Feed them from the front.
• Contains v126 (observer memory and counter state across restarts) and earlier.

v126.0.0 (2026-08-22) — Observers remember what they saw across a restart

• Observer-driven machines no longer fall out of step after a server restart or chunk reload. An observer kept what it last saw only in memory; after a restart it came back a few seconds after its chunk and took whatever stood in front of it as the starting point. Anything that changed in between went unseen: a cactus that grew its second block during the start-up minutes left the observer staring at "cactus" forever, and a corn plant that caught up several stages had the counter behind it miss exactly those pulses. Reported with a cactus harvester and a counted corn farm, both reproduced on a restart.
• The observer now stores its last seen block alongside its position. When it comes back it compares the stored block with the current one and, if they differ, fires the missed edge — one pulse for any change, one per stage for crops that advanced several stages (the v122 stage pulses, now also across restarts). The catch-up pulse waits a moment so pistons and counters of the same chunk are restored first.
• Counters keep their intermediate count across a restart. The count lived only in memory, so a counter that stood at 1 of 5 before a restart came back at 0 and never reached its target — the second half of the corn-farm report. The count is now stored with the counter's device entry and restored with it (the target was always safe, it sits in the block itself).
• Cost: a few bytes per observer and counter in the existing device file, written by the save task that already runs; the entry disappears with the device, nothing is left behind. No new scans.
• Contains v125 (sticky reload guard, applicator plant rule), v124, v123 and v122.

v125.0.0 (2026-08-21) — Sticky pistons survive a restart; applicators never break plants

• Extended sticky pistons no longer lose their head on chunk load. On a server restart (or any chunk reload) a sticky piston that was standing extended with a block in front came back broken: body still extended, head gone, the pushed block sitting in the head's cell. The reload routine retracts every piston for a moment, the power source re-registers and extends it again within milliseconds, and the delayed pull then overwrote the fresh head with the pulled block. The pull now checks whether the piston is already extended again and leaves it alone. (Running machines healed themselves on the next pulse, which is why this went unnoticed — an idle contraption showed it.)
• An applicator holding anything plant-like will never break a block. Mushroom caps, flowers, grass, saplings, seeds and spores now behave like seeds always did: place if the target cell is free, otherwise do nothing. Before, a mushroom cap in the applicator counted as a "tool" and a second pulse harvested the mushroom it had just planted. Detection is data-driven — Plant_ items, the game's own Type=Plant tag, or any block with growth data — so plants from future updates and other mods are covered. Stone, wood, tools and weapons are unchanged.
• Contains v124 (sticky retract drops plants), v123 (scheduler fix) and v122 (observer growth pulses).

v124.0.0 (2026-08-21) — Plants now drop when a sticky piston pulls their block away

• Retracting a sticky piston now breaks whatever was resting on the pulled block. Pushing a block out from under a plant, flower, mushroom or torch always made it drop; pulling the block back with a sticky piston did not — the plant simply stayed floating in the air, because the retract path never told the game to re-check support. Both paths now behave the same, exactly as in Minecraft.
• This matters for any harvester that works on a short pulse: sticky piston normally extended, a brief retract drops the crop, the block returns underneath for the next cycle (observer → torch → sticky piston). Those builds now harvest on every pulse.
• No other changes. Contains v123 (scheduler fix) and v122 (observer growth pulses).

v123.0.0 (2026-08-21) — Fixes stuttering machinery once many observers are placed

• Observers no longer stall the shared server scheduler. The observer scan read its watched blocks from the server's single scheduler thread, and on current Hytale builds that read blocks until the world thread gets round to it. With a couple of dozen observers the scheduler was busy waiting almost permanently — and everything else that runs on that same thread stuttered: the Bluestone clock, pistons, pulse generators, hoppers, carts, and even other plugins that share it (GlymeraBees). The world itself and NPCs kept running at full speed, which made it look like a client problem.
• The scan now runs as one batched job per world on the world thread, the same way pressure plates, hoppers and comparators already did. Behaviour is unchanged; only the thread is different.
• If your machines, carts or bees turned jerky after you built an observer-heavy contraption, this is the fix. Update recommended for every server running v100 or later.

v122.0.0 (2026-08-21) — Observers count every growth stage, even the ones that happened while you were away

• An observer watching a crop now emits one pulse per growth stage, not one per change. The game catches up plant growth in a single tick when a chunk wakes up — a seed you left behind comes back as a fully grown plant in one step. Previously the observer saw that as a single change and fired once, so any counter waiting for "four stages" stalled forever. Farms that count stages to time their harvest now stay in sync after you leave and return, after a restart, and after /time set.
• Works for every plant the game can grow — crops, mushrooms, plants added by other mods — because the stage list is read from the block's own farming data, not from a built-in list.
• Only forward steps within the same growth cycle count as multiple pulses; harvesting, replanting, a sapling turning into a tree and any non-plant change still give exactly one pulse. While you are nearby nothing changes at all — stages arrive one at a time as before.
• Background: machinery ticks within 8 chunks (256 blocks) of a player, observers and other sensors within 192 blocks, while chunks stay loaded much further out. Anything in between grows without being watched; this release makes that harmless.

v121.0.0 (2026-08-21) — Performance: the signal engine now works locally instead of world-wide

• A change now recomputes only the contraption it belongs to, not the whole world. Until now any lever, observer pulse, clock or pushed block rebuilt the entire world's signal network, every unrelated plot included. The engine now splits components into independent islands and recomputes just the affected one — about 15× cheaper under load, and a running clock no longer pays for everyone else's builds.
• Block classification (wire, repeater, conductor …) is cached per block type instead of being re-derived on every lookup.
• Behaviour is unchanged: old and new engine were run side by side through 36,000 ticks on 40 random worlds, including blocks being added, removed and pushed — zero differences. No configuration change.

v120.0.0 (2026-08-20) — Observers now catch every piston movement, however brief

• An observer watching a cell that a piston moves is now triggered instantly, the moment the block is pushed, pulled, or the piston head extends or retracts into that cell. Previously the observer only sampled its watched cell twice a second. A piston driven by a one-tick pulse (a counter firing, an observer pulse, a button through a repeater chain) pushes its block out and back within roughly 200 ms — often between two samples — so the observer saw the same cell before and after and never fired. Farms that use a piston to knock a crop loose and an observer to re-trigger the seeder would randomly skip a cycle.
• Behaves like a Minecraft observer: one pulse for the push and one for the retract. Growth stages, player edits and changes made by other plugins are still detected by the regular scan — those are never short-lived.
• No configuration change. Existing contraptions that happened to miss these short movements will now see them, which is the correct behaviour.

v119.0.0 (2026-08-19) — Pistons no longer power themselves through their face

• A piston's front face is now immune to power, exactly like in Minecraft. Previously a power source sitting in the cell a piston pushes into — most notably a Bluestone Block placed there to be pushed around — powered the piston itself, so it fired the moment the block was set down. A piston now takes power from its back and its four sides only; nothing that sits in front of its face activates it, whether that is a Bluestone Block, a repeater output or a powered solid block.
• This makes movable-power-source contraptions work: push a Bluestone Block with a piston and it powers whatever it lands next to — lamps, doors, other machines — without ever feeding back into the piston that moves it.
• Applies to both the piston and the sticky piston, in every orientation including up and down. No other component changes: lamps, hoppers, ejectors and applicators accept power from all six sides as before.

v118.0.0 (2026-08-11) — The persistence update: no restart can kill your machines

This release hardens the entire save/restore chain. Background: a CurseForge report of pressure plates staying dead after every server restart until re-placed — not reproducible on our servers, but the investigation surfaced three real weak spots. All three are closed.

Restores no longer depend on boot order

• Machinery used to be restored only when its chunk loaded after the plugin had started listening. Chunks the server loads on its own during boot — the spawn area, chunk-loader-pinned chunks, worlds that other plugins create — could slip through that window, and devices there stayed dead until broken and re-placed. Worse, a permanently loaded chunk never reloads, so there was never a second chance.
• A catch-up pass now runs 15 seconds after startup and once a minute from then on: it restores devices whose chunk is already in memory and hooks up worlds created at runtime. The pass only restores — it never deletes an entry and never forces a chunk to load. Cost is a handful of map lookups per minute, orders of magnitude below the normal component ticking.

A crash can no longer corrupt the device file

• The device registry (autonomous_blocks.json) is now written atomically: temp file, flush to disk, then rename. Previously a kill in mid-save — a host's force-restart button, a crash, a timeout — could truncate the file, and the next start silently swallowed the damage and began with an empty registry, wiping every device on the server.

Problems are reported to the admin instead of swallowed

• If the file cannot be written (missing permissions, full disk), the console now shows a single clear warning that placed devices will not survive a restart — previously this failed forever in silence.
• If the file is unreadable at startup, it is preserved as autonomous_blocks.json.corrupt for recovery, a pending temp file from an interrupted save is restored when possible, and a warning names what happened. The plugin never again starts silently with an empty registry.
• These are the only console messages in the plugin, and they only ever appear when something is actually wrong.

v117.0.0 (2026-07-27) — The Incinerator, and an Applicator that runs on its own

NEW — Bluestone Incinerator: a trash can for your sorting lines

• A heavy stone furnace that destroys everything pipes, funnels and ejectors push into it. There is no inventory to open and nothing that can clog: an incoming item is gone the moment it arrives, so all six sides can deliver at once without ever backing up. No burn time, no queue, no storage.
• The embers show the load. Five stages from cold to full glow: every delivery heats it one step (full glow after four items), and it cools one step every 0.6 seconds. The glow is real light with radius 4 / 7 / 11 / 15 — a working incinerator lights the room like a lamp that runs on rubbish.
• At full glow it throws sparks, shimmers with heat and crackles audibly within 7 blocks. All three effects are client-side: a glowing incinerator costs the server nothing, and a cold one stops ticking entirely.
• After a server restart it starts cold, so no incinerator is left glowing from a shutdown.
• Crafted from 4× Cobblestone + 2× Iron Ore + 1× Fire Essence at a tier-3 workbench. Ownership protection and piston resistance apply like for every other Bluestone block — only you and server admins can break it, glowing or not.

Applicator

• It no longer needs you standing there. Previously the Applicator did nothing unless the player who placed it was online and nearby — and that blocked all of it: placing blocks, breaking blocks, seeds, saplings, buckets. It now works for its owner whether they are logged in or not (like every other Bluestone component, the machine still needs some player within the ~192-block activity range).
• The right tool now gives the right result. The Applicator hands the tool to the block the way a player does: shears harvest leaves, vines, bushes and seagrass as blocks, a bark scraper strips a trunk in place instead of felling it, and a pickaxe on gravel yields its proper drops.
• Tools wear like in your hand — and a broken tool is no longer lost. Wear is calculated per tool and per block exactly as for a player, so soft blocks cost no durability at all. A tool that reaches zero stays in the magazine for repair; the Applicator skips it, takes the next intact tool, and stops if there is none — it never keeps working with a broken tool, and it notices a freshly restocked one on the next signal. Wear can be switched off with applicatorToolDurability: false in mods/de.glymera_GlymeraBluestone/config.json.
• Buckets are used the way a player uses them. A filled bucket places a fluid source per pulse, respecting content and charges — a bucket holding three charges of green slime places three sources — and the emptied bucket stays in its slot for refilling by pipe. Empty buckets are skipped as long as the magazine holds anything better; if it holds nothing but empties, the Applicator picks up the source in front of it instead and fills the bucket completely, exactly like a player would. Multi-charge buckets come from GlymeraBucket; without that plugin this branch stays inert.
• The magazine is still read slot by slot, lowest first: in a mixed magazine the front-most usable item decides what happens.

Housekeeping

• All console output was removed for this release — the plugin is now completely silent. This also removes the optional transfer tracing via plugins/GlymeraBluestone/debug_transfers that v112 introduced.
• Internal iterations v116.1–v116.17 are condensed into this release.

v116.0.0 (2026-07-24) — Pistons meet the bees: honey glue

• Honey blocks glue structures together. With GlymeraBees installed, a pushed honey block drags every touching movable block along — and honey chains to honey, so multi-block contraptions move as one unit (Minecraft-style flying-machine mechanics). The 12-block piston limit applies to the whole glued assembly; if a glued block's destination is occupied or would cross a plot border, the piston refuses the entire push, exactly like hitting an immovable block.
• Sticky pistons pull the assembly back. Retracting a sticky piston whose front block is a honey block pulls the whole glued structure with it. Creatures standing in the path of glued blocks are shoved aside like on a normal push.
• Piston bases and heads never stick (as in Minecraft — a piston would otherwise tear its own machine apart on retract). One deliberate deviation from Minecraft: immovable blocks (Bluestone components, containers, bedrock) simply don't glue instead of blocking the whole push — so honey stays usable right next to wires and lamps.

• Without GlymeraBees installed this feature is completely inert — zero behavior change.

• Pistons nudge their surroundings awake (v115.1). Every cell a piston head clears or fills now receives the same neighbourhood update a native block edit performs: water and other fluids beside the moved cells re-settle immediately (flowing into vacated cells instead of sleeping through the change), and unsupported blocks above vacated cells fall as expected.

v113.0.0 (2026-07-15) — Carts can no longer turn around

• Reversed carts after a restart: fixed for good. The v112 direction recovery still had one blind spot: if the server saved while a cart was in the second half of a curve exit, the recovery fell back to a stale heading and the pathfinder could pick the reverse ring direction (it depended on the curve's orientation — which is why it felt random and rare). The pathfinder now always starts from the cart's exact bookkeeping cell (persisted with the cart) and the cell the cart just came from is off-limits for the first step — turning around is structurally impossible, no matter how stale the saved heading is. The only exception is a true dead end, where reversing out remains allowed.
• Existing carts migrate automatically; a cart that is currently driving the wrong way keeps its (valid) data — break it and place it again to send it off in the right direction.

v112.0.0 (2026-07-12) — The Reliability Update: carts that never vanish, pipes that never leak, and a world that sleeps

Twenty maintenance versions in one package. No new blocks this time — instead, every moving part of the system got measurably more reliable, more predictable and cheaper to run. Three changes affect existing builds and are marked [BEHAVIOR CHANGE] below.

NEW — The Sleeping World: machinery only runs with an audience
- All self-driving Bluestone machinery (pipes, funnels, comparators, daylight sensors, pressure plates, observers, idle pulse generators and cart management) now pauses when no player is within ~192 blocks (~6 chunks) — and resumes seamlessly, loss-free and in the same state the moment someone approaches. Nothing is skipped, dropped or double-fired by the freeze itself.
- Signal transport is deliberately NOT gated: a lever signal still crosses the boundary and distant lamps, doors and pistons still react to it. Only the self-running machinery sleeps.
- Why: the game engine parks all entities and puts chunks to sleep without players anyway — machinery that fought this (see cart fixes below) caused every category of weirdness we chased this week. Now Bluestone stops before the world sleeps, which also structurally prevents items from being lost at sleeping chunk borders.
- Build tip (also in the plugin description): chunks wake in a ring around you as you approach, so parts of a huge machine wake before others. Keep timing-critical machines compact — ideally within one chunk (the in-game grid tool helps). For true 24/7 operation far from players, use a chunk loader.

Carts — the big reliability overhaul
- Disappearing carts: fixed. A cart crossing a chunk border could get duplicated by the respawn logic and later culled by the engine — taking the cart and its cargo with it. Carts now re-attach to their existing entity instead of blind-spawning, and a destruction is only accepted once it is confirmed real.
- Merging carts and scrambled order: fixed. Without players nearby, the old watchdog respawned parked carts in an endless carousel (24,000 spawns in one night!), producing overlapping "invisible" carts and shuffled trains. The audience gate above ends this for good — formations and cart order now survive any absence.
- Station queues. Arriving carts no longer pile onto an occupied station cell: they queue up behind it, one per cell, any train length. Powering the booster releases the front cart and the queue rolls forward on its own — followers flow automatically (no extra pulses needed), always at exactly one cell spacing, and stop cleanly at the queue's end instead of teleporting or overlapping.
- Sleeping-chunk safety. A driving cart now waits at the edge of a sleeping chunk instead of driving into it and freezing mid-track (this was the cause of "6 carts left, 2 came back stacked").
- Hopper Carts no longer dump into pipes running under the track. The cart's vertical exchange (dump below / intake above, through one support block) now only accepts real containers and standing funnels — a funnel opening upward under the rail still catches the cargo (that's the intended station unloader), but a lying pipe merely passing underneath has no upward opening and is ignored, matching what the models show.
- Placing a cart on a cell that already holds one is now rejected (item returned) — stacking two carts on one cell was the root of several ghost-train reports.
- After a server restart, carts recover their true driving direction from the track (previously a mid-curve save could flip them at the next junction).
- The Chest Cart now uses the proper minecart body with a golden tint — visually consistent with the other two carts, same 27 slots.

Pipes — honest item flow
- [BEHAVIOR CHANGE] The mouth rule. Non-pipe containers (chests, benches, carts) are now only served through the pipe's mouth (the arrow/placement direction). Previously any adjacent container counted as an outlet, so a chest merely sitting beside or below a passing line silently siphoned items out of it — closed loops drained themselves into a neighbour's collection chest. Pipe-to-pipe connections are unchanged (they connect on any touch, as the flanges show). Migration: if you filled a chest from the side of a through-line, point the last pipe segment at the chest.
- [BEHAVIOR CHANGE] Even pacing. Items travel exactly one segment per transfer tick (5 items/s per line) instead of occasionally "sprinting" several segments unseen — comparators along a line now light up in true flow order. Existing sprint-lucky lines are accordingly a touch slower, but uniform.
- Full pipes keep delivering. A pipe under continuous inflow no longer hoards until the source runs dry — inflow and outflow now run simultaneously (1 in / 1 out per tick). Chest→pipe→chest chains deliver the first item after ~0.6 s, not after the source empties.
- Cross-chunk item loss: fixed. Transfers into or out of a chunk that is falling asleep were the one confirmed way an item could truly vanish. Transfers now stop at sleeping chunk borders (and, thanks to the Sleeping World, stop before borders sleep at all).
- Deterministic loop direction. Freshly inserted items (and all items after a restart) start in the pipe's arrow direction — a closed loop no longer re-rolls its rotation direction every server restart.
- Pipes visually dock onto containers. A pipe run now extends all the way to the chest/bench it serves (arm + flange at the block border) instead of stopping half a block short. Sideways neighbours deliberately get no arm — what you see is exactly what connects. Existing lines refresh the moment you place/break anything next to them.

Signals & components
- [BEHAVIOR CHANGE] Components no longer conduct like solid blocks. A signal can no longer skip through the body of a counter, repeater or other component and bypass its logic — it has to go through the component's actual input. If a build relied on feeding a signal through a component's block body, route it around (or through) the component properly.
- No more phantom edge after restart. Applicators, Ejectors and Counters connected to an always-ON source no longer fire/count once out of nowhere after a server reboot — they silently adopt the current level at boot. (Pistons intentionally keep their boot re-extend; that behaviour is load-bearing.)
- Pulse generator locked to the engine grid. The "pulse, pulse, pause" beat at fast settings is gone — pulses now land exactly on the signal engine's own tick, are perfectly even, run cheaper, and equal-frequency pulse generators tick in sync.
- Lamps that stayed lit after their off-edge fell into an unloading chunk now heal on chunk reload.

For tinkerers
- Optional transfer tracing: create the empty file plugins/GlymeraBluestone/debug_transfers and every pipe pull/push/pickup and cart transfer is logged with item and coordinates. Delete the file (and reboot) to switch it off. Default is off.

v91.0.0 (2026-07-09) — The Rails & Automation Update: minecarts, daylight sensor, a farming applicator & fair repairs

This release bundles everything since v80 into one big update: a complete rail logistics system with three driverless carts and four signal rails, a Daylight Sensor that measures real light, an Applicator that can farm — plus ownership protection for carts, several recipe corrections and an important set of item-durability fixes.

NEW — Rails & Carts: driverless logistics on tracks
- Bluestone carts run on the game's normal rails — no driver needed. The server drives them at a steady 5 blocks/s through straights, curves and slopes. Any number of carts can share one track, and any number of stations can share one line.
- Booster Rail — the start/stop logic of the whole system: while powered, a cart on it departs (or rolls straight through); unpowered it is a station — every arriving cart stops and parks there until the rail is powered again. Powering a booster instantly wakes every cart parked on it.
- Sensor Rail — the detector: glows and emits a full-strength signal (15) the moment any Bluestone cart is on it, moving or parked. Feed it into wire, lamps, doors — anything.
- Switch Rail — junction control: place it where the track branches. Unpowered, carts run straight; powered, they take the branch. Flipping the signal re-routes traffic instantly.
- Activator Rail — a mode-setter for Hopper Carts: driving over a powered activator switches the cart's item intake off, an unpowered one switches it back on. Because it sets a state instead of toggling, several activators in a row behave deterministically — the last one wins.
- Three carts, each with its own look and job:
- Bluestone Cart — the plain runner. No inventory; its job is presence: it trips Sensor Rails along its route, making it a travelling trigger, a patrol clock, or simply a cheap test vehicle.
- Chest Cart (golden, open-box body) — 27 slots of rolling storage. Passive by design: load and unload it with Hopper blocks placed at the track.
- Hopper Cart (steel-blue) — 9 slots and hungry: while its intake is on, it pulls from a chest above the track and dumps into a chest below it — through one solid support block in both directions, exactly like the classic under-track hopper trick. Combined with Activator Rails you decide precisely where along the line it loads and where it delivers.
- The Comparator reads carts. Point a comparator at a rail cell and it outputs the fill level of the cart standing there: plain cart = 15 (pure presence), container cart = 1–15 proportional to its used slots, empty container cart = 0. "Wait until unloaded, then depart" is now a three-block circuit.
- Hopper blocks load and unload carts too: a hopper feeding a track cell fills the cart standing there, a hopper drawing from a track cell empties it.
- Carts are fully persistent: they survive server restarts and chunk unloads with their inventory and continue their journey when the area loads again — and the engine never duplicates them. Destroying a cart drops the correct cart item and spills its contents; nothing is ever lost.
- Carts driving through unloaded terrain simply wait at the loaded edge (only loaded chunks tick — use a chunk loader for cross-country freight lines).

NEW — Daylight Sensor
- A flat plate (pressure-plate height) with a sun engraving that lights up golden while the sensor emits.
- It measures the real light in the cell directly above itself — not just the time of day: signal strength = the brighter of sky light × sun position and artificial block light. Full daylight = 15, dawn/dusk = less, night = 0 — but a torch next to it keeps it lit at night, and covering it with any solid block forces it to 0 (glass and leaves let light through, so a glass roof works).
- That makes both classics trivial: "lamps on at night" (sensor + torch inverter) and light-threshold switches via signal strength.
- Crafting: 2× Bluestone Wire, 2× Copper Ore, 1× Iron Bar at a Tier-3 Workbench.

NEW — The Applicator learned to farm
- Seeds: with seeds in its magazine and tilled farmland in front of it (the crop cell must be free, the soil below must fit — watered and fertilized farmland included), a signal plants the crop. All 34 seed types work, including the Eternal variants; the alchemy crops (Health/Mana) correctly demand crystal soil.
- Saplings: same logic on normal soil — a signal plants the tree.
- Water: with a filled water bucket in its magazine it places a water source in front of itself and keeps the empty bucket in the magazine (refill it by pipe and the cycle continues).
- Deliberately conservative: if the ground or the target cell doesn't fit, nothing happens — the Applicator never throws seeds away, never uses them to break blocks, and never places a full bucket as a decoration block. Combined with pipes for seed supply and a harvester of your choice, the full field cycle is now automatable.

Ownership protection now covers carts
- Every newly placed cart remembers who placed it. Other players (and TNT, and mobs) can no longer smash your carts — they get "this cart isn't yours" and the cart stays intact. Owners and admins break them normally. Carts placed before this update have no recorded owner and stay unprotected until replaced.

Fair repairs — durability is preserved everywhere
- Fixed three places that silently returned items as new: the Hopper's push step (every damaged tool travelling through a pipe line arrived fully repaired!), the Ejector's throw, and cart inventories across a server restart. All three now preserve durability and metadata exactly. The free repair machine is closed.

Recipe corrections
- Sticky Piston: the sticky ingredient is now 2× Tree Sap (harvested from the sap globs growing on trees) — the previous ingredient turned out to be unobtainable in survival.
- Bluestone Block: now 5× Bluestone Wire (was 9×).
- All three carts now correctly require a Tier-3 Workbench like the rest of the family.
- The Lamp's crystal ingredient finally shows its proper name ("White Crystal Block") in recipe tooltips.

Reliability (the invisible arc)
- Rail parts (Sensor / Switch / Activator) placed before a restart could lose their engine registration when their chunk reloaded — sensors kept glowing but stopped signalling. Fixed at the root, and every rail part now also self-heals on first contact (a cart passing over, a route being planned).
- A cart placed onto an already powered booster now starts immediately (previously the rail had to be switched off and on again).
- Hopper Cart transfers work through the chest's support block (chests can't float), so real station layouts work exactly like you'd build them intuitively.
- The Hopper Cart no longer vacuums loose items off the ground — that's the upright funnel's job; the cart focuses on chest-to-chest logistics.

v80.0.0 (2026-07-05) — The Identity Update: Signal Counter, wood insulation, build protection & a complete visual overhaul

This release bundles everything since the last published version into one big update. Every single component now has its own unmistakable 3D look, three brand-new gameplay systems arrive (the Signal Counter, wood as an insulator, and ownership protection), and dozens of behaviour fixes make circuits more predictable than ever. Highlights below; the detailed history follows in the sections underneath.

NEW — Signal Counter
- A new circuit-board block with six little lamps on top. The number of burning lamps is its setting: 1 lamp = every incoming pulse passes straight through, 3 lamps = only every third pulse gets through, and so on up to 6. Press F to cycle the setting 1 → 6 (stored in the block itself — survives restarts and chunk reloads).
- Strictly directional like the repeater: it counts pulses arriving at its back and fires exactly one pulse out the front when the target is reached, then starts counting from zero again. While it fires, the burning lamps flash bright white.
- The killer combo: point an Observer at a crop and put a Counter behind it. Carrots change 3 times while growing, wheat/corn/potatoes/pumpkins 4 times, tomatoes up to 6 — set the counter accordingly and your farm circuit fires exactly when the crop is ripe, not on every growth stage.
- Crafting: 2× Iron Ore, 2× Copper Ore, 1× Charcoal at a Tier-3 Workbench. (The current count is intentionally not saved over a server restart — the setting is.)

NEW — Wood insulates
- Until now, every solid block conducted a signal (weak/strong powering) — there was no way to deliberately separate two lines running through a wall. Now there is a clear, physical rule: signals travel through stone, but never through wood. All ~800 wooden blocks count — planks, trunks, beams, wooden stairs, even wooden furniture, crates and workbenches. Use any wooden block to cleanly insulate parallel lines or shield a machine from a neighbouring circuit.

NEW — Your circuits belong to you
- Every Bluestone block now remembers who placed it. Other players can no longer break your components, open your Ejectors/Hoppers/Applicator magazines, or change settings (repeater delay, counter target, pulse speed, filters, piston orientation).
- Deliberately still public: operating things. Anyone may pull your levers, press your buttons and step on your pressure plates — public doors and machines keep working for everybody.
- Server admins bypass the protection entirely. Blocks placed before this update have no recorded owner and stay unprotected until replaced.

Every component got its own 3D identity (the "optics" arc, v36–v72 — details in the sections below)
- Wire is now a real pipe network: octagonal conduits that only grow arms toward actual connections, with couplings, a glowing dashed core line, junction cubes — and true hitboxes and selection outlines that match the shape.
- Torch = a masonry block with recessed fire bowls on five sides (orange = idle/inverting, blue = powered output) and an engraved socket on its input side.
- Repeater = a flat circuit board with an engraved direction arrow, a fixed output stub and a second glow-stub that physically moves back as you raise the delay (F key, 1–4 ticks). Locked repeaters show a green cross-bar meeting the repeater that locks them.
- Comparator = the repeater's sibling board with three lamps in the classic layout. It reads the container behind it (double chests work on both halves now) and can also be mounted flat on top of or hanging under a container. Lamps show red while it outputs nothing, blue while it outputs a signal.
- Observer = a crystal eye recessed in a face plate; it watches the block in front and pulses out of its five other sides. (The watched face itself never emits — no more accidental feedback clocks.)
- Lever, Button and Pulse Generator = the "cage" family: identical armored housings with a window on every side so you can see the actual mechanism inside — the flip-lever, the press-cap, or the floating clock crystal that blinks red/blue in time with the pulses. Corner markers tell them apart at a glance: squares = lever, triangles = button, diamonds = pulse generator.
- Pressure Plate = an actual flat plate that visibly sinks when stepped on (walking over it triggers it — no more climbing onto a full block).
- Ejector = a full block with a deep ejection funnel: black cone, thin white spiral winding to the outlet.
- Applicator = a machine chuck with four gripper claws around the working face and engraved magazine slots.
- Every inventory icon was re-rendered so you instantly see what a block is — cage blocks show their inner mechanism, boards are shown from above, face blocks head-on.

Behaviour & reliability (the fixes arc)
- Air isolates. A source next to an air gap no longer powers a consumer across the gap.
- Bluestone components are piston-proof. Pistons refuse to push or pull any Bluestone component (which used to leave broken registrations behind) — the two deliberate exceptions, exactly like the originals: the Lamp and the Bluestone Block move and keep working. Foreign piston heads are respected, never overwritten, and never deleted by another piston's retraction.
- Farmland moves intact. Pushing tilled soil no longer destroys it (the crop on top pops off, as expected) — automatic farms with moving soil are possible.
- Placement order never matters. Placing a lever/button next to existing wire now connects instantly (this was the last component that didn't announce itself on placement).
- Pulse rhythm is deterministic. A pulse generator's output is exactly one engine tick per pulse — the "pulse, pulse, pause" stutter is gone, and every visible flash keeps its guaranteed minimum length.
- No more break particles when a block merely changes state or variant (placing directional blocks, cycling settings, lamps switching, pistons extending). Real destruction still shows particles and drops.
- Comparator placement is anchor-based. Look wherever you want while placing: you get the on-top/hanging variant only when there really is a container below/above the target cell, otherwise always the normal floor board.

v67.0.0 – v72.0.0 (2026-07-03/04) — Ejector funnel, Pulse cage, Comparator board

• Ejector: new full-block design with a facetted ejection funnel on the output side — black cone with a thin white spiral winding toward the outlet, engraved muzzle ring and rivets. Up/Down variants match.
• Pulse Generator: joined the cage family (window housing, diamond corner markers). Inside floats the clock crystal — a tip-standing cube over a metal pedestal that blinks red/blue with every pulse. Since the pulse generator emits on all sides, all sides now honestly look the same (the old directional lightning-bolt texture was a lie).
• Fixed an engine-level timing bug where a pulse could "stick" for half a second when the engine tick missed the generator's short active window — the audible/visible rhythm is now perfectly even.
• Comparator: rebuilt as the repeater's sibling circuit board (see release summary above) with container reading behind/below/above, rotating state models and a ceiling hitbox for the hanging variant.

v59.0.0 – v66.0.0 (2026-07-03) — Cage switches, flat pressure plate, wire end caps, air isolation

• Lever & Button: the cage design — six identical armored faces with windows, the real mechanism visible inside (tilting lever with glowing knob / press-cap that retracts), corner lights on every face (red = off, blue = on), and a lower frame band sized so wire pipes and repeater stubs always dock into solid frame, never into a window.
• Pressure Plate: now an actual flat plate (11 % block height) that sinks when stepped on. Walking across triggers it. Same textures, same behaviour, fixed low hitbox.
• Wire end caps: every free pipe end (toward plates, doors, or nothing) is closed with a dark cap — no more looking into a hollow pipe. Wire-to-wire and wire-to-block joints are visually unchanged.
• Air isolates (important engine rule fix): sources used to seed their strength into all six neighbour cells including air, so a consumer behind a 1-block air gap could trigger. Signals now only enter real conductors — components and solid blocks. (Wood joined the non-conductors in v80.)

v53.0.0 – v58.0.0 (2026-07-03) — Observer eye, Applicator chuck, honest outputs

• Observer: crystal eye in a recessed socket with brow grooves, output stubs with pulse arches on its emitting sides, a full docking ring on top and a recessed socket below.
• The observer's face no longer emits a signal — it used to power the very block it was watching, which caused accidental feedback clocks. Output remains on the other five sides; the optics now match the behaviour exactly.
• Applicator: machine-chuck design — a working aperture with a static red energy core and four gripper claws reaching toward the target cell, magazine slots engraved on the sides. No states, no logic changes.

v47.0.0 – v52.0.0 (2026-07-03) — Repeater circuit board & pipe hitboxes

• Repeater: redesigned as a flat masonry circuit board: engraved dashed direction arrow in state colour (red off / blue on / green locked), fixed output glow-stub, and a delay stub that physically moves backward as you cycle 1–4 ticks with F — you can read the delay from across the room. Locking shows as a green cross-bar spanning the board, visually meeting the repeater that locks it. Docking stubs sit exactly on the wire axis, so pipelines connect seamlessly.
• Item pipes got real hitboxes: all 14 pipe shapes (straight/elbow/T/cross/ends) now collide and show selection outlines matching their actual geometry — no more invisible full-block boxes. (The upright funnel intentionally stays a full block.)

v42.0.0 – v46.0.0 (2026-07-03) — The torch block

• Torch: now a solid masonry block with recessed fire bowls on five sides — mini torch stumps with real flame particles (orange = idle, i.e. inverter armed; blue = powered output, with real light) — and an engraved socket port on the input side. State names and logic untouched: it is still the NOT gate you know.
• Solved a subtle engine limitation along the way: custom model UV offsets must be integers, or the client silently rejects the model. All generated models are verified integer-clean since.

v36.0.0 – v41.0.0 (2026-07-03) — Wire becomes a pipe network

• Wire: complete visual rebuild from glowing cubes to a real conduit network. Octagonal pipes that grow arms only toward actual connections (sources, repeaters front/back, consumers, doors — never toward hoppers or piston heads), junction cubes where lines meet, pipe couplings every 12 blocks, and a glowing dashed core line running along the top — red idle, blue powered, patterns flush across every joint.
• Real hitboxes and selection outlines for all 64 wire shapes: you aim at and collide with the actual pipes, and you can walk over low runs.
• Isolated wires show as a compact junction cube; straight-through runs form one continuous pipe without a middle knot.
• Under the hood this introduced the central registration hook that keeps wire arms correct on placement, breaking, chunk loads and restarts — for every component type at once.

v35.0.0 (2026-07-03) — Adjustable repeater delay confirmed & "swallowed pulses" fixed for good

The adjustable repeater delay is here to stay.
- Press F on a repeater to cycle its delay: 1 → 2 → 3 → 4 ticks (0.1–0.4 s), shown as dots in the arrow's colour on the repeater's face — red when off, blue when powered, green when locked. Rotation, power state and lock state are preserved while cycling.
- The delay lives in the block itself, so it survives restarts, chunk reloads and even being moved by pistons — no extra bookkeeping, no data files.
- For longer delays, chain repeaters: e.g. three repeaters at delay 4 = 1.2 seconds.

Fixed — fast pulse trains looked like they "swallowed" pulses.
- With a pulse generator on the fastest setting, repeaters sometimes seemed to skip pulses. A deep timing analysis proved the logic never lost a single pulse — but when the server's world thread briefly stalled, the engine caught up by running two ticks back-to-back, and the ON and OFF edge of a one-tick pulse collapsed into the same instant: the flash became too short for the human eye (measured: 17% of output flashes were under 40 ms).
- The engine now enforces a minimum real-time spacing of 60 ms between ticks: a catch-up tick that would run almost simultaneously with the previous one is skipped, and its pending switches simply run a few dozen milliseconds later. Nothing is lost, order is preserved, and every visible pulse is now guaranteed to be at least ~60 ms long. Verified with a stress build (two synchronized pulse generators, mixed-delay repeater chains, pistons, hoppers): 0 invisible pulses, 0 lost pulses.

v32.0.0 – v34.0.0 (2026-07-02/03) — internal iterations (superseded by v35)

• v32 temporarily removed the adjustable delay while the "swallowed pulses" report was investigated; v33 was an instrumented debug build whose timing log identified the true cause (tick bunching after world-thread stalls — a display artefact, not a logic bug); v34 introduced the minimum tick-spacing fix. v35 is the clean release of that work with the delay feature restored and all debug instrumentation removed.

v31.0.0 / v30.0.0 (2026-07-02) — internal iterations on the delay cycle (superseded by v32)

• v30 moved the delay cycling to the Pre-use event with real state-change mappings; v31 fixed state-mangled runtime block ids (*…_State_Definitions_…) breaking the variant lookup on active repeaters. Both are obsolete with v32 removing the feature; the state-mangling insight is kept in the code where ids are parsed.

v29.0.0 (2026-07-02) — Delay dots on the repeater, piston-head duplication fix, no more swallowed pulses

NEW — the repeater shows its delay as dots
- The repeater's top face now shows 1–4 small dots in the arrow's colour — one dot per tick of delay (0.1 s each). Right-clicking cycles the delay as before; the dots update instantly and keep the arrow-colour convention: red = off, blue = powered, green = locked.
- Under the hood the delay now lives in the block itself (three hidden block variants per orientation), so the setting is stored by the world: it survives restarts, chunk reloads and even being moved — with no extra bookkeeping. Rotation, on/off state and lock state are preserved when cycling. All delay variants drop the normal Bluestone Repeater item when broken.

Fixed — piston-head duplication when pushing a lamp out of a wire row (report)
- Pushing a lamp that sat between wires could conjure a second piston head at a right angle to the real one, destroying a wire in the process. Root cause: the freshly placed piston head's block id contains "BluestonePiston", and the engine — still iterating its component snapshot from before the push — mistook the head at the lamp's old cell for a piston and "activated" it (its arbitrary rotation supplied the sideways direction; its extension is what popped the wire).
- Fixed on three levels: piston heads are never treated as components anywhere (engine role, consumer edges, activation), consumer edges now fire after the engine pass completes instead of mid-iteration, and every edge re-checks that its target still is a consumer. The whole class of "world changed mid-pass" bugs is gone.

Fixed — repeaters swallowed pulses when a delay was set (report)
- A repeater with delay 2–4 fed by a pulse generator (or any fast input) skipped pulses: the engine kept only one pending switch per repeater, so with longer delays a pulse's off-edge overwrote its own on-edge. Pending switches are now a proper queue — every edge travels through independently with the configured delay, pulses keep their duration, and clocks feed through repeaters at any delay setting. (Delay-1 repeaters were never affected, which is why freshly placed ones seemed fine.)

v28.0.0 (2026-07-02) — Fix: a single wire between a source and a block now powers the block

• Lever → wire → stone block → torch did nothing — the signal stopped at the block. The "wire points into a block" rule only counted another wire behind the wire as line continuation, so a strand of length 1 (fed directly by a lever, button, plate, comparator, pulse, torch or repeater) never counted as pointing anywhere. Exactly like Minecraft dust, which visually connects to power components, the continuation check now also accepts a source, repeater or torch behind the wire — so the classic 1-wire NOT gate works. Consumers (pistons etc.) deliberately do not count, matching MC.
• No other behaviour changed; pure engine-rule fix on top of v26/v27.

v27.0.0 (2026-07-02) — Locked repeaters show a green arrow

A locked repeater is now visible at a glance
- When a repeater is locked (a powered repeater points into its side, v26 feature), its arrow turns green: a bright green arrow means it is locked while outputting a signal, a dark green arrow means it is locked in the off state. Unlock it and the normal red/blue arrow returns.
- Works for all three repeater orientations, updates only on a real state change (no extra cost), and repairs itself after a restart or chunk reload — a green arrow can never get stuck (wires/repeaters reset to a neutral idle state on load before the engine re-asserts the truth, now including the locked states).
- Right-clicking a locked repeater still cycles its delay setting.

v26.0.0 (2026-07-02) — Powered blocks, adjustable repeaters, the Bluestone Block & piston-vs-component fixes

The Minecraft-parity update: the three biggest gaps between Bluestone and classic redstone circuitry are closed. Standard redstone tutorial builds (NOT/AND gates, latches, T-flip-flops, torch towers, signals through walls, timing chains) now translate 1:1.

NEW — solid blocks can carry a signal (weak/strong powering)
- A powered wire now powers the solid block its line runs into (and always the block directly beneath it, like dust powering its floor). Anything attached to or next to that block reacts: a torch on a powered block turns off (the classic NOT gate — no repeater workaround needed anymore), doors/lamps/pistons behind a 1-block wall respond, and a repeater reads a powered block behind it.
- A block fed by a repeater output, by the cell above a burning torch, or next to an active source (lever, plate, button, comparator, pulse, power block) is strongly powered: it re-feeds adjacent wire, so a signal can be routed through a wall and continue on the other side — exactly the MC rule set.
- Deliberately MC-faithful: wire-powered blocks are only readable (weak) and never re-feed wire — otherwise every signal would leak through every wall and the 15-block range would be meaningless. A wire running parallel past a wall does not power it; only a line ending into it does.
- Performance: computed inside the existing event-driven engine pass (a handful of map lookups and at most one block read per candidate cell) — idle circuits still cost nothing.

NEW — adjustable repeater delay (1–4 ticks) + repeater locking
- Right-click a repeater to cycle its delay: 1 → 2 → 3 → 4 ticks (0.1–0.4 s), with a chat message showing the new value. Both edges use the same delay, so pulse length is still preserved through any chain. Default stays 1 tick; the setting survives restarts and chunk reloads (stored in the repeater's existing persistence entry).
- Repeater locking: a powered repeater whose output arrow points into the side of another repeater locks it — the locked repeater freezes in its current state and ignores input changes until the lock is released (MC's standard building block for clocked memory cells). No extra cost: evaluated only for registered repeater neighbours during a recompute.

NEW — the Bluestone Block (placeable constant power source)
- The counterpart of MC's Block of Redstone: a solid block that permanently emits full signal strength 15 on all six sides — feeds wire, activates any adjacent device, and powers neighbouring solid blocks. No state, no scan, zero idle cost.
- Pistons can push it (and a sticky piston can pull it), and it keeps working at its new position — the foundation for piston-based T-flip-flops and movable activators.
- Glowing "energy core" look in the exact blue of an active wire, with circuit traces that visually connect to neighbouring Bluestone blocks; rendered 3D inventory icon; crafted from 9× Bluestone Wire at the Workbench (Tier 3) — the MC recipe, translated.

Fixed — pistons vs. Bluestone components (the "pushed active wire" report)
- Pushing a wire, repeater, torch, lever, button, pressure plate, pulse generator or comparator used to relocate it as a bare block: the device arrived dead at its new cell (its registration, rotation and active state stayed behind), signals froze, and the registry kept a ghost entry forever. An active lamp was even relocated as its permanently-lit internal block and could never be switched off again.
- Now MC-faithful: those attachment-style components pop off as their item when a piston pushes them (or pushes a block into them) — with proper drops and a full unregister, so nothing leaks. Native doors pop too instead of being torn apart.
- Observer, Lamp and the new Bluestone Block are genuinely movable: the piston relocates them and migrates their registration/persistence, so they keep working at the new position (a moved lamp that lost its signal turns itself off).
- A sticky piston no longer pulls attachment components, doors or containers (chests etc. were previously pulled by bare block-id, silently losing their inventory!) — they simply stay put, like in MC.
- Breaking an idle wire/repeater by hand also left its registry/persistence entry behind (only active ones were cleaned up); now every break unregisters fully, including a repeater's delay setting.

Changed — pistons now accept every signal source
- Pistons react to the signal engine like all other consumers: direct lever/button/torch/comparator control works again (the v17 restriction predated the v19 engine rewrite whose single synchronous tick removed the race that restriction worked around), and a piston behind a powered wall extends. Wire and repeaters keep working exactly as before.

Performance — three permanent polling loops removed
- Lamp, Ejector and Applicator are now driven directly by the signal engine's on/off edges instead of each being polled every 100 ms (6 block reads per device, 10× per second, around the clock — even when nothing ever changed). An idle device now costs nothing at all. The Applicator additionally loses its private self-rescheduling timer per placed block.
- Fewer scheduler round-trips: comparators, hoppers and pressure plates are now processed in one batched task per world per interval instead of one task per device. With 50 hoppers that is ~10 task dispatches per second instead of ~500. Same actions, same world thread, same order — just without the queueing overhead.
- Behaviour of active circuits is unchanged: the ejector keeps its trigger cooldown, the applicator keeps its owner permissions, hoppers/pipes/filters move items exactly as before.

Fixed — lamp next to a torch was inverted
- A lamp placed directly next to a Bluestone torch used to light up when the torch was logically off (and stay dark while the torch was burning blue). The lamp now follows the real torch output. Signals routed through wire were always correct.
- On chunk load, a lamp saved as ON with no signal present switches itself off (same self-healing as wires and doors).

Consistency — uniform trigger sources for all consumers
- Ejector and Applicator now respond to every signal source next to them — including pressure plates, torches and comparators, which previously did not trigger them.
- The repeater now powers only the block at its output arrow (true diode behaviour); devices touching its sides no longer trigger.

v24.0.0 (2026-07-02) — Doors respond to signals again

Fixed — "I can't open the doors using the pressure plates."
- Native doors now respond to Bluestone signals, exactly as the pressure-plate description promises. Any signal next to a door opens it — pressure plate, lever, button, wire, repeater, torch, pulse generator or comparator — and when the signal ends, the door closes again automatically. A button therefore opens a door briefly and it shuts by itself after the pulse.
- The door opens away from the signal side (a plate in front of the door swings it away from you, a plate behind swings it towards the walkway), matching how doors behave when opened by hand.
- Both door cells count: a signal at head height works just as well as one at floor level.
- Doors need no setup and no extra placement rules — put a door next to any Bluestone part (or a Bluestone part next to an existing door) and it just works, surviving chunk reloads and server restarts. On reload, a door left open without a signal is closed automatically (same self-healing the wires already do).
- Opening or closing a door by hand still works at any time; the signal only moves the door when it actually switches on or off.
- Background: door support was silently lost in the v19 engine rewrite — the door logic still existed but was no longer wired up to the new signal engine. It is now a first-class signal consumer.

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.