Most redstone guides teach you what to build. This one teaches you why it works — and why some things that look broken are actually features.

We are covering three connected topics: quasi-connectivity, BUD switches, and observers. They are related, and understanding the relationship separates builders who copy designs from builders who invent them.

Version-pinned to Minecraft 1.21.4 Java Edition. Bedrock handles block updates differently and most of this does not apply there.

Block updates — the foundation

Every piece of redstone reacts to block updates, not directly to redstone power. When a block changes state — a piston extends, a block is placed, a lever is flipped — Minecraft sends a block update event to the 6 adjacent blocks (and some additional neighbours, depending on the block type).

Those adjacent blocks receive the update and react: a piston recalculates whether it should be powered, a comparator re-reads its input container, a redstone wire re-checks its connectivity.

This matters because update order and update type determine when and whether things fire. Two categories of update:

  • Redstone-update (RU) — sent when redstone signal strength changes (wire receives or loses power)
  • Block-update (BU) — sent when a block changes (block placed, broken, or state-changed)

Most redstone components react to both. A few react to only one. This asymmetry is the source of everything below.

Quasi-connectivity — the "bug" that became a feature

In Minecraft's Java Edition, a piston can be powered by a redstone signal one block above the block directly behind its head (the block that would power it normally). This is called quasi-connectivity (QC).

More precisely: a piston checks for redstone power at its own position AND at the position one block above its trigger position. If power is present at either location, the piston activates.

[air  ] ← power here fires the piston (quasi-connectivity)
[piston facing right]
[power source here fires normally]

This was a side effect of how Mojang implemented piston power checking using the same code as doors — a door checks the block at its base AND the block above for power, to handle pressure plates and buttons at two heights. Pistons inherited this check without inheriting the reason.

Mojang's position on QC (paraphrased from old documentation): "It's been there long enough that removing it would break too many builds. It's staying." They have explicitly kept it intentional. It is not going away.

Why does this matter? QC means you can power a piston indirectly through updates from positions that don't directly connect by normal redstone logic. This is the mechanism behind BUD switches.

BUD switches

A Block Update Detector (BUD) is a circuit that activates when it detects a block update in a specific location, regardless of whether redstone power has changed.

The classic BUD switch uses quasi-connectivity: a piston is placed such that it is in a state of "almost" being powered — power exists at the quasi position but the piston is locked by another mechanism. When a block update occurs near the piston, the piston re-evaluates its power state and fires.

The simplest T-BUD (Tileable BUD):

[repeater → → ] [block]
                  ↑
              [piston facing up]

The piston is powered by QC from the repeater above it, but normally the piston cannot extend because... it has already extended and is locked by a self-locking mechanism. When a block update comes from the target location, it breaks the lock and the piston fires, then resets.

In practice, BUDs are used for:

  • Detecting when a tree has grown (the new log blocks trigger an update on adjacent BUDs)
  • Detecting when a crop reaches maturity
  • Detecting when a player places or breaks a block in a specific location
  • Triggering systems on natural world events without a clock

The problem with BUDs in 1.21.4

BUD switches are sensitive to update order, which is sensitive to chunk loading order, which changed subtly between major versions. Designs that were robust in 1.19 may misfire or fail to trigger in 1.21.4.

Before using a BUD switch in a production farm, test it on a disposable world in 1.21.4 specifically. If it misfires, try a different BUD design — the schematic matters, not just the principle.

Observers

The observer block was added in 1.11 specifically to detect block updates and emit a redstone pulse. It made most BUD switches obsolete for the common use cases.

An observer:

  • Faces a target block
  • Emits a 2-tick (100ms) pulse when the target block's state changes
  • Detects block placements, block breaks, block state changes (crop growth, door open/close, etc.)

