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.
 * Please do not delete this bug or this comment. It's fine if you disagree, but deleting is immature and petty.  Jeb marked this bug as skipped a while back, but since time has passed and new evidence has come up, I would like to 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) 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. IRL, I tinker with compilers and programming language design, which is why I have such strong opinions about keeping systems simple, minimal, and orthogonal.  This bug drives me 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]