Minecraft Wiki:Issues/Piston Quasiconnectivity Bug

! Piston Quasiconnectivity Bug A piston can be powered by a block that is not directly adjacent to it, but diagonally above or 2 blocks above. However changes to these blocks will not propagate updates to the piston. However, 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.
 * 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:
 * This bug is simple to fix.
 * 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!
 * 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.
 * 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."
 * The 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): "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."
 * 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 will now 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

 * 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: hxxp://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]


 * 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 ispired 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. --Kimitsu 11:28, 16 November 2011 (UTC)