 |
VOOZH | about |
|
VOOZH | about |
Quasi-connectivity[1][2] is a property of dispensers, droppers, and pistons that allows them to be activated by anything that would activate the space above them, no matter what is actually in that space. While quasi-connectivity can be difficult to work around sometimes and might seem like a bug, it is officially recognized as a feature that "works as intended"[3] and does make some builds much easier (for example, piston walls). Despite a functional similarity to dispensers and droppers, crafters are not affected by quasi-connectivity.[4]
Quasi-connectivity is often abbreviated as QC. Other terms used for this property include "connectivity", "piston connectivity" (as new redstoners usually discover this property when playing around with pistons), "indirect power" (but that term is also sometimes used for activating mechanism components with an adjacent powered block), and "BUD-powered" (although quasi-connectivity and block update detectors are not synonymous).
Rather than repeating "dispensers, droppers, and pistons", this tutorial discusses only pistons, but everything discussed here applies to dispensers and droppers as well.
Before discussing activation by quasi-connectivity, let's review more general methods of activation.
Mechanism components can be activated, which causes the mechanism component to do something (push a block, open the door, turn on, etc.). Most Minecrafters would just say they are "powered", but it can be useful to distinguish powered and activated.
All mechanism components are activated by:
In addition to the normal methods of activation described in the previous section, pistons can also be activated if one of the normal methods would activate a mechanism component in the space above the piston, even if none are present, or even if the block above the piston is non-conductive (including air).
A common expedient used to better understand how QC works in practice is to imagine pistons as behaving like the bottom half of a door: anything that activates the top of a door also activates the bottom of the door, and anything that activates the space above a piston also activates the piston.
This type of activation is known as "quasi-connectivity" (QC) and is often summarized by saying that pistons can be powered by blocks diagonally above or two blocks above, however this simplified explanation does not describe how block updates can affect the piston's activation (see the section below).
A piston does not always realize it's receiving a redstone signal when being powered by quasi-connectivity. When redstone components change their state, they send block updates (specifically neighbor updates) to adjacent blocks so that they can update their state in response (for example, a redstone lamp turns on when a redstone block is placed next to it because the redstone block sends block updates to all of its direct neighbors, and when the lamp receives the update it will realize it's being powered). However, redstone components only update other blocks a maximum of two spaces away (by taxicab distance), but quasi-connectivity can create situations where a piston should be activated from a redstone component three spaces away. For example, a piston that has a conductive block two spaces above itself that is receiving a signal from a repeater does not extend immediately.
Because of this problem, some methods of activation by quasi-connectivity ("QC activation", for short) update the piston immediately ("immediate QC activation"), while others put the piston into a state where it should be activated but does not activate until an update is received ("update-based QC activation").
Immediate QC activation is the activation of a piston by quasi-connectivity that occurs immediately and doesn't require the piston to be separately updated. This only works with redstone components that can update other blocks two blocks away from them.
Other redstone components cannot update redstone components more than one block away so they cannot be used for immediate QC activation, only for update-based QC activation.
A piston that is currently receiving a redstone signal due to quasi-connectivity but was not sent any block update does not activate until it finally receives an update. This method of activation is known as update-based QC activation.
Pistons can be updated in multiple ways:
*
|
*
|
*
|
*
|
*
|
*
|
*
|
*
|
*
|
The redstone components that cannot be used to put a piston into a QC activation may still be useful for updating them. For example, a tripwire updates adjacent blocks when an entity moves into or out of its space, and activator rails and powered rails are useful in that they update adjacent blocks when activated or deactivated (thus updates can be controlled with redstone without directly powering neighbors).
Although somewhat difficult to understand, quasi-connectivity does offer many benefits.
Because a piston can be activated in its own space or the space above it, there are simply more options when figuring out how to activate it.
Because a piston can be activated by anything that would activate the space above it, pistons can be activated from two spaces away while most redstone components can only be activated from one space away.
Update-based QC activation can be used to create a block update detector: a redstone circuit that is triggered by a block update rather than a redstone power input.
A piston activated by quasi-connectivity is sometimes described as "BUD-powered". However, quasi-connectivity and block update detectors (BUDs) are neither synonymous nor even subsets of each other. There are methods of QC activation that do not produce block update detectors (for example, any immediate QC activation method) and there are block update detectors that do not depend on quasi-connectivity (for example, stuck-piston BUDs).
A torch key is a circuit that can react to the placement of a redstone torch in a particular location, even when the circuit is hidden beneath the ground. They are used to create a hidden method of activating another mechanism (for example, a piston door).
There are two primary methods of designing a torch key. The first is to place a block update detector under the ground so that the placement of a redstone torch updates the BUD. However, BUDs can also be updated remotely by other redstone components, increasing the chances of discovery. The second method is to use immediate QC activation by placing the torch so that it simply activates a piston by quasi-connectivity.
→
|
→
|
Similar to torch keys, but with a visible input, a floating button is a button that doesn't appear to be connected to anything but can still be used. The strategy is to put a button far enough away that it can activate a piston by update-based QC activation and then repeatedly update the piston (without activating it) so that it responds quickly to the button turning on and off.
For example, the schematic on the left shows one way to build a floating button. The clock circuit on the left repeatedly powers and unpowers the powered rail next to the piston. When the powered rail changes state it updates the piston without activating it. If the piston is updated while the button has been pushed, it extends because the button would activate a mechanism in the space above the piston. Similarly, if the piston is updated after the button pops back out, the piston retracts again.
A quieter floating button (right schematic) can be created by using a dropper instead of a piston and using it to push an item into a hopper, which pushes it right back (unlike the dropper, the hopper isn't affected by redstone components two blocks above it), but briefly activates a comparator output. This version updates the dropper with a hopper clock, which is a little slower and thus slightly less responsive, but smaller than a torch-repeater clock.
Quasi-connectivity can make it difficult to implement wiring above pistons compactly without also activating them. For example, the player can't run redstone dust over a block on a piston because the dust affects the piston even if the block is a top slab.
There are a number of strategies for getting a signal over a piston without affecting the piston:
→
|
→
|
→
|
→
|
→
|
→
|
Adds a 4 game tick delay to the signal's rising edge (2 ticks for the piston's extension + 2 ticks for the activation of the comparator) and a 2 game tick delay to the signal's falling edge, takes up only one space above piston. The difference in rising and falling edge delay shortens pulses by 2 ticks. If the piston moving the cauldron gets a pulse shorter than 3 game ticks, it drops the cauldron in the extended position, making the output stay on until the next time the input turns on and off again. A composter can be used for the same purpose.
| Java Edition Beta | |||||||
|---|---|---|---|---|---|---|---|
| 1.2 | Added dispensers to the game, which are affected by quasi-connectivity. | ||||||
| 1.5 | Added powered rails. Originally they were affected by quasi-connectivity. | ||||||
| 1.7 | Added pistons and sticky pistons, which are affected by quasi-connectivity. | ||||||
| Java Edition | |||||||
| 1.2.1 | 1.2 | Powered rails aren't affected by quasi-connectivity anymore. | |||||
| 1.5 | 13w03a | Added droppers. Droppers are affected by quasi-connectivity, just like dispensers. | |||||
| 23w13a_or_b | Added the fix_qc vote rule as part of the 2023 April Fools update. When this rule is approved, quasi-connectivity is disabled. | ||||||
| Tutorials | |||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||
| |||||||||||||||||||
| |||||||||||||||||||
| |||||||||||||||||||
| |||||||||||||||||||
| |||||||||||||||||||
| |||||||||||||||||||
| |||||||||||||||||||
| |||||||||||||||||||