What observers detect: block state changes, not redstone changes. A redstone wire changing power does not trigger an observer watching it (the wire's block state doesn't change when power flows through, only when the wire's connectivity changes).

What observers do not detect: a player walking through the observed space, entities, or items — those are entity changes, not block state changes.

Observer clocks

Two observers facing each other create a self-sustaining clock:

[←OBS] [OBS→]

Each observer detects the other's output piston/block change and re-triggers. The cycle time is 4 game ticks (2 ticks per observer reaction). In 1.21.4, this is approximately 200ms per full cycle.

The clock produces a continuous alternating signal. Attach it to a piston for a piston clock, or to a redstone wire for a power source.

Stopping an observer clock: you cannot simply cut the redstone — you need to interrupt the update chain. The standard method is a sticky piston that pulls one observer out of detection range, powered by a separate switch.

Observer-based tree farms

The cleanest use case: an observer watches the space where a sapling grows. When the sapling becomes a log (block state change: sapling → oak_log), the observer fires, triggering a piston array or TNT duper to harvest the tree.

Design considerations for 1.21.4:

  • The observer must face the block that changes, not a block adjacent to it
  • Bonemeal-based growth triggers the observer on the first sapling-to-log transition
  • For large trees (dark oak, jungle), you may need multiple observers watching different trunk positions

Flying machines

Flying machines are the intersection of observers, pistons, and slime/honey mechanics. They are the most complex vanilla redstone structure, and they work because of a specific property: slime blocks push attached blocks when a piston moves them.

A minimal flying machine (two-piston, one direction):

[slime] [sticky piston →] [slime] [observer→] [piston→]

When the right piston fires, it pushes the slime block. The slime is attached to the observer. The observer moves, detects that its target block changed (because the block in front of it changed due to the move), and fires, triggering the left piston. The left piston pushes everything forward, the right piston re-triggers via QC or observer output.

The key rules for flying machines in 1.21.4:

  1. Slime blocks carry attached blocks when moved by a sticky piston. Blocks attached to slime (touching it) move with it, up to a maximum of 12 blocks per move.
  2. Honey blocks do not stick to slime blocks — you can create a break point in an attachment chain using a honey block between two slime segments.
  3. Observer facing direction is relative to the machine's direction — when the observer moves, it detects the block newly in front of it after the move, which may or may not be what you intended. Design the machine so the observer always "sees" something it should react to.
  4. The 12-block push limit is per-piston per-tick. If your flying machine tries to push more than 12 blocks, it jams and stops. This limits how many passengers you can attach.

Vertical vs horizontal

Horizontal flying machines are standard. Vertical flying machines (going up or down) work the same way but gravity affects dropped items — make sure any harvest system accounts for this.

In 1.21.4, the piston mechanics for flying machines are unchanged from 1.18 onward. Old designs still work. The main things to check when porting an older design:

  • Chunk loading — flying machines that cross chunk borders pause when they leave a loaded chunk. Either confine the machine path within forceloaded chunks, or accept that it will pause at chunk borders and use a retrigger mechanism.
  • Block entities — some block types added in 1.20–1.21 have block entity data that makes them unmoveable by pistons. Check the Minecraft Wiki moveable blocks list before attaching new blocks to a flying machine.

Putting it together — a tree chopper

A fully observer-driven tree chopper for 1.21.4:

  1. Observer 1 watches the sapling position. Fires when sapling grows to a log.
  2. Pulse circuit converts the 2-tick observer pulse into a clean signal long enough to trigger the next stage.
  3. Piston array breaks the trunk from bottom to top, or a TNT layer handles the full tree.
  4. Collection hoppers beneath the base collect drops.
  5. Replanting dispenser — a dispenser with sapling restocks the spot.

The sequence fires entirely on block state changes — no clock needed. The tree grows at natural rate, the observer detects it, the harvest runs, the sapling is replanted. The loop restarts when the sapling grows again.

This is the practical endpoint of understanding observers and BUDs: you design systems that react to the world rather than running on a clock that burns ticks whether or not anything happened.

Quick reference

Mechanism Detects Version sensitive? Bedrock?
Quasi-connectivity Block updates from QC position No (stable since 1.8) No
BUD switch Block updates near target Yes (update order varies) No
Observer Block state changes No (stable since 1.11) Yes (but timing differs)
Observer clock Self-sustaining, 4-tick cycle No Partially
Flying machine Motion via piston+slime push No Partially

Sources & further reading: