Minecraft Wiki:Issues/Piston Quasiconnectivity Bug

Description: A piston can be powered by a block that is not directly adjacent to it, but diagonally above or 2 blocks above, but changes to these blocks will not propagate updates to the piston. Nevertheless, when the piston is caused to update by other means, it will take into account the state of these nonadjacent blocks. See this image for a better description along with a visual explanation.

Argument for Removal


Jeb marked this bug as skipped a while back, but since time has passed and new evidence has come up, I would like to respectfully ask him to reconsider. Here's why:
 * 1) This bug is simple to fix.
 * 2) The "designs" people use this bug in (BUD switches) can easily be made without this bug.  Yes, I repeat, piston BUD switches can be made without using this bug.  Tell all of your friends!
 * 3) Jeb was concerned about breaking existing creations.  However, his fix for the Wire-after-Repeater Connectivity Bug #1 (AKA the Repeater-Wire-Block Bug) has broken far more circuits (at least an order of magnitude more) than a fix to the piston bug would, and the affected circuits are far simpler.  (The old 4-way connectivity of a wire after a repeater has been heavily used; see the images to the right for an example.)  I filed this breakage as the Wire-after-Repeater Connectivity Bug #2, and Jeb's response to it was to change the way that redstone wire is displayed.  I find this new display to be a fantastic improvement (thank you Jeb!) and think it will make learning redstone much easier.  Nevertheless, the fact remains that other recent fixes have had a much greater breakage impact than a fix for this bug would.
 * 4) Continuing with what I said in (3):  In the past, Mojang has broken an insane amount of designs "for the good of the game."  The booster glitch fix ruined much more stuff (at least an order of magnitude more) than a fix to this bug would ruin.  And fixing this bug will actually open up new possibilities for circuits, while the booster glitch fix enabled very few to none.  (It did improve balance, however.)  Here, I think it is abundantly clear that fixing the Piston Quasiconnectivity Bug is worth it "for the good of the game."
 * 5) Pistons' quasiconnectivity behavior is baffling and hard to reason about.  Design for simplicity and orthogonality, not hacks and crazy special cases.  To quote a comment someone else made about this bug (comment not signed)(signing it now, that comment was mine TheMvanH): "This bug has plagued everyone who ever tried to make a construction with two layers of pistons above each other, since they cannot be controlled separately and behave really strange. It is also very counter intuitive to new users, and it makes absolutely no sense at all."
 * 6) I will concede that there is one very particular thing (and only one) that can be done easily only with this bug: powering a wall of pistons.  Quasiconnectivity behavior, without a doubt, is a terrible way to solve this problem.  A far better, far simpler, far easier to understand solution is to make pistons have the connectivity of repeaters (a wire "running past" a piston would provide power to that piston, under the proposed solution).  It takes minutes to implement, and is an improvement that will be felt in many other places as well.  There is no good reason that pistons should not have this connectivity.  (The things that have "block connectivity" (i.e., non-repeater connectivity) behave that way since it would be really annoying if, e.g., every block next to a wire became powered.  This is clearly not true of pistons.)  A simple problem like this demands a simple fix like the one I proposed, not a complex one that makes doing lots of other things impossible or very hard and which has made thousands of engineers pull their hair out.

So, there we have it. This bug drives me and many others crazy, and I respectfully argue that there is no justifiable reason to keep it in the game. Thank you for considering what I have to say. :) —Immute [talk]

Comments

 * This is a video of the bug Nohlium 05:34, 23 November 2011 (UTC)


 * I tested out the circuit logic in the array variation of the video you linked to. The BUD only works in roughly the same configuration, if any attempt is made to compact it using the same logic it gets stuck in place. Consequently, I'd consider that design to be a bug in and of itself. Lyinginbedmon 02:56 15 November 2011 (UTC)


 * I'm a big fan of the BUD and I've put a ton of work into some machines that will break if this bug is fixed. Nonetheless, it seems pretty straightforward to me that it should be fixed. Redstone is already beyond the grasp of most people and it doesn't help that there is a bug that you need to understand just to use pistons. The machines will get fixed, we're pretty clever. And if you want to throw us a bone, add a sensor block some time down the road. Last username 17:15, 14 November 2011 (UTC)
 * Nicely put, and I would definitely appreciate of a Detector block (sends a one-Restone-Tick pulse if a block update occurs and then goes "deaf" for another tick so it doesn't react to its own output) GALAKTOS 14:29, 15 November 2011 (UTC)


 * I'm against the fix. It is good for BUD switches, but it is also good for memory cells. Look at redstonewarrior's video So much on YouTube to see, how this works: http://www.youtube.com/watch?v=FKCGqXGgToI#t=87s (sorry, I was unable to provide real link) → Zarevak 21:39, 14 November 2011 (UTC)
 * Yes, that's a common D flip-flop design. If we didn't have this bug, we'd be able to make even more compact DFFs, though. —Immute [talk]
 * Fixed the link for you. --- User42 (talk) 18:52, 24 November 2011 (UTC)


 * I am wondering how you would propose making a compact BUD piston toggle without the quasiconnectivity bug?--Incanus uk 11:10, 15 November 2011 (UTC)


 * Bugs should be fixed, that's the common sense. If some bug inspired a good functionality that people liked and started to use a lot, the proper way is not to skip the bug, but to fix it, and implement that functionality legitimately. Also, I like the idea that pistons should attract redstone wires like repeaters. Users are often forced to place rows of useless repeaters along lines of pistons, which adds up overall strain due to repeaters' lighting effects --Kimitsu 11:28, 16 November 2011 (UTC)


 * I just spent four hours manually re-creating a large machine before discovering this wonderful glitch. They should add legitimate functionality for BUDs and fix this obscene bug. -H


 * It's pretty clear to me that this should be fixed. Having special-case exception behavior begets frustration while learning to use redstone, which is complicated and bulky enough as-is. The functionality provided by the BUD should be incorporated into a new block, allowing the bug to be fixed while satisfying people who rely on the bug. Undocumented and poorly-implemented behavior should never be left in just because people rely on it. --Chromium 18:19, 26 February 2012 (UTC)


 * I think this should be fixed and a dedicated block added to the game that you could craft and which would serve the purpose of current BUDS. 90.210.171.134 16:28, 5 March 2012 (UTC)


 * If I am correct, the intended behavior was to extend pistons if a repeater on a block next to and facing the piston, enabling piston walls to be constructed. The game just checks the power state of a block that would be above the piston instead of looking at individual repeaters. --- User42 (talk) 01:15, 18 March 2012 (UTC)
 * Update: The piston's "are you powered" method checks for blocks nearby that are powering in it's direction. Currently there are checks for each block adjacent to the piston and each block adjacent to the space above the piston. If it checks for repeaters in the spaces adjacent to the block above it before checking their powering status it will still retain the intended behavior without the side effects. The check specifically for the block two blocks above that should be removed. --- User42 (talk) 14:35, 14 April 2012 (UTC)


 * I think I found a way to BUD without this bug using the slabs' property of letting a redstone current pass through them as if they were air until another slab is placed on top. Here is an example using screenshots NetherrackCreeper 08:00, 1 April 2012 (UTC)
 * A bud is supposed to detect any block update, not just slab placement. That design could be useful for other things, though. --- User42 (talk) 16:47, 14 April 2012 (UTC)