Droppers, Dispensers and Pistons activate when blocks are providing power diagonally or two blocks above

Due to the piston head being a separate block from the piston, it is counted as such.

And as another bug report stated, "Powering the block on top of a piston extends the piston", the same concept applies here.

The Redstone block is powering the piston head, which is a separate block and it is on top of the piston.

And by the way, Better Than Wolves had a BUD block. It shouldn't be that hard to make it. (I'm referring to the "Buddy Block".)

See the screenshot I just posted.

Piston will extend if there is a power block 2 meters above it.
Piston will not extend if there is a block between it and the power.
Piston will not extend if the power block is similarly below it or on any side.
If you were to break that wood block on the left, and replace it, the piston would stay extended.

Some demonstrations similar bugs:
http://www.youtube.com/watch?v=g5hZtUlrlmo

Please fix this, it has made redstone contraptions and logic difficult.

This is really annoying. I tried to turn on redstone lights using a redstone block and sticky piston powered by detector rails, but it didn't retracted. Same bug.

Confirmed in 13w02b

Very annoying bug! PLEASE MOJANG FIX IT! IT WILL RUIN MY MAP!!! 😞

As of 13w02b, you can't force update on a piston with a trapdoor or a redstone lamp, making this "feature" even less useful. Get us rid of it and give us a BUD!!!

This is intended.
If you saw a video made by SethBling, you will find out that pistons constantly check their state, but will only react to a powered block if they are more than one block away.

Could you perhaps provide a link to the specific video... Going to check if that is either made by dev or contains a dev stating that this is intended.

@Michael: Pistons do not constantly check their state, otherwise it would be impossible for them to be used as BUD switches. If you were referring to the videos of sethbling showing grum how redstone works, grum thought it was a bug and sethbling told him that Mojang wasn't going to fix it.

@Mojang: If you didn't intend this behavior and/or do intend to fix it, I suggest stating publicly as soon as possible that it WILL be fixed eventually and to take that into consideration when building new stuff. You may even want to provide a build that includes the fix so people can proactively test and fix their contraptions.

Side note: Piston powered redstone block walls aren't as fun as I thought they'd be. Pistons don't cause updates when they extend, and when they retract they apparently update before pulling the redstone block. I also got a nice mess when I depowered them that seems to be affected by the size of the redstone hashset.

Works as intended, the Redstone Block is powering the piston.

It isn't WAI. Because mojang said that they are gonna make the BUD switch. Redstone Block isn't one.

I highly doubt that pistons were initially intended to produce all of the behavior that they exhibit, specifically BUD behavior. I do not think the initial intention has changed, but that Mojang has been receiving pressure to not remove the behavior. The intention to not break stuff (and upset a bunch of people) has overridden the initial intention of pistons being pistons.

Tying a mechanic that is completely unrelated to (and occasionally contradicts) the expected behavior of something so closely to it's core function is unhelpful for everyone, especially for people who are new to redstone, but even experienced redstoners have to deal with the additional mental burden and space restrictions required to avoid the mechanic when they don't need it.

If you were replying to the side note in my previous comment which is only tangentially related to this bug:
(Spoiler courtesy of Pastebin.com)

The thing is that redstone signal travels two blocks down, and it was always that way.

Then explain in the image why the first piston is retracted and the second one is extended. If what you (Arthur Uzulin) say is true those should be reversed, no?

Also, if "redstone signal travels two blocks down" then explain why a redstone lamp placed in the same place does NOT light under ANY circumstances? Why are pistons special? Why did they intend that?

Also, you can cause different, conflicting behavior by breaking that block in the middle sometimes. You can actually get the piston to be extended or not depending on the ORDER you do things, which is a flat out bug no matter what they intended.

Using this bug, I was able to get a piston extended with NO blocks at all within 10 blocks of it. See the new screenshot. This ONLY works if you start by powering it from 2 blocks above and then remove the blocks around it in a certain order.

I make use of BUD switches using pistons in my builds, but even so I'd still like a BUD block as replacement for getting the piston bugs fixed because it'd make things easier, less messy, and give more possibilities.

I'm pretty sure this is implied, but the bug persists even if the piston is broken and replaced.

I had the same issue in my game. causing a lot of problems; please fix!

I have to say that this bug, even though it has become a "feature" in many persons eyes, ruins some of the consistency we want in minecraft. I support the idea of a block made to be a BUD! Mojang, fix this bug, and add something that can please those who are going to miss it!

There are TONS of problems caused by this bug and no real use for it besides detecting block updates. I know Mojang is currently planning to ignore the bug, but I would strongly recommend reconsidering.

And of course compatibility with previous circuits should not be a factor. Leaving the game broken forever to prevent a couple minor circuit changes is never a good idea, especially in the update that exists so that all broken circuits will happen in the same update.

The block is actually powered, and this is useful for a whole bunch of memory-latch designs.

Anon, please give examples of situations where this is a problem (= can't be avoided, need a big "stretch" to avoid it), i'm not sure there are more occasion where it's better to remove it than keeping it.

Removing BUDs is effectively destroying any possibility of doing compact redstone builds that uses pistons. In this case it's not used to detect block updates, it's to power a piston from further away. I know that systems breaking isn't a factor, but here it's the whole case of compact builds that is affected. See cubehamster videos if you want some example.

Also, to Birk Aigner and everyone else too, it actually is very consistent. Each time you power a piston diagonally or from two blocks above, you get a BUD. There no "sometimes" in here, never.

So now that consistency isn't a reason anymore, why would there be a need to remove BUDs ? It's a bug but a non problematic one as long as you know how glowstone / slabs work in redstone, and a very useful one.

And, a little bit off topic, to Jeb(or Dinnerbone, don't remember who did the change) if you ever see this : Why did you "fix" trapdoors, redstone lamp and such ? It wasn't a bug that they updated, but you removed it anyway. It looks like it was to prevent people from using BUDs and not to fix them. If you're going to fix BUDs fix the piston connectivity, not how other blocks function. You just removed the thing that allowed us to avoid / control BUDs without removing the bug itself which makes it super annoying as of now as there is almost nothing at all we can do anymore to them.

When it comes to powering with redstone, pistons are the inconsistent ones. Doors, redstone lamps, etc. do not get powered the same way. Pistons getting power diagonally and needing an update to extent/retract is an obvious bug.

HOWEVER, block update detection is very useful for a wide variety of situations.

http://www.youtube.com/watch?v=XTUr3akixVk

EDIT: Prepended the protocol on the link.

@SewdiO:

This is a problem whenever someone wants to use pistons for anything that does not involve block updates. Even if it is a relatively small problem, it takes time and mental effort to solve, and anyone who does not understand it will tend to develop superstitions and/or a fear of redstone. Compact builds that rely on special case behavior tend to break between updates, so using them is a risk in and of itself.

-

You don't want it removed because compactness isn't a problem, then proceed to protest it's removal because it would break compactness.

-

When the bug occurs, it may seem inconsistent, which can be just as bad as something that actually is inconsistent. However, this bug also introduces general inconsistencies with other blocks and devices in Minecraft.

There is also a distinction between temporal consistency and spatial consistency. Most redstone blocks are spatially consistent*: if the world around the block is in state "A" the block is in state "X", if the world is in a second stable state "B" the block is in state "Y", etc. Each block has exactly one state that can be derived from every world state, while each block state can correlate to more than one world state. Spatial consistency is much easier to understand than temporal consistency.

Most bugs are very self consistent, at least temporally. Debugging a consistent bug is much easier than debugging an inconsistent bug, but it doesn't make it less of a bug.

-

Knowing how glowstone and slabs work is irrelevant to this bug, which requires neither.

The minecart booster bug was very useful, too. It got replaced by a legitimate method of boosting minecarts. ;P

-

I do not think the trapdoor "fix" was intended to address this bug, but it wouldn't be a problem if this bug didn't exist in the first place.

• Assuming the state of the world is stable, e.g. all blocks have had a chance to finish processing all inputs they have received.

If anybody wants to stop the BUD behavior, Dinnerbone has added a small feature where if the Comparator is facing a piston for example, the piston would not behave as a BUD.

@Arthur Uzulin you mean MC-6077? It is actually a bug and might be fixed in near future.

Things caused by this bug in the latest snapshots : 13w05a and 13w05b

The pictures i have added are things caused by this bug to reproduce follow instructions that are here - https://mojang.atlassian.net/browse/MC-8924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

You can link to issues with "[[MC-8924]]" or "MC-8924" (without quotes). It's easier to read than a full URL, and is crossed out when the issue is resolved. Note that there is a dash between "MC" and "8924".

Redstone block provides power to extended piston head which provides power to main piston block causing it to loop on itself and keep extended. Maybe make Piston heads not hold a redstone signal? I don't know. 🙂

This is the BUD-Bug which is very useful in redstone contraption so far the minecraft devs have decided not to fix it for that reason.

This bug made some of my redstone structures not working. Please fix it in the 1.5 update!!!

Ronald, this doesn't just affect pistons facing up or towards the block (if diagonal). It also affects pistons facing away and down, where the arm/head doesn't make contact with the powered block.

@Yoerie Dinnerbone said they would add a block specifically to detect block updates if this got fixed. It would be much more compact than this and pistons would be easier to understand and use.

not sure if this is the same bug, don't want to make duplicate posts

@xfallxcuav, yeah it's the same. normally powered pistons cause update on diagonally powered ones and due to some underlying processing order it results in such pattern.

wow this means that i had 2 bugs at once in 13w05b for MC-8992 so i guess it wasnt 100% duplicated

If they add a bud block it would be impossible to do things like 1:1 pixel displays. It already is impossible because of the trapdoor change. There was a design, but now there isn't. The best solution is a bud piston that behaves as it is now (then there could also be a bud block, but it would not break anything). It also breaks 4by4 and larger piston doors.
I would say that it MAY be a bug that Redstone blocks power pistons diagonally, that can be changed without any impact, it is a limit, but the whole quasiconectivity is very important. It is a bug, but so are chunk errors and creepers*, but those are iconic to Minecraft.

I actually wrote a essay on this, so I guess I will put a link to it.
http://www.minecraftforum.net/topic/1694360-why-the-bud-should-stay-essay/

*The creeper was originally a modeling error by notch while he was trying to make pigs.

Here's an interesting 1:1 pixel display in the snapshot.
http://www.youtube.com/watch?v=9SG4SxUu0sU
As far as vertical pixel displays go, we'd need a way to feed toggleable power into a block that doesn't rely on a supporting block. This means no dust, repeaters, or comparators (since they need a supporting block, but we'd also need the power to only affect the block being touched (or proxy it with a solid block).

Creepers themselves aren't a bug. The change of the model from the pig was, but then he skinned it and gave it an AI (explosiveness, etc.) on purpose.

... That was a cool video, but it isn't survival-feasible (or even non-mcedit creative). So even though it is cool, it still leaves some emptiness. And yes, creepers aren't bugs, But they were bugs, and then made into a feature. See what I'm saying?

@William Pearson We see what you're saying. It's an invalid argument. You could post that exact same argument on every single bug on this site.

Bugs are bad. This bug is bad. In some rare cases a bug can give you an idea to make something good, but that bug should still be fixed, and the idea implemented as a feature.

We're not saying you shouldn't be able to detect block updates (that's a separate discussion that I'm sure would be quite heated) or that you shouldn't be able to power walls of pistons with (relative) ease. We're saying that the fact that power will travel through air in one direction and one direction only, and power one and only one device, is a bug that should be fixed.

Reading people claim that something or other can't be compact without the existing BUD bugs makes me wonder about the math on that one. There are around 20 useful distinct-function items/blocks for redstone contraptions. If all items could be placed anywhere then a 4x4x4 contraption would have 64 blocks.

The attachment blocks required for dust, torches, repeaters, etc would limit the freedom. I think it's reasonable to assume that around half the blocks in a contraption are prescribed to allow these attachments. That leaves 32 positions on average that are free to to be any of the useful blocks.

With 20 items/blocks to choose from and 32 positions, that's around 4.3x10^41 possible contraptions. It seems to me that with such a massive number of possibilities anyone who claims to know for certain what can and cannot be built is overconfident.

I went ahead and built a 1:1 pixel vertical display without quasiconnectivity. I'm attaching a zip containing the display and the mod (for 13w05b).

Edit: 13w05b, not 13w05a.

I don't want to make a duplicate. So can someone tell me if this: http://youtu.be/99qSwa0Hyn4 and MC-108 are related?

Not only related but same issue.

Thanks Tails 🙂

Hi,
I have the same problem (lever above a piston and wanted to not power it directly by the lever but by a complex redstone circuit), really annoying one for compact lever/piston/redstone system.

Regards

Didn't Jeb say this wouldn't be fixed, some time in 2011?

The BUD functionality is useful, so removing it entirely would break a lot of things.

It would be useful if reliable (ie possibility to put power on/off). Here the problem is that it isn't reliable (piston extended and remains until you create an update of it) above the fact that it is not linked to the "normal way" redstone power is provided.

This is not the only way to make a BUD with pistons, and dinnerbone did say they would implement a BUD block if they broke this. Try putting a block in front of a piston, obsidian in front of that block, powering the piston, and breaking the obsidian. 🙂

Even though I STRONGLY feel that quasiconectivity is useful, with Redstone blocks it brakes tons of things. That is a bug. BUT, I am not asking for general quasiconectivity to be removed.
Oh, and Tavis Hansen, your design, while clever, is not infinity expandable, which was what made the design I showed so amazing.
Patching quasiconectivity with Redstone blocks would only break devices in snapshots that use that, and I don't see how you could use that. It would also fix the pistons getting stuck upwards.

Here's an infinitely expandable version. (display_demo.zip)

My point is that I figured out how to do it without hitting my head on my desk. IMO that's a little more important than compactness, but I think this may be a bit more compact that DicotheRedstoner's display anyway. 🙂

Wasn't the whole point of doing a dedicated restone update to make the major changes to the way redstone works all at once? How can the 1.5 pre-release be due on thursday without a resolution to this? Is that the devs officially saying that we're stuck with broken pistons more or less forever?

William, quasi-connectivity being linked to pistons is a problem. It's limiting.

Pistons are useful, and if they worked the same no matter their orientation and took power CORRECTLY, they'd be even more useful.

BUD update behavior is useful, and if it could be used outside of a piston it'd be even more useful.

This is the trouble I'm getting...

Thanks to this bug pistons are severely messed up and building any larger piston mechanism becomes a guess-game and timing hell. I can't believe this bug still isn't fixed or at least scheduled for fixing.
It's also very odd that some people suggest to keep this bug in the game... it's a BUG that breaks countless legit builds. To keep it in just because exploiting it's side effects can be (ab)used sounds insane to me. If the unintentional functionality provided by the bug is so useful then it should be provided as a seperate item/feature!

EDIT:Comments removed as link to MC-11193

Still persistent in 13w10b, and I would like to see the bud functions from this bug made into a sperate feature/item as Tim H said

I've encountered this bug in a few ways, makes redstone contraptions operate in strange, non-intuitive ways. 2 specific, recent examples that have caused me issues:

1. A piston pushing a redstone block up can never be retracted without breaking the redstone block. This is massively non-intuitive, and dramatically reduces the utility of the redstone block/piston combination.

2. I had a pressure plate on the ground, and an upward-facing sticky piston buried under the adjacent block. Stepping on the pressure plate doesn't activate the piston (as it shouldn't), but if I activate the piston another way (a lever, for example), standing on the pressure plate prevents the piston from retracting, even if I turn off the lever. Again, this is massively non-intuitive, and breaks otherwise functional designs.

Please fix this before the redstone update!

Still in 13w10b ->can one Mojang DEV take care of this one ? or at least explain why my strange_behaviour.png is normal (though I doubt it)

A bud block can NOT replace the functionality of quasiconectivity, because it is used in other cases (EG piston doors). That's why it wont be fixed. Quasiconnectivity with Redstone blocks is annoying, and can be said a bug, because it breaks many logical things. Quasiconectivity with pressure plates... I need a picture, your design is non-intuitive (it sounds like you are trying to break the pressure plate). I wouldn't mind a bud piston, that might be a good compromise.

A bud piston would be good

Since 13w10b Dispensers and Droppers show the same behaviour as Pistons when powered diagonally or 2 blocks above.

perhaps give pistons, dispensers and droppers an option to toggle this bug, so it could be a feature. If that was possible everyone would be satisified I reckon

Dispensers did the same thing in 1.4.7, it was just less noticeable because they only responded to redstone-initiated block updates. Simple removal of an "or" statement would fix that one. They are opaque, so putting two on top of each other with a dispenser facing them would have the desired effect anyway.

@William Pearson: Keeping a bug in the game that destroys legit and logical mechanisms in order to allow other illogic mechanisms that exploit bugs and were never meant to be in the game in the first place, where's the logic in that? If certain things like some piston doors or 1x1 displays can only be achieved by exploiting bugs then it has to mean one of those two things:
1) They aren't meant to be possible in the game and shouldn't exist.
or 2) They should be possible in the game and thus shall be made possible by either adding new redstone devices or by changing current redstone devices to provide this functionality in a LOGIC and intuitive way.
The current behavior, however, is just plain BROKEN.

@William Pearson, redstone blocks will enable many of the things that otherwise wouldn't be possible without quasiconnectivity. Things may not be as compact, but why do they need to be? If you really want something, you can make space for it. As for the benefits of removing quasiconnectivity, we don't really know what will become possible because we haven't had a chance to use pistons that aren't affected. One thing that will definitely benefit is the ability of players who are inexperienced with redstone or the intricacies of block updates to design complex things.

@Tavis Hansen, I never said that Redstone blocks should be removed. Just that they don't power pistons like they do, fixing that problem. Also, the bud piston idea would probably be the best compromise, is there anything wrong with that?

1: It would still behave in a buggy manner
2: One more thing that needs to be maintained - If they change something fundamental about pistons they need to do it in two places
3: Player confusion as to why there are two types of pistons that look like they should do the same thing, using a different piston than the tutorial, etc.

I honestly think the redstone blocks should power the pistons like they do currently, because you can make really nice RS-nor latches, for displays.

This very odd piston behavior has been the bane of my existence. using pistons in a compact fashion when they pull power THROUGH the air makes me pull my hair out. It is a bug that needs fixed.

Seriously? 1.5, the update meant to make redstone and pistons more reliable, didn't fix this hair-puller of a bug?

Many of my contraptions are broken after updating to 1.5 from 1.4.7. I hope they change this soon. :C

This bug has existed for many, many versions, it's not new to 1.5.

If your redstone contraptions broke, it's most likely due to this change...
https://mojang.atlassian.net/browse/MC-846

Or this new bug...
https://mojang.atlassian.net/browse/MC-11189

Well, the problem I reported MC-11901 was said to be a duplicate of this problem. However, before updating I did not have the problem. I guess the bug I reported is not a duplicate then but it does seem very similar.

@George Gates, when referring to other issues, you do not have to use a complete link to the issue, you can just use something like MC-846 and MC-11189.

EDIT: Auto-parsing FTW, thanks.

The behavior with dispensers and droppers allows for dispensers buds. Or more like dispenser rs nor latches without a reset. So it is annoying. The piston behavior can always be escaped, usually with a slab where it would receive power. Hopefully this helps.

Looks like my recent report MC-12198 is also marked as a duplicate of this bug. As @Eddie commented earlier though I only experienced the problem myself once updating to 1.5. It looks like half of the bug has been resolved in 1.5, namely that pistons who are being powered by a block are now being updated by that block, even if the block is above and to the side. Whereas before pistons were being powered but not updated by such a block.

But I still have a problem with the other half of the bug - pistons diagonally adjacent to a powered block shouldn't be powered by it.

I cannot confirm that that block is updating the piston.

If you build the structure referenced in my report MC-12198, that is three pistons in a row, with three blocks on top of them, and power the middle block with a button, lever or pressure plate, then you will notice that under 1.4.7 only the middle piston appears to be powered (as it is the only one to extend). However if you leave the middle block powered and place a block next to either of the other pistons then they extend too.

Therefor, under 1.4.7, the middle block is powering all three pistons, but only updating the middle one.

If you then try it under 1.5, you will find that powering the middle block causes all three pistons to extend. Hence my observation that it appears that updates are being propagated now.

Ultimately though, my main problem is that I don't think the two pistons to the sides should be getting power from the middle block, let alone needing to be updated.

That is only because the extending piston is updating the other pistons, not the block being powered itself. (See MC-11220.)

Ok that makes more sense. To test it I removed the middle piston, and now the other two pistons only extend or retract after an adjacent block update. Regardless, something has changed between 1.4.7 and 1.5 with respect to these updates, such that now the middle piston is updating the two side pistons whereas before it did not. Maybe it's the new 2-ticks-to-extend piston timing.

I think I'll just add my vote to this issue and hope it gets corrected soon. 🙂

The droppers/dispensers being powered the same way is a different bug and should be marked as related instead of duplicate. Pistons are not and should not be powered the same way as most other blocks, and both being in the same report prevents one from being marked resolved while the other isn't fixed.

The piston bug with redstone block isn't a bug.
https://twitter.com/Dinnerbone/status/313237462757543937

@ Dominik Banaszak It seems to still be annoying, can you give me a practical use of the part with redstone blocks? It latches the piston permanency. <rant>General quasiconectivity is nice, but these specific cases, the ones that Mojang wants to keep, seem very useless and inhibiting.

</rant>

Oh my god so many dups!

Why is this not fixed yet? It's been around for SOOO LOOONG!

As described in the so-called “dublicate” this happens under other conditions, too: https://mojang.atlassian.net/browse/MC-12639

it seems that when a sticky piston (and I imagine normal pistons to) push a redstone block in any direction, they can the retract when no more power is being sent to them. with the exception of when the piston is pushing a redstone block up. when pushing a redstone block up the piston will remain extend even when power is no longer hitting the piston.
I have tried hitting the sticky piston with power and turning off the power again, but nothing other than breaking the redstone block seems to work.

also, when sticky pistons are placed side by side faceing up, and a redstone block is placed ontop 2 or more pistons beside each other, the first of the 2 pistons to have a redstone block placed on top will extend and then stays powerd by the second redston block on the piston beside it, it will refuse to go down even when the redstone block ontop of it is broken.

it would seem that when the second redstone block is placed beside the first, the power of the second redstone block travels through the first redstone block and then down to the piston below it, and once that piston extends it would seem that second redstone block then continues powering that piston through the extended part. but that's just my theory.

but also, with 2 upward faceing pistons are side by side with a redstone block placed atop 1 piston, and redston power is sent through a repeater into the redstone block, both pistons extend. but I have only seen this happn in my world once and have not been able to re-create this last glitch.

now I imagine some of what I said has been stated already, and I have read some of the comments. but either I did not understand it in the same way that I have just written it, which would then make this explination of it plenty helpful to some people may have also not totally been able to understand other explinations of it in the way that they may with this one, or I'm try to adress a differen part of it.
I don't know anything about BUDs or any of those fancy names. I'm sure I've probably used tons of these different circuts in my redstone stuffs, but if you looked at one of my redstone doohickys and said something like "oh so you used a nor and an and gate before a bud to...." I'd look at you like you were from the moon.

I have also noticed that pistons seem to be erroneously powered when the piston arm is extended into a space that would be powered.

For example, place a piston 1 below and 1 below a block such that the extended arm will be directly below said block. Then place a redstone torch on the back of the block to power the piston. Now place a button on the block and press it. The only time the piston retracts is for the brief moment when the button power has ended and the torch has yet to update. In other words, the extended piston SEEMS to be powered both by the torch AND by the button if it is extended.

Removing the torch and pressing the button does not power the piston which indicates it is not getting power diagonally from the button but is instead being powered through the piston arm.

Whether this is a long-standing issue or not it is still irrational if not inconsistent behavior that does hinder the process of making some rational designs compact, even if it can be used in irrational ways to make other designs compact.

Yes, the whole Redstone mechanics are a long-term issue of inconsistent and unpredictable behavior.

Not only affects droppers, dispensers and pistons but all contraptions. They mostly work because of all that weird Redstone quirks starting with “directional” problems like the north-west-problems or the weird diagonal powering behavior and not ending here (top-down powers, but sideways not?).

I’m pretty sure this will not be fixed until Minecraft 2.0, because it needs major Redstone mechanics changes to make it completely consistent and predictable. (And IF Redstone will ever be fixed it likely breaks ALL Redstone stuff people built so far.)

CJ: That is intentional "Pistons do(and always did) get powered from 2 blocks above" - Quote courtesy of Dinnerbone.

"Worlds do (and always have) an invisible wall around them." - Anyone before InfDev.

"Redstone torches do (and always have) fired one tick sooner if you orient the stack in the north-south direction." - Anyone before 1.5

"Pistons do (and always have) been able to duplicate diamond blocks." - Anyone before that was fixed

Incorrect or illogical behavior doesn't suddenly become correct or logical just because it has always worked that way.

Travis Hansen: This is not my argument, the fact that I am trying to reinstate is Dinnerbone's confirmation of that side of this issue being intentional.

Jeb implemented pistons, but I don't think anyone at Mojang understands the issue fully. At most they're trying to not break stuff and avoid having to implement a BUD block.

140 plus people have reported duplicates of this bug. I would estimate that about 30 of those people reported the dispenser/dropper version, which leaves 110 who reported the piston version. I don't know of any other bug that is that well known but still that hard to search for.

Well, if this is supposed to be intended, then:
1) Why would we use Blocks of Redstone, if they are usually applied to builds with pistons, if we can't place them on a piston and still retain the normal operation of the piston?
2) This makes no sense, there's nothing connecting the power source to the piston!
3) If this is not a bug, then WHY isn't Redstone dust able to be
powered like this?
4) If Mojang wanted a BUD, then make one! Don't cause issues like this for such a trivial workaround!

The whole reason Redstone blocks were implemented were as a portable power source. Well, they aren't as portable as you would expect them to be, because you can't use them vertically (up).

This is a really, really, REALLY annoying issue.

This page should probably be divided into several reports: The behavior with droppers and dispensers, the behavior with Redstone blocks, and the behavior with pistons in general. The behavior that let dispensers fire multiple times (on rising and falling edges) was useful. Real-life circuitry is all about finding quirky behaviors and exploiting them. The transistor, a fundamental element of computing, essentially exploits a behavior that silicon exhibits. The effect of droppers and dispensers experiencing quasiconectivity is extremely annoying BECAUSE it is unavoidable. The same thing can be said for piston quasiconectivity with Redstone blocks. But with pistons in general, it is always avoidable using slabs, except in cases where the piston would still be powered if the behavior was removed.
For example, one can avoid powering a piston quasiconectivly by doing this (assume ██ is a full block, it was the best possible):
Before:
____________________
████████████████▒┫
________
██████▒┫
The upper line powers both pistons (or can hold the lower one on)

After:
____________________
██████▀▀████████▒┫
________
██████▒┫
The slab prevents the quasiconectivity. (I hope the full block characters show up right)

The point is: If it happens, then it should be consistent! But this only happens on a certain side of a piston, so my question is "Why?"

The behavior with redstone blocks is identical to the behavior of blocks powered by repeaters or levers. The only difference is that redstone blocks can't be turned off. Therefore it is the same bug.

I agree with separating the dispenser bug.

FireHunterX: The strong power can travel two blocks downward becoming weak power, that is one of the functions of redstone, redstone dust can only pick up strong power while devices like pistons catch the weak power.

If you are correct redstone lamps would exhibit the same behavior. They don't.

In this diagram the redstone is strongly powering the block which is weakly powering the spaces next to the block which do not transmit any power. The piston is below one of those spaces, therefore it should not receive power. If you replaced the piston with a redstone lamp, which can be weakly powered, it would not light up.

_
█
 ▒┫

There are two distinct definitions of the term "weak" power. One of them refers to a block being able to activate redstone devices next to it by "weakly" powering them, and another refers to any power provided by redstone dust, which redstone dust will happily ignore if it isn't connected to the source of that power.
The second definition has nothing to do with how far the power can extend. You can test it by powering a line of redstone lamps. Both repeaters and wires will power the same distance (two blocks), yet wire will only accept power from the block powered by the repeater.

The reason for no bud block is that a bud block would be a pain, and it would probably need a tile entity if it were to be customizable. But if it had a tile entity, there would be no way to move it, so it would break bud trapdoors, and other things. Oh, and the explanation on why it works is great. Oh, and separating the redstone blocks and repeaters/levers may be good because it makes pistons jam and become unusable. For this, it could be that a redstone block doesn't power pistons facing upwards from 2 blocks above. (see image)
before:
██
¯¦̅
██
after
██
__
██
Man, we need a code to insert blocks.
Would this be a good compromise?

Better Than Wolves has had a functional non-tile-entity BUD block for a long time.

The pseudocode for your suggestionwould be

if (!(block at y + 2 == redstone))
    if (block at y + 2 is providing weak power downwards)
        return powered;

located in BlockPistonBase.java. If they ever added more pushable powered blocks they would need to do

if (!(block at y + 2 == redstone || block at y + 2 == pushablePower || block at y + 2 == anotherPushablePower ...))
    if (block at y + 2 is providing weak power downwards)
        return powered;

That only fixes one problem which only surfaced after this bug was initially reported.

IMO it'd be a good solution to redstone block problem when redstone devices that have a "face" (namely droppers, dispensers, pistons and future similar blocks) would be unable to receive power diagonally through their "faces" (similar to repeaters/comparators). This has only been implemented with pistons and for the directly opposite strongly powered blocks only, which results in such redstone block (mis)behaviour. Such partial implementation doesn't include other blocks in 3x3x2 space in front of a device, allowing for undue diagonal and - in the case of device facing upwards - vertical powering.

What I think is your point: "Don't let anything be powered by any blocks in front of it."

That would work for the case where redstone blocks make pistons get stuck, but it's still only fixing one symptom of the problem.

Repeaters and dispensers don't need that limitation to function correctly. Pistons have that limitation so they don't automatically break any redstone torches that happen to be placed in front of them.

@tavis
I hope you'll see that limitation should be extended when you reproduce this by simply putting a redstone onto a redstone block in front of a piston (direction doesn't matter).

What about a radical approach? Only directly powered (directly powered block touching the base, Redstone torch, powered Restone dust) pistons extend.

@dirk
It is much likely to be considered not intended by Mojang, if I understand Dinnerbone's tweet on this matter correctly.
I think they've added vertical connectivity (and quasiconnectivity) to compensate for being unable to place redstone and attachable devices onto a piston, which is a transparent block (like stairs, fences and glass) due to the limitations of current rendering engine. The engine is being rewritten as Dinnerbone states, so I believe we may expect that pistons would possibly become opaque and attachable, and this weird way of powering would thus become unneeded.

@kbk
As stated in the bug report, my opinion is that pistons should only accept power from the green blocks and strong power from the orange blocks directed toward the block above the piston in the following diagram:

In other words, I agree with you about pistons but I'd actually like them to be a little more limited than what you're thinking. 🙂

A few things I can think of that would break with this implementation: All devices relying on quasiconnectivity, piston walls powered by redstone torches, and pulse limiters using a repeater and a block attached to an upward-facing sticky piston. The other option I presented would likely result in the desired functionality being unimplemented in new repeater-like devices.

"Pistons do(and always did) get powered from 2 blocks above"

This fails to hold true for dispensers, but suddenly that's how it works now.

I already had to replace about 226 dispenser-utilizing devices (that's the number of individual devices, scattered throughout a 113-room dungeon) after the dispenser powering bug was fixed - now, I'll accept that, as the change made was a fix to a bug, making redstone more consistent. However, this change does not make any sense, and I'm afraid I have no trivial way to work around it until it is fixed - either it won't work now, or it won't work once this bug is fixed (if ever).

I'd personally rather that Mojang remove this nonsensical behavior altogether, and make pistons, droppers, and dispensers behave the same as any other redstone component would - with no spooky action from a distance. As far as BUDs, I'm sure most of the community will agree that an actual, bug-free BUD block is the best option, rather than keeping bugs like this in the game for backwards-compatibility and letting them grow even less stable.

Dispensers have always worked that way, but since they ejected items on every redstone update it wasn't nearly as noticeable. If you had something powering one and you powered it with something else it would still fire, now it won't. Fixing the original bug revealed a second bug that needs to be fixed just as badly.

There are some special cases that pistons need to take into consideration, but that doesn't require quasiconnectivity.

Oh my god why?

So like I already said, implement a BUD Block and keep the functionality of pistons.
A major function in the game should not be crippled by something that a few people want. Meet the middle! Satisfy both ends!

It's like saying the majority vote loses!

Oh, and what exactly did 1.5 do to Redstone? It's unbelievably unreliable now! Strong power, Weak power, same thing! It's power regardless! All mechanisms should accept POWER. Not WEAK POWER only or STRONG POWER only, just POWER.

If we all want a BUD block like they promised us someone(me) should make a petition: •insert ad here• http://www.change.org/petitions/mojang-ab-minecraft-developers-add-bud-block-to-minecraft

FireHunterX,

Oh, and what exactly did 1.5 do to Redstone? It's unbelievably unreliable now! Strong power, Weak power, same thing! It's power regardless! All mechanisms should accept POWER. Not WEAK POWER only or STRONG POWER only, just POWER.

Strong and weak power has been in the game ever since redstone was added - even since before the repeater was added. It's not an unreliable or inconsistent concept at all. Blocks can be strongly or weakly powered, and this is based solely on what is powering them. Redstone wire only weakly powers blocks, while redstone torches, repeaters, comparators, buttons, pressure plates, etc. strongly power them. The only difference between strong and weak power is that a weakly-powered block will not power redstone wire: it still powers all other redstone devices.

If the distinction between strong and weak power did not exist, then you could alternate blocks and wire indefinitely for a zero-delay wire which never loses power. You also would be unable to isolate wires in most situations. Consider the following design:

#_
_#

That's a cross-section of a simple setup to have two wires run in parallel in a 2x2 space. # represents blocks while _ represents redstone wire. Right now (and ever since redstone was first created), this works: the wires do not touch and do not interfere. Under your proposal, the wire on the top-right would power the blocks below it (as it does right now), and these blocks would propagate that power to the lower line of wire: the wires are not isolated.

I don't honestly see why you're complaining here. All mechanisms, with the exception of redstone wire, do accept both strong and weak power, and treat them in the exact same way. Redstone wire accepts only weak power, else countless issues would be caused (difficulty in isolating wires, crash-inducing zero-tick loops from self-sustaining wire, etc.). No device only accepts strong power and not weak power - literally the only difference between strong and weak is that strong can power wires in addition to everything weak can power. All redstone components capable of outputting power will output strong power, with the exception of redstone wire and blocks, which output weak power (note that this does not make wires/blocks weakly powered themselves, as they can both still power wires. The strong/weak rule only applies to blocks being powered). The rules are very consistent and exist for good reasons; remove the concept altogether and you'll break far more redstone than any Minecraft update ever has.

Fixed in 2.0! See Mojang.com 😛

The change log was erronous; try it yourself. This bug has not been fixed in Minecraft 2.0, red, blue, or purple flavors. In fact, it also fails to spawn redstone bugs, which is itself a bug.

@Gerrard:
My point was not that there should be no strong or weak power, my point is that you shouldn't need to purposely make your power weak or strong to allow machines to work. If there's power, regardless of weak or strong, the machine should activate.

Can you give an example where you have to purposely make your power weak or strong for a machine to activate? Redstone wire is not a machine, and it is the only thing that cares whether your power is weak or strong.

Can you come up with a solution that doesn't get rid of strong/weak power, but somehow still manages to make it so the player never has to worry about its existence?

Okay.

You have a line of Redstone wire, 20 blocks long. After 16 blocks, then the Redstone current needs to be refreshed with a repeater. But if we don't include a repeater, it cuts out at 16.

As long as I don't put a mechanism past 16 blocks, it should power, as there is still Redstone current in that part of the wire. So, even though the power cuts out after 16 blocks, it's still power.

And, if any mechanism accepted any level of power, then you would only need to remember to restrengthen it after 16 blocks.

Wait, have you been talking about the redstone's signal strength this whole time? Because strong/weak is something completely different, as opposed to the signal strength conveyed by the brigthness of a wire.

If you mean signal strength, that actually ranges from 0 to 15, not 0 to 16. Most mechanisms don't care what exact strength it's being powered with: 0 means not powered, anything else means powered. The only exception to this is the comparator, and special reactions to different signal strengths are kind of its entire purpose.

In your example, the power cuts out at the 16th block. If the 16th block is a repeater, it can take the (very weak) signal at the 15th block, and output a refreshed signal. If the 16th block is a mechanism, such as a door, dispenser, or piston, it will still be powered.

It already is basically how you suggested: you just have to remember to restrengthen your signal every 16 blocks. Hint: if the wire isn't producing particles, that means its signal strength is 0 - make sure your wires aren't longer than 15 without repeaters. If there are particles, it has at least 1, which is enough to power things.

Yeah, I've been talking about strength since the discussion started. I might have misunderstood, but I thought someone had commented that it should matter what signal strength a mechanism is powered by.

I was using a different definition of signal strength in which "strong" is coming from anything that isn't a block and "weak" is coming from opaque blocks powered by a strong signal. It's an implementation detail that only applies to a special case involving pistons, and the end result would actually be quite intuitive to players.

I as well am experiencing such problems with pistons although i am not sure weather or not to report it as a new bug.
(pistons powered with a redstone block forced into place above the now bugged piston, by a non effected stick piston are powering other pistons diagonally and will not retract after the power"redstone block" source is retracted "only will retract after redstone block and others nearby are destroyed" and so not helping my constant testing for a perfect fully automatic sugarcane farm)
If this is a new bug please contact me and i can provide more details and screen shots.

If you place an upward facing piston, then put a block of redstone on top of it, it does not extend. This is reasonable, but if you trigger the piston some other way, it will not retract. Further experimentation indicates that an upward-facing piston can be powered in general from the block above the extended shaft, but not from the block they would be pushing. However, horizontal pistons can nowise be powered from the block at their face, extended or retracted.

This seems peculiar, and I'm guessing it's connected to this.

ETA: Updates don't seem to help, as I tried placing and breaking blocks adjacent to piston, shaft, and BoR

Ok, here is why it should not power with Redstone blocks:
It powers when the redstone block is next to it but not above it. (See images)
Also, the dispensers and droppers were not annoying because they could fire twice, but that BEHAVIOUR was removed, making dispensers "latch" and be all useless.
Piston quasiconectivity can always be "escaped" with a slab, so that is good.

Just a note to people who still feel like defending this bug's existence because of their use in compact BUDs: There are several very compact piston BUD designs which don't even rely on this bug. I personally will be using these until an official BUD block is created (oh, and here's an idea: an official BUD block could be able to output 15 unique signals for different types of block updates, going with 1.5's theme of analogue output).

There's no excuse for leaving this bug in the game except "it will break pre-existing builds". That wasn't enough to keep Mojang from eventually fixing the dispenser powering bug, and I had to replace roughly 226 mechanisms relying on the bug in an adventure map. It shouldn't be a valid excuse here if it wasn't there. Fixing this bug won't make any Minecraftian problems impossible to solve - at most, it'll change your solution a bit here and there, and I'm sure we'll see revised compact piston door designs well within a week of the snapshot that fixes it.

A block being powered by a repeater where the redstone block is in this post has the same effect

In 13w19a

What was that with the new attachments of exe's? Were they viruses?

This is not a Bug/Glitch it is really really usefull for redstone meganics. If they fix this, the BUD gets removed again. Dont remove this awesome feature!!!

They've already removed several BUD features (e.g. fencegates, doors, cauldron contents, etc. no longer work with BUDs). They said if the BUD gets completely removed, they'll make a dedicated replacement - one that won't gradually decay into uselessness with every single bugfix. Would you honestly have the BUD in its current, stripped form, or would you rather have a BUD that Mojang openly calls a feature and doesn't break more and more of with every update?

And can you please tell me how it's even remotely useful to have this bug apply to dispensers and droppers? I've yet to see any compact BUDs or other practical things make use of that - it mostly just causes problems.

Also, there are plenty of BUD designs that don't rely on this bug, and they're very compact and significantly less bug-like in appearance as well.

As I have said before, the main cause of annoyance with this behavior is when you get it when you don't expect it. Specifically, Redstone blocks and dispensers.
And a bud block doesn't make sense.
BUDs are odd, and couldn't be called intended. The way it works, if a bud block is added, it would be a unnecessary and sloppy solution. Integrating additional behaviors in pistons works well. Minecraft is a complex cellular automata, and is about using the behaviors of various blocks. Some are obvious, like pistons pushing, and others less, like repeater locking.

A BUD would be a block that emits a redstone signal when a block next to it changes. The implementation could vary, but the basic idea makes sense.
You're arguing that they should intentionally leave an unintended function in the game because it doesn't make sense.
Locked repeaters have a visual indication that they are locked, require a very specific and obvious set of conditions, and the locking function is directly related to the core function of repeaters.

The video linked in Gerrard Lukacs' post shows a few very simple BUD design that do not involve quasi-connectivity. Is there a non-BUD argument for keeping this bug?

William Pearson, BUD does not necessarily need to be the name or even the functionality. A number of other concepts could explain a very similar set of behavior - for example, a Motion Sensitive block of some sorts. Such a block need not accommodate invisible block updates such as sapling maturity state, but could accommodate the majority of practical uses (block removal/placement/motion, door opening/closing, etc.). This would not be unnecessary, as it would implement a block with the feature of this sort of behavior, rather than relying on a number of implementation side-effects which keep changing (see MC-5898).

And even if integrating BUD behavior into pistons "worked well" and actually made sense, why leave this bug for Dispensers and Droppers? I've had to redesign countless circuits thanks to interference in signals because Dispensers and Droppers exhibit the same behavior.

I've been saying that it should be separated into several parts: Dropper/Dispenser quasiconectivity, General piston quasiconectivity, and redstone block quasiconectivity.
And for some reason, the idea of a BUD block makes me shudder (really), and I am not 100% sure why.

Well if a BUD block makes you shudder then stay away from Better Than Wolves, because it has one 😞

Better than wolves has a ton of things that don't "fit" minecraft.
Donuts, blood, poop, animal cruelty (slicing a wolf in half!?)...
So I think of it as a bad example.
--------------------------------------------------------------
I have decided that bud behavior is probably bad in dispensers and droppers, because very little can be done with it, and it ruins stuff.

Vanilla Minecraft has a ton of things that don't "fit" Minecraft. There is absolutely no precedent for most of the things they added in 1.5.
And forget about mods that have BUD blocks, vanilla has several. They just don't look like one so we can safely ignore them. Water, floating sand, pistons, and even repeaters can be used to detect block updates.

I don't see why this isn't fixed by now. If they consider quasiconnectivity a feature, then it is a useless and VERY annoying one. There are so many ways to make bud switches besides this bug; an example is sethblings video here: http://www.youtube.com/watch?v=Qp4_oQuReuE

Confirmed in 12w25b and c

Block update detectors are useful for people who want block update detectors.

Properly working pistons are useful for people who want properly working pistons.

If you have broken pistons that act as buds, then people who need proper pistons are out of luck and have no work-around.

If you need a bud, and pistons don't do buds, then you have options. Perhaps not compact.

If you need both compact buds, and proper pistons, then you have to break the broken pistons and add in a proper bud block.

… but as of now we have broken pistons and bug using as BUD mechanism.

I still think we should stop this.
1. You break many redstone mechanisms
2. It is actually a removed feature than, so this should never be accepted anyway by mojang.

sighs
remove this "bug" because that's what it is, a bug.
add a block update detector block, which I'm assuming this "bud block" people mention is.
everyone is happy.

those who use this bug, a single bluck for an update detector is far better than a strange pistons switch setup anyways. get rid of your piston and switchs and put in the detector block. big woop. "but my redston will break!" do as I just said and it will be fixed. to lazy to go and fix the redstone? then you didn't need it anyways.

basically all the people who have used this, don't want it to go cause they've used it.
those who haven't used it, don't want it because it's not helping them and is making it difficault or impossible to use redstone mechanisms they design as they should logically work but don't because of this bug.
makes more sence to get rid of it so redstone can work right than to keep it so a few guys and gals can be happy.

Like Dinnerbone said, pistons CAN be powered with 2 blocks away, and not only with redstone blocks. Try to create something like that:
.... -> Redstone wire
[[]] -> Any solid block
[]I -> Piston (any type)
i -> Any thing that can activate redstone (redstone torch here)

i ........
[[]][[]][[]]
         []I
(^ Those spaces are white-spaces, because you can't use more than one space at once in the comments.)

Try to build it in ANY versions after the version where the pistons are added (1.7 probably?)
It should retract the piston.
Mods, come on and mark this as Works as Intended. If the developer says that this is intended, this IS intended. Even if someone likes it or not.
For those saying that this is a bug - this is a feature of pistons in Minecraft.
THE END

The claim "it will break builds" is not acceptable. Piston timings changed, breaking systems. Redstone torch accuracy broke from 125 single player to 125 multiplayer and everything since, breaking systems and actually giving some timing loops zero chance of working properly. (Bug number ... 2523, https://mojang.atlassian.net/browse/MC-2523).

The point is this: We've (our server) had "buds" from what should have been simple piston builds that DID NOT WANT BUD BEHAVIOR!

• We don't want this oddball piston powering!

It has interfered with some relatively simple designs.

If there is a good reason for this – if there is something that you want to do with pistons that cannot be done without this – then please indicate what it is.

"Block Update Detector" is not a good reason. That should be a new block, perhaps using nether quartz.

easy to fix.
JUST USE A HALFSLAB!
Futher dont fudging fix this bug.

Please explain what you mean, "just use a half slab". I do not understand your comment.

Because you can place a normalblock and place redstone over it. U can use a upsidedown halfslab to fix this.
1. place a halfslab (upsidedown)
2. place redstonedust on it
3. try to power a block 2 blocks under it
4. You see that that shouldnt work. So than it is fixed.
im a redstoner. and if this bug gets fixed, many systems shouldnt work anymore

Remember 2 glitches that people wanted to keep :
->water glitch : making boat faster and some server had water highway using this : was fixed and no replacement
->minecart glitch : two minecarts near each other accelerate : was fixed and replaced with booster rail

Here we have 2 solutions :
->Mojang thinks this is bug (my point of view because messing up with contracted designed and hiding things (like in pure rock)) and they will fix it with a replacement or none
->Mojang thinks this is feature : they just have to put this one as "working as intended" and that's all (and people just have to know this when building with piston)

Arguing is pointless because there are always people who want "nothing changes" and other "everything changes". Only Mojang will do (or no)t things related to this.

We need to discuss whether the desired solution is the elimination of powering at a distance or the elimination of powering without an update. These are two distinctly different possible solutions if this is considered a bug.

There's a group of people arguing that this isn't a bug, but I wonder if they all agree that the blocks indicated in orange in the image should not provide an update and that they should power the piston. There's also a group of people arguing that this needs to be fixed, but should it be fixed by making pistons not take power from the orange blocks, or by making pistons receive an update from the orange blocks?

Currently we are divided into 2 groups, "fix it" and "do nothing"
We should be talking about "no power and no update" vs "power and an update" vs the current "power and no update"

To those arguing that power and no update is the best option, we've seen that BUDs can be built without quasi-connectivity, do you have another reason?
Personally, I would like to see power and an update. It would be hard to wire an entire wall of pistons to move or to get power to some carefully hidden pistons if they only responded to direct power, but I can't stand having pistons whose behaviour depends on block updates when that's not what I'm trying to build.

I supported power and no update, but power and an update works now since nothing gives updates anymore. You used to be able to do
[-█ ██▯
[█ [][]
To make both pistons extend ([]-[] is a fence gate and ▯ is a button).
Now, you can't.
I guess I support this, although it does break some things, they were already broken in 1.5.
And also, there are 3 other subsets: piston quasiconnectivity (Piston diagonal powering), droper/dispencer quasiconnectivity, which is droppers diagonal powering and latching, and piston quasiconnectivity with redstone blocks, which I sepperate because you can't turn off redstone blocks, so it basically freezes the piston.
Only regular piston quasiconnectivity can be argued for, since there are several workarounds for it. The others cause trouble.

The quasiconnectivity feature may be tricky to use, but it makes pistons far more versatile and useful. Besides the BUD thing, others have mentioned piston walls, and I've also seen it used for other circuits.

Yeah, I wish there were a happy middle. If only we could have 2 types of pistons, one that had it and one that didn't. But, as a mod said, that would be confusing.

Although Dinnerbone's tweet specifies that Pistons can be powered from two blocks above them, neither he, nor any other official source, has ever indicated that that the BUD behavior (pistons not extending/retracting without a separate block update even though they're powered/unpowered) is intended.

As @unknown has said, there are three possible directions to go with this:
current behavior: powers from two blocks, but piston does not change state without a separate block update. This is useful, but counterintuitive, and endlessly confusing and frustrating. It makes redstone hard to understand, because it contradicts the normal rules.
Power from only one block: This would make it consistent with other redstone behavior, and resolves the block update issue, because changing the powered state of the redstone should always provide the necessary block update for the piston to update. However, since Dinnerbone has implied that powering from two blocks away is intended, they are unlikely to implement this solution. It would make various piston contraptions harder or impossible to create.
Power and update: This would make the behavior much easier to understand, because pistons would consistently change state based on power. They can be isolated with halfslabs, giving the builder control over whether they respond to signals from two blocks away or not. The only thing lost is BUD functionality, and that's available through alternative designs.

I think the last option is clearly the best, though there are of course going to be people who are comfortable with the current behavior, and don't want to have to change. I just think it's better to do the the that makes the most sense, rather than being held hostage by the past.

How does quasiconnectivity help with piston walls as @unknown says above? Wouldn't you want all your pistons to update when powered for a piston wall? It seems to me that the current power but don't update approach has the potential to leave some pistons retracted. I keep reading that this bug is useful but I have yet to see a good explanation why.

The power but don't update approach worked well until you stopped being able to use fence gates to update pistons.
Now, I'm not sure.
The point this annoys people at the most is using redstone blocks, and the pistons "jamming".

I don't think anyone cares too much about redstone blocks. The uselessness of sticking a redstone block on top of a piston is immediate obvious so people don't do it. A more annoying point is that mechanisms can interact with no immediately obvious symptoms of that interaction.
As for piston walls, I think he may be talking about repeaters and torches powering pistons below and in front of them. That's what the orange blocks are for.

Tavis has got it – the problem is getting power to pistons on several adjacent levels, which is awkward without quasiconnectivity, even with the expensive "orange blocks".

And yeah, not being able to retract a BRS vertically is slightly annoying, but on consideration I can live with it.

That does not rely on quasiconnectivity. The point of the term quasiconnectivity is that you are taking power from somewhere that doesn't update. Getting a proper update from the 2 blocks away power source would not affect your ability to power a piston wall.

The orange blocks are just placeholders for repeaters or similar blocks.

this really should be fixed, using the BUD designs that don't rely on quasi are better any way, and this prevents a lot of cool things with redstone blocks from being done like:

piston
redstone block

piston

because the redstone block powers the lower piston even though they aren't touching. Please remove this mojang!

this really should be fixed, using the BUD designs that don't rely on quasi are better any way, and this prevents a lot of cool things with redstone blocks from being done like:

piston
redstone block

piston

because the redstone block powers the lower piston even though they aren't touching. Please remove this mojang!

GAH.

The annoying part of this is how it works in some cases. You didn't read the potential uses.
I'm annoyed with redstone blocks too, but the other uses are worth keeping.

And also, it is realy only a problem when the top piston "jams", there are other uses. And you can avoid it any way.
And how would you use that?
The only thing that could do is make a more expensive, slower variety to the redstone torch tower, that resets instantly and messes up pulses.

I know people are saying that you can use halfslabs or stairs to isolate pistons to get the "proper" behavior.

I'd like to actually SEE a working system, with 4 pistons in a 2x2 vertical grid, each one activateable independently from the others.

And, as I say that, I realize that a trivial solution is to power the bottom two "normally", and the top two from "above". So make that a 2 wide x3 tall grid – how do you get the middle ones to work without issues?

I'd like to thank Mojang for officially confirming that this is intended and will not be changed.

Meanwhile: Anyone got a good way to make a tall, two-wide set of pistons work without this? We've run into this issue on other builds by accident, and while small builds can be adjusted, I don't see how to do it on bigger stuff.

Thank you grum for intendifiying it.
@ Keybounce not quite sure what you mean.
But you probably can do this:
[-[]▁▁▁
[-[]██:◀
[-[]▁▁▁██
[-[]██:◀
[-[]▁▁▁██
[-[]██:◀
All you do is power the back repeaters.

-------_________________---------
CONFIRMED TO BE INTENDED? WAT DA FAK?

?

?!
I freakin HATE this thing! it causes me so meny problems that I cannot figure out how to get around! and I've tried the halfslab thing and it does not do crap for me. how are pistons not working properly when they logically should intended?

? me not happy. I mean this whole argument was basically 1 side is happy with it this way and the other isn't, so both sides fighting for what will make them happy. but really, an up facing piston remaining down when a redstone block is place on top of it, the extended when powerd from something else, but not retracting when that smething else is turned off, because the redstone bloack is now powering it makes absolutely NO sence at all!

and you guys say these problems can be worked around? show me how! cause I have nor freak clue how to make stuff that should logically work, do so when because of this weird happening, don't. (again, tried halfslab, did freakin nothing)

Show what you are trying to do, and I will show you how to do it.
Stop screaming.
Its just a set of numbers being changed.

I'm presuming that the BUD behavior is being marked WAI, but I'm curious if redstone blocks on top of a stuck-extended piston are WAI, because no amount of block-updating can make that thing retract.

@Keybounce

Your problem isn't dependant on BUD. You can't power each piston individually in any way, that's not possible (if you have a grid of at least 4x4), even without quasiconnectivity. This is because a repeater directed to a piston with another one below it will power both. So with or without BUDs, you can't do that.

To power a wall of pistons, you have to alternate between powering a line directly with a repeater (powering two lines at the same time), and through a repeater (BUDing the line below). While tricky, you can get around your problem by sending one tick pulses to the pistons. If you send it to a piston powered directly by repeater, you have to send another pulse to the piston below, which will retract the previously pushed block. To power the "through a block" pistons, you just have to make sure that you don't send the one tick pulse corresponding to the retraction at the same time as you send a pulse to the pistons above.

Let's say that even rows are powered through a block, and odd rows are powered directly. If you want to load an image stored in some memory to the screen, the powering order goes like that :
1. one tick pulse to the even pixels you want to activate, pushing them and the ones below
2. (one tick later) one tick pulse to the pixels below, retracting the odd blocks pushed (don't power all the odd line, only the pistons below the previously powered)
3. (two ticks later, so the blocks are pushed and don't stick) one tick pulse to the odd pixels you want to activate
4. restart the following tick, if you were to do 3. and 1. at the same time BUDs problems would occur

To clear it you send a pulse of at least two ticks to recover the blocks.

If you want to power pistons with levers (lever up : pixel on, lever down, pixel down, or the other way around) you do the same thing for the powering order. You have to hook to each lever a dual edge one tick monostable circuit, to send a pulse when flicking the lever in both directions.

If you want to do it with buttons, you just need a one tick monostable circuit for each button.

And really, all of these complications aren't because of quasiconnectivity. The only improvement possible would be to speed (point 4.), but that's a very poor improvement comparing to all what is possible with quasiconnectivity (if trapdoor, fence gates or redstone lamps still updated as it was before ; this was the most stupid "fix" to quasiconnectivity there has been as it only prevent from using it but still leave it there).

I hope that helps ! 😃

The 2 by X wall would be possible without quasiconnectivity by alternating powering the sides and backs of the pistons or blocks behind the pistons, e.g. power the back of the bottom ones, sides of the second ones, back of the third ones, etc.
Alternatively you could use chains of RS block pushing pistons.

I can see why this behavior might be marked as intended for pistons, but can we please have any explanation for why it exists on droppers and dispensers as well? Does Mojang intend to migrate this behavior to other blocks, such as command blocks, hoppers, and TNT as well?

@Tim Gunderson
Yes, the piston being powered from two blocks above has been confirmed as intended by Mojang.

@Gerrard Lukacs: because users love bugs ... and they want us to keep them. So we'll just do so.

@Grum In that case wouldn't a more appropriate resolution be "Won't Fix?"

Both of those imply some state; Won't fix implies that it is a bug, while works as intended implies it was intended in the first place. Thus, we need something like "Won't remove".

His comment implies that it is a bug that they won't fix "because users love bugs."

Tee hee. Yes, "Won't Remove", or "Promoted to official feature", sound like better resolutions than "Works as intended".

Either way, it won't change.

@Grum: What about pistons being powered/unpowered, but not updating their state until they receive a separate block update? Is that WAI, or should it be filed as a separate bug?

Is there any chance an option in the form of a GameRule could be added that would allow servers to toggle whether pistons work with current behavior or with the behavior asked for by this bug report?

I wrote a mod that removes this behavior: http://www.minecraftforum.net/topic/1874049-sspsmp-pistondispenser-quasiconnectivity-fix/

Works as intended? ARE YOU FREAKING SERIOUS? I'll go demand my money back and then I'm gone for good. Bye.

"What? There is a feature that I consider a bug and I want my money back" Calm the heck down.

So, someone doesn't make a change to a behavior that was in the game for 2 years, and you get extremely mad?
Just work around it.
Or use his mod.

Yup, I'm quite frustrated at this "resolution" as well.

SethBling used this once and now we're going to keep it forever because he told Grum that Buds were useful (he trained him in redstone).

Community proven solution (to make most everyone happy) is a bud block and killing quasi connectivity, but that won't happen because of the Jeb door which is extremely ancient, but hey, it's Jens most proud creation apparently. Ooh, and lets not forget we can't release something that will break even 1 RS build.

RS community has been dying and now I see exactly why... sad thing was that after 3 years it was only RS that kept me playing. I do not mod my game, the devs have been given the code for the solution to this bug but they choose to live in denial and warmly welcome most all undocumented features.

I'm done. Enjoy a broken and illogical game everyone.

Actually it is working as intended because it is a bug turned feature by demand of the community. Would you rather have is break all existing maps and make certain constructs impossible?

Try making a 10x10 wall of pistons that all move together without this quasiconnectivity (use that mod above).

If you can make alternatives for all the existing structures we might consider it.

Yes for predictability’s and consistency’s sake! Please “break” some stuff by fixing a bug that was declared as feature after it was reported.

A bug is still a bug, even if you call it “feature”.

Try making a 10x10 wall of pistons that all move together without this quasiconnectivity (use that mod above).

Challenge accepted. If you don't want to see a bunch of pistons being placed click here instead.

Grum, Thank you for the reply (really appreciated). I still don't know where this was voted on by the "community", last vote I recall was Notch and his moon vote 😃 (wish there were more of those polls). I'm sure more would have spoken up in this thread if they weren't just watching and waiting (like me) for the "Fixed" resolution.

I accept the Mojang stance but would like to challenge you on your "do not fix since it will break OLD builds" position. This awesome new launcher supports versions and so you really shouldn't worry about breaking RS builds anymore. When a map maker builds a map I would hope them to be expected to know that it will possibly only work with that build (at least that's how I think when I play with making maps.. and I happily fix my RS if it does break because I know it's for the greater good as well as efficiency).

Anyway, thanks again and keep up the good work.

Grum, can you (or anybody else) please provide any decent list of all the useful designs that will probably be mourned about if quasiconnectivity would ever be disabled?

Grum, what about the BUD behavior? Is that part of what you're calling feature/WAI, or are you just talking about quasiconnectivity?

Thank you, Grum, for choosing to keep accepting community input here.

I've probably made it clear that I am also of the opinion that this bug should be fixed for the sake of coherent, intuitive redstone behavior, even at the cost of breaking existing maps. I'm glad to see that you're willing to consider reverting if we can prove that this change won't make particular devices impossible.

I just have one open question - can supporters of this bug-as-feature provide a comprehensive list of constructs which "rely" on this bug? This can help us streamline the process of settling the claim of whether fixing this bug makes things "impossible" or merely changes the way redstoners build things.

And yes, I understand that Grum only said he'd consider it - but by all means, if I find the time, I'll be glad to try my hand at making alternatives to devices which meaningfully use this bug.

Also, can we please put an end to the argument "but then we'll have to rebuild some of our existing machines!"? I gladly accepted the original dispenser bug fix even at the cost of having to scour a massive dungeon and replace 226 broken machines. I think you'll manage, regardless of the scale of your project - if you found the time to make it, you or someone else can find the time to repair it.

As Gerrard asked, I too would like to see a list of devices that rely on this bug. Personally, I have only found it to be needlessly frustrating when attempting to debug a redstone mechanism. Sure, if this would be fixed/removed, we would lose our brainless BUDs, which I personally have found useless, and to those that would lament the loss of their current BUD designs that rely on this, there are plenty of other BUD designs that don't rely on the bug and are sometimes/generally more compact.

Also, this behavior makes no logical sense whatsoever. Using current redstone mechanics, there is no valid reason why a piston should exhibit this behavior.

tl;dr: What this bug giveth, it taketh away. Many users, myself included, have had to work around this bug just to get things to work properly. I have found little use in it other than the occasional one-time-use BUD and to troll somebody building something with redstone.

I'm not big on following ”the Minecraft community”, but I think that the community was kind of expecting this to be fixed back when Mojang announced the Redstone Update — which was specifically described, if I recall correctly (I didn't find any text of the original announcement), as potentially breaking existing redstone machines.

(I've personally had at least two otherwise-straightforward mechanisms broken by this bug, when I tried to use pistons to transfer a signal vertically in a constrained space. Why should up-and-down work differently from sideways?)

Ok, first, the argument of this being non-obvious:
Hoppers locking when receiving redstone isn't obvious on first glance. I sometimes didn't account for that, and stuff didn't work. But, it was always the case, so in the future, I can account for it. Any change to preexisting behavior will break stuff. One change to a block isn't always this, as repeater locking didn't break anything (at least, it shouldn't have).
I had a veuge list of stuff that uses quasiconnectivity in some way on a early post, I'll fetch that.

Hoppers locking when receiving redstone isn't obvious on first glance.

That's a problem with hoppers not having any externally visible or audible indication that they are being powered. They respond immediately to changes that affect them, so the worst case for debugging hoppers is far better than the worst case for debugging quasiconnective pistons.

Ok, I have found that it is realy realy hard to track what will be broken.
I know for sure CNB's 4by4 door is broken, and a type of memory cell.
It is realy hard to test what will be broken.

I personally think that Mojang should take Mumbo Jumbo's suggestion (http://www.youtube.com/watch?v=QYe_xe7SNKY) about splitting the piston. Change the name of the original piston to something like piston (BUD) and that has the same block ID that would be crafted slightly differently and then add a new piston and sticky piston that use the original texture and crafting recipes that don't work in slightly unexpected ways

I know for sure CNB's 4by4 door is broken

I don't think that one will be easy to fix. It might be possible with redstone blocks, but that's the kind of thing I would expect to break eventually no matter what tricks were used.
–
EDIT: Never mind, I didn't remember how it worked, but after looking at it again it looks doable.
–
I managed to fix this 3x3 door by modifying it slightly. It's not quite as compact as the original but the concept is obviously workable.

<blockquote>I personally think that Mojang should take Mumbo Jumbo's suggestion (http://www.youtube.com/watch?v=QYe_xe7SNKY) about splitting the piston. Change the name of the original piston to something like piston (BUD) </blockquote>

YES!

Keep the old block, with a changed name. Add in a new, better, fixed block.

It's like the old "wooden slab" that was kept, and different from the new, current, wood slabs.

Here's "Jeb"(seamless and flush 2-wide) door that doesn't use quasiconnectivity to function.
It's 4 blocks larger to the side and 2 underneath because you can't power the bottom row from the top.
Not a huge size difference.

http://imgur.com/a/7J7bP

Dear Alex and Keybounce. The invention of redstone block made BUD designs without quasiconnectivity possible. All those people above are trying to tell Grum that BUD ≠ quasiconnectivity and the latter is a pure bug, that deserves to get squashed. Yet you guys want Mojang to add not one block but 4 redstone devices with this illogical behavior. Why'd you want that?

I want a properly working piston/sticky piston. Period.

If it takes having both "older, compatible blocks" as well as "newer, better blocks", so be it.

We have – still, today, fully functional – stone slabs that happen to look like wood, but fireproof and using picks.

The old wooden slabs are only kept for technical reasons.
It's perfectly possible to make a BUD that doesn't rely on quasiconnectivity, and I don't understand why people act like fixing this bug kills BUDs.

Edit: In fact, it was possible to make a non-quasiconnectivity piston BUD in beta 1.7. No redstone blocks required.

Keybounce and Alex Campbell, I agree with both of you. I know that it is possible to make BUDs without the quasi connectivity, I personally use them in my builds to avoid anything breaking. Sethbling even made a video on how to build them (http://www.youtube.com/watch?v=Qp4_oQuReuE). The only reason that I brought up Mumbo Jumbo's idea is to keep everyone happy. I'm sure some people would still love to have the quasi BUDs, even though they tend to be larger, they are often more easily tileable. But, the reason I feel that the current piston should have the functionality removed and a BUD piston added is more for inexperienced players. If some inexperienced kid starts playing the game for the first time and puts a redstone block on top of a piston, it'll just get stuck and they'll have no clue why. And Mojang could determine if the new piston gets the BUD or the current keeps it, which would allow for older builds to break, but easily be fixed, or just add a new BUD less piston that wouldn't affect any builds. Besides, most the quasi BUDs aren't really ever used as a BUD. They used to be used to transmit power via a fence gate or trapdoor, but that is now broken. The X x X doors are the only thing that I can think of the really rely on it. Something like a sugar cane farm can just rely on the piston can't push a extended piston arm thing.

Piston doors and buds are the primary use.
The thing is, while I like piston quasiconectivity, there is also dropper and dispencer quasiconnectivity.
That should be fixed, or debated at least.

The old wooden slabs are only kept for technical reasons.

No, they were kept so that not everything was destroyed on the change.

Seem similar?

My taughts on this matter are that this is a bug.
It makes redstone inconsistent.
I'd like to have proper working pistons and maybe a BUD block that would produce a redstone signal (like the button so it would have a cooldown) when it would have adjacent blocks updated.
I will gladly accept any and every challenge to show that builds can be done without this bug.

No, they were kept so that not everything was destroyed on the change.

You might also remember that at one point wooden stairs and fences didn't burn. Slabs got a new block because fire and tool properties are based on block ID, and removing the old blocks would have replaced all the existing ones with air or a different type of slab.

–
Another device that breaks is this piston toggle. It can be fixed by extending the redstone above the pistons over the top of them, placing the torches on the sides of the blocks directly above the pistons, and placing redstone wire directly below those torches:

The torches can be placed on any side of those blocks as long as they don't interfere with the output.

so the worst case for debugging hoppers is far better than the worst case for debugging quasiconnective pistons.{/quote}
Let me just say one thing.
You can spot the problem on first build with hoppers, and with quasiconnective pistons. (As in the problem exists when you build the machine). Changing quasiconectivity will simultaneously break many machines, including ones you forgot used this at all. You realize what a hastle it would be to go about and change every t flip-flop in my world? Even if the design isn't much bigger, it works slightly differently (power in different spots).
And most people (me included) probably wouldn't have expected that t flip-flop to be broken by the change anyway.

I have a build that I believe requires quasiconnectivity. However, I'd like to see if people can build it without using quasiconnectivity. Please check out this world: http://www.uploadmb.com/dw.php?id=1373602193

In this world, I have built a wooden wall where a vertical slice of the wall can be extended two blocks and retracted. A very important aspect of this build is that it is flush. No redstone is visible from the outer portion of the wall. The wall can be made longer in any direction (left, right, up, down) without interfering with the redstone and while remaining completely flat.

I don't believe that this can be implemented without quasiconnectivity, particularly the flush aspect of this build. However, please feel free to prove me wrong 🙂

Here's a piston wall that actually doesn't depend on this bug: (the previously-posted one does)
http://puu.sh/3ATv7.jpg

You can't control each horizontal row independently with that design the way you can with quasiconnectivity.

I've been requesting this issue to get a resolution for as long as I've heard about it. I've started the discussion in the office (and before I moved to Sweden) more times than I can remember.

Always the opposing arguments have always been:
1) all the things existing will break
2) all the things existing might not be able to be build
3) meh, lets not spend time on this again

I just put a resolution on the ticket after asking Jens to do so and somehow that got forgotten (even after repeating the question).

I share the opinion that this 'non-direct-connectivity-still-powers-a-piston' is a bug. It's confusing for everyone but a small niche of experienced redstoners.

It seems that after removing quasi-connectivity there are still working budswitches. Eventhough I think bud-switches shouldn't ever be available because they are based on leaked implementation, I'd be perfectly fine for them to be confined just to pistons & boats (as shown in Sethblings video: http://www.youtube.com/watch?v=Qp4_oQuReuE ).

So in order to possibly get this non-direct-connected-powering removed, I think we need to solve all the problems above, which in theory shouldn't be too hard if we work together.

I can fix the first point by adding a gamerule that allows the old behavior to happen. So people on old maps can still 'toggle quasiconnectivity-mode' while the default normal gameplay wouldn't have that.

I'm not star at redstone, so I have no idea how many contraptions would be unreproducible, I'm quite sure some will be or take significantly more space. I think that if the damage is 'low enough' there might still be a chance that this gets past Dinnerbones & Jeb's scrutiny. But this really will be up to you guys to provide.

Grum, thanks so much for all the help. I think a game rule would definitely be a good idea. Enable it by default for existing maps and then give people the option to enable on new maps, with off being the default settings. My only worry with that option and not splitting into non-BUD
piston and BUD piston or just removing it all together is that some builds will be incompatible between maps. This scenario could occur if someone sees an experienced redstoner on youtube build something with a BUD, then that player build it in there world and turns the feature on. Then if they build something else from someone on youtube the requires the settings being off, it'll just create a gigantic mess because only one will work at a time. This isn't that big of a deal, but still not optimal.

Tim: Which design using this bug does allow rows to be controlled independently?

Edit: This would allow each row to be controlled independently if not for this bug: http://puu.sh/3AWbM.jpg

Excellent, that would even be an improvement over what we have now! 😃

Alex, that design in my mind would cause 2 or 3 rows to fire on the rows where the repeater directly touches the piston due to the piston block being strongly powered.

Tim, pistons cannot be strongly powered. This build would work perfectly with the quasi BUD removed.

Sorry for all of the comments, but I was thinking, one of the reason that BUDS are used is because they can power blocks two below them. What if another block were added to the game that was kind of like a vertical repeater. It could work by placing it like:

redstone
stone
(new block)
piston

It could then transmit the redstone signal downwards, or it could act as a BUD block. The piston would then only react to Quasi connectivity when this block is placed near the piston.

I think the gamerule would solve this and leave everyone happy.
that way people could test both effects and also people could gradually get to know the new mechanics.

that player build it in there world and turns the feature on. Then if they build something else from someone on youtube the requires the settings being off, it'll just create a gigantic mess because only one will work at a time.

Alex, that player would just have to create 2 diferent saves, one with gamerule and the without.

Why a game rule? The launcher can manage multiple versions of Minecraft. If people want to have the bug, the can simply run an older version of the game.

That would mean you can't get new content and still keep this behavior - you'd have to make a choice between quasiconnectivity and everything added in all future versions. Thus, there's a rationale in simply having it as an option that can be switched on.

This would allow each row to be controlled independently if not for this bug: http://puu.sh/3AWbM.jpg

My implementation of the bug fix allows repeaters to power the piston below and in front of them. I think that behavior is useful and intuitive enough to keep, and I'm not quite sure how I would be able to fix this particular device if it was removed:

There's supposed to be a wall in front of it, and powering the piston below the piston next to the repeater would break it.

Powering individual rows of a wall using pistons and redstone blocks is possible with this implementation but quickly gets quite bulky. Powering rows of wall has always been pretty much impossible, so I think it might be worth looking into adding a mechanic to remedy that. You still can't do it with a wall of RS torches, but that's objectively less useful than pistons.
–
@grum: BUDs don't expose more implementation than any other system, they just use it differently. For all anyone else cares, they could just as easily poll for changes every tick and the only difference would be performance. Besides, if all that mattered was hiding implementation we'd all be staring at blank or maybe even invisible screens. 🙂

@Tavis: Can't you make the lower row piston, block, repeater, wire – giving you two rows of wire, with a block separating them?

In either case, treating redstone as "Always has an update range of 2" – such that the upper repeater, and the lower piston are distance 2, so the lower piston will just work – does make sense.

In fact, as I look at that, why use a repeater there at all? Why not redstone dust normally?

If a redstone dust is powered, and the rule is "redstone dust powers anything in range 2", then the lower piston is powered. And, that fits the "repeaters act as signal isolators, and only power the blocks right in front of them" behavior, which would not power the lower piston.

In other words, what seems to be "reasonable, expected" behavior is that using dust instead of a repeater would power both (as well as the one above them if there was a third), and a repeater would only power the one.

(I am not a redstone expert; I've had too much "fun" with torch bugs and repeaters not working right in loops.)

I would also like to vote against adding a gamerule. Utilizing gamerules for optional forward compatibility has never happened before, and if you do it once everyone will end up demanding it for everything.

Can't you make the lower row piston, block, repeater, wire – giving you two rows of wire, with a block separating them?

In fact, as I look at that, why use a repeater there at all? Why not redstone dust normally?

That would power the piston you can't see behind the block the repeater is on.

I would also like to vote against adding a gamerule. Utilizing gamerules for optional forward compatibility has never happened before, and if you do it once everyone will end up demanding it for everything.

Although I would like to see quasiconnectivity fixed, I have to agree with you that the community would end up demanding it for everything. But not fixing bugs because the community like them may just result in the same situation.

Zé, that isn't possible though for servers, like the mindcrack server, and I'm sure that no one would want to have to keep 2 version of their single player LP world up to date. The only time when the game rule might be helpful is for things like CTM or PVP maps.

@Tavis:

@grum: BUDs don't expose more implementation than any other system, they just use it differently. For all anyone else cares, they could just as easily poll for changes every tick and the only difference would be performance. Besides, if all that mattered was hiding implementation we'd all be staring at blank or maybe even invisible screens.

If you were to simulate redstone and flush out the deltas into the world there would not be anything like 'buds'. Buds are leaks of implementation, they should not serve any true purpose to build upon.

@grum Floating sand, breaking and placing blocks, flowing water, etc. would still need to be updated somehow. If everything were simulated the simulation could also take into account any blocks that should respond to such changes.

BUDS are fundamentally a way of detecting "The neighbor block has been updated".

There is a way for blocks, in the code, to notify their neighbors that they have changed. Minecraft, at its heart, is a cellular automata.

Any time a state change is not accurately propagated – even in the case of "which way does water flow from here" – it is possible for the "current state of the world" to be strange. And if a block, upon being notified, makes a change from the inconsistent state into the consistent one, then there is something to detect.

Do you think Etho's old "Boat Bud" should not exist?
Can you see any way to prevent it from happening?

In general, if I have a water source that wants to go either to an immediate fall in one direction, or has to go a longer distance in another direction, even if that direction's length is controlled by a piston, then it is possible for the water source to not notice a "change" that has range 2. And if you teach it to look at range 2, I can set up a bud at range 3. Etc. I see no cheap solution to that.

===

There are only two choices:
1. Buds should not exist. Liquid blocks, whenever they get a random tick, should make at least some attempt to detect changed environment around them. Etc. (Actually, any block that has an action dependent on the environment. Not just liquids)
2. Buds should exist, in some form. Then, the question is only "how big" and "how slow". Etho's boat bud is both big and slow. A single block detector can exist – the existing comparator is almost a bud already (and I just saw a video showing that it can detect changes in tile entity data – a data update detector.)

If you want to use #1 (no buds at all), then a perfect examination of the environment is probably not possible because of time. You can either say "Regardless of CPU power, each block we want to check the environment will sample one or two random blocks in range each update tick", or you can say "Each block that that is environment sensitive will add itself to a current recheck list; each time through the main game loop, some blocks on that recheck list will make some attempts to recheck, and the total amount of rechecks made will depend on CPU power, such that more powerful machines will see a world become more consistent faster", with the length of that list being a trigger for removing older blocks from the list (and possibly a block being smart enough to say "I have now checked everything around me, remove me from the list even if there is spare CPU").

The first of those two choices – regardless of CPU power, each environment sensitive block makes one or two random checks each time it gets a random update tick – is probably the better, more consistent one.

And if you want to use #2 – buds should exist in some form – then there is no reason not to have a single block bud. Either an omnidirectional bud (any change in any neighbor sends a notice to 5 other sides), or a redstone-torch like "single direction in, fixed outputs". I personally would prefer to be an omni-buds-man.

===

Entirely separate from the question "Should there be buds?" is the question, "Should this piston behavior continue?".

Should pistons be changed? We've had a major change to piston timings already. So we already have precedent for changing things.

Should old redstone behavior be changed? We already have seen timings of redstone torches, and the behavior of torch and repeater loops destroyed from 125 singleplayer to anything later (bug #2523, that actually kills much of what I was going to use redstone for in my world. https://mojang.atlassian.net/browse/MC-2523). We've seen really long insta-wire loops that propagated through unloaded chunks in one tick in single player turn into loss-of-sync, multiple tick signals.

And yes, insta-wire can be used as a denial of service attack on a server. Arbitrary inst-computations have been demonstrated as a proof of concept (both instant nand and instant nor gates). But there are no "gamerule" settings – or server.property settings, or anything – for a server to indicate how much instawire / redstone torch updates / etc they are willing to put up with in a tick, and the default settings are too low for doing anything interesting.

===

Bottom line: Mojang has repeatedly broken builds in the past. I think we, the community, have gotten used to, almost expecting this to continue. To now turn around and say "It's broken, but won't be fixed" makes very little sense. And if you are going to say "Promoted to official feature", then consider just how little sense it really makes – I could not describe it accurately if I had to, other than to say: "Generally speaking, a piston can be 'powered' if either the block above it would power a piston, or if while extended, the extended arm is powered and then power removed from the base". I think that's accurate.

And if it's not, how would you describe it such that others can understand it, and be accurate?

Keybounce, that was a very helpful comment. I agree with 90% of what you said truly. I think before every block in the game receives a random tick update, the rendering engine needs to be overhauled. We need things like: Anisotropic Filtering, Antialiasing, OpenGL 4, vRAM compression, Dynamic Chunk Updates, multicore, multithread, the move away from Java to native binaries, etc. This will allow the game to run more smoothly, even on older hardware. This is needed, because certain laptops (which a large percentage of minecrafters play on) get terrible FPS without Optifine, and a majority of users don't know how to add mods. The random tick update will surely cause a further decrease in FPS. Even so, having water updated every tick will subsequently break many builds. This is also the case with the quasiconnectivity BUDs being removed, but the BUDs are more of an inconsistent "feature" (bug) than water not being updated. And if the water were random ally updated, players may not know why. The random tick should only be used for things like crops, soil hydration, or burned out redstone torches, in my opinion. I think the BUD should just be removed all together, but I feel that the community of some of the experienced redstoners who refuse to upgrade to the piston can't push piston head BUD will cause too much fuss for that too occur (I do realize that it wont power a piston two blocks lower, but for something like a sugarcane farm). I think that the only way to fix this is two piston types, a BUD block, or complete removal of the BUD. I don't know if Jeb and Dinnerbone are just appeasing the people who want it by dubbing it a "feature", but it honestly seems way too confusing for the average user who doesn't know why their build isnt working, even though it should in theory work. Grum, I'd love to hear your latest thoughts on this issue and what your other ideas on future implementation might be. I think that this comment thread just needs to pick one way to go with this and then help you move forward with that idea with ways to implement it, how it would work, etc.

I’m pretty sure “the community” we’re talking about on here is only a few big redstoners with a lot of subscribers on Youtube. Most of the community either doesn’t care or wants the bug being fixed.

I’m pretty sure “the community” we’re talking about on here is only a few big redstoners with a lot of subscribers on Youtube. Most of the community either doesn’t care or wants the bug being fixed.

No. The behavior has a ton of uses, including in piston doors and everything. Fiddle around with the mod mentioned earlier, you'll see what's broken. It's hard to figure out. Not only buds.

Re-read the comments and check the so-called “broken” builds created with that mod.

I have. There's many. It's hard to figure out which ones actualy are broken. So far, we have found 2 broken systems, one of which is the most common t-flipflop in the world, and will break 90% of all maps if broken. (That may be an exaduration, but it is a common design).

@Dirk Sohler

I’m pretty sure “the community” we’re talking about on here is only a few big redstoners with a lot of subscribers on Youtube. Most of the community either doesn’t care or wants the bug being fixed.

Couldn't have said any better.

@William Pearson

I have. There's many. It's hard to figure out which ones actualy are broken. So far, we have found 2 broken systems, one of which is the most common t-flipflop in the world, and will break 90% of all maps if broken. (That may be an exaduration, but it is a common design).

Just do a hopper t-flip flop

http://www.youtube.com/watch?v=vSYp3f6sTJ8

@Zé Carlos
Look, the point is, a design that common is broken. Many things are broken. There already are several quick fixes (putting redstone dust below the torches), but doing that requires large amounts of work.
Supose you are doing something extremely complicated. (http://forum.redstonedev.net/showthread.php?tid=1494 http://forum.redstonedev.net/showthread.php?tid=1651 ect.) How much fun would it be to go thru and replace every single t flip-flop? It would take ages, and the new design wouldn't be as compact.

And that was just a example.
You wouldn't realize how many things might be broken.

@William Pearson
I like to use as little pistons as possible in redstone builds because it can do quite a bit lag depending on the quantity and intensity.
Probably before repeater locks, and hoppers we didn't have means to work around, but now we have.
somethings break, some change, some are added.
That's just how things are.
Progress is good.

@Zé Carlos

I like to use as little pistons as possible in redstone builds

Then how does this effect you? Are you trying to remove this because it broke one of your machines?

Besides, there are ways to work around this before then. And even if we have new designs, the old t flip-flop is the most resource-light design. (Even with the change.) Thus, it is used a lot. And changing the thing that is used a lot?

And it would be a removal without a replacement. Unlike minecart boosters (with parallel minecarts).

@William Pearson
I've been trying to use less pistons since I discovered this annoying bug that makes them unreliable and highly susceptible, but using as little pistons as possible means I still use them,
Pistons are useful and needed but I would really like be able to use them in my builds without any of those weird behaviours.

I was saying if you have some old designs that use this bug that there are ways around and just as compact and if that design is massive more of a reason to use them because of less lag.

And it would be a removal without a replacement.

what would be a removal without a replacement?

You want quasiconnectivity for t flip-flop but they can be done just about the same size or less.
I'd like you to point out designs that use quasiconnectivity and can't be done in any other way.

Here's a much more flexible piston toggle. The repeater is required when it is facing most directions, but in some cases it can be omitted. The input can come from any direction, the output can be taken from any side of the redstone block, and the output piston can be rotated in any direction except towards the input.

–

For the alternating extended/retracted piston wall using the mod provided: Send a one tick pulse to the repeaters next to the pistons while sending a two tick pulse to the other ones to extend the pistons directly next to the repeaters. The other pistons can be extended as normal or with a one tick pulse if you like consistency. Two or more tick pulses will clear the wall. If you want to extend raw pistons just use redstone blocks and add another wall of pistons in front of the first. If one set of rows is already extended it can be reversed with a one tick pulse.

I'm not saying that they cant be done. I'm saying that many prevalient designs have it used.
Oh, and you can often help "ignore" quasiconnectivity (in all cases exept those that have vertical redstone blocks) by using upsidedownslabs.
Like this curcit.

The upper and lower lines trigger seperatly.

████▂▂▂
▂▂▂██▀▀
███-]████

@Zé Carlos
Just get used to it.

There are a fair amount of things. Saying "I Don't understand this help plz!111!!!" (Which you didn't, this is intentionally exadurated) is not the correct response to a behavior that can be worked around, is stable, and has been in the game for 2 years.

My first reaction was confusion too. But it has been very helpful sinse I got over that.

@William Pearson

Just get used to it.

I see what you're trying to say, but to me that is an invalid argument. You could just say that about every other bug: "don't fix this bug, just get over it". I'm sure there are bugs some people love and some people hate, but despite that, keeping a known bug in the game is not right.

I stand by my points and have nothing else to say.

Well, in my opinion, it has become too usefull to remove, even if it experiences bug-like side effects.
Whenever someone argues about keeping known bugs:
Creepers were origionaly a improperly moddled pig.

Bugs can lead to good things.
They said that this is no longer considered a bug.

Creepers were origionaly a improperly moddled pig.

And then Notch just gave up and left them with a pig skin and dropping pork.

Yes, bugs can lead to good things, that is, if they don't negatively affect the experience of players. This bug, however, HAS a negative effect that leads to illogic behaviour (pistons getting stuck in states they shouldn't be in, etc.) and prevents people from building machinery that SHOULD work by all logic means. I can't believe keeping a bug like this in game is even open for discussion, let alone accepting it as "intended". If a bug is needed to provide functionality that the main game doesn't provide, then something is fundamentally wrong. If the functionality is necessary, provide an item or method that provides it WITHOUT negatively affecting the experience of legit players. That the bug has always been in the game is not a valid argument for it's existence. Also, a fix breaking existing machinery is not an argument either, because everyone who (ab)used it could clearly see that the illogic behaviour could have never been intended and thus might get fixed in the future.

However, all idealism aside, keeping the current Block IDs as pistons with the bug for the sake of backwards-compatibility and having new fixed piston blocks for crafting and the creative menu would be a compromise that should acceptable for everyone, because all would get what they want and noone would get harmed in the process. Legit players would have a bugless experience, existing contraptions would not break and mapmakers who like to use the bug can just spawn in the old pistons via /give command.

Creepers were origionaly a improperly moddled pig.

And then Notch just gave up and left them with a pig skin and dropping pork.

I'm saying good things come from bugs sometimes.

This behavior (That's the most neutral term for it I can think of) is far to usefull to be removed.
Especially sinse it has been used for over two years, and can be established as a base property of pistons.

Yes, bugs can lead to good things, that is, if they don't negatively affect the experience of players. This bug, however, HAS a negative effect that leads to illogic behaviour (pistons getting stuck in states they shouldn't be in, etc.) and prevents people from building machinery that SHOULD work by all logic means. I can't believe keeping a bug like this in game is even open for discussion, let alone accepting it as "intended". If a bug is needed to provide functionality that the main game doesn't provide, then something is fundamentally wrong. If the functionality is necessary, provide an item or method that provides it WITHOUT negatively affecting the experience of legit players. That the bug has always been in the game is not a valid argument for it's existence. Also, a fix breaking existing machinery is not an argument either, because everyone who (ab)used it could clearly see that the illogic behaviour could have never been intended and thus might get fixed in the future.

However, all idealism aside, keeping the current Block IDs as pistons with the bug for the sake of backwards-compatibility and having new fixed piston blocks for crafting and the creative menu would be a compromise that should acceptable for everyone, because all would get what they want and noone would get harmed in the process. Legit players would have a bugless experience, existing contraptions would not break and mapmakers who like to use the bug can just spawn in the old pistons via /give command.

For one, you have a strongly negative attitude. However, the second paragraph is the optimal case.

I would, however, appreciate it still being craftable.
And, removing a thing that is the fundamental princable of many redstone contraptions, for example 3by3 and 4by4 doors, would be a terrible idea.
If you want proof that this is needed and removal will IRIPLACALBY break things, try building a 5by5 piston door without this.

And saying illogical/non-obvious things should be removed?
Well, repeater locking.
Who would have guessed that pointing a repeater into another would do that?
The only case where, with pistons, this breaks things, is a redstone block ontop of a piston.
Fixing that one thing, and breaking almost everything else?
NO.

And, you can generaly curcimvent this behavior with slabs.
And only in highly compact piston circuits does it become obvious.
And unless you jump right into advanced redstone without wiking anything, you should realize this happens.
And design circuits around it.
Not against it, hoping that it will be fixed magicly and then your circuit will work.

And, I have had my own circuits broken by this.
I don't complain, I use it in other circuits.
If it does require a total redesign, that annoys me a bit, but I prefer having the cases where it helps in the game.

And, removing a thing that is the fundamental princable of many redstone contraptions, for example 3by3 and 4by4 doors, would be a terrible idea.

I posted a screenshot of a working 3x3 door and have built half of a 4x4 door that operates by manually toggling levers. The design can be mirrored and the lever flipping can be automated.

try building a 5by5 piston door without this.

You're getting a bit ridiculous here, but I suspect that those would be possible to build using redstone blocks.

Well, repeater locking.

Name one useful thing besides this that aiming a repeater at the side of another repeater does. I'd also like to point out that it is immediately obvious that something is happening.

The only case where, with pistons, this breaks things, is a redstone block ontop of a piston.

Two systems that are normally not used together and don't normally interfere can break when they are both activated at the same time. You may notice that this bug was reported before 1.5.

And, you can generaly curcimvent this behavior with slabs.

That is neither an obvious solution nor solves all of the problems with this bug.

And only in highly compact piston circuits does it become obvious.

They don't need to be compact for this to be a problem. A single wire in the wrong place is all it takes.

And unless you jump right into advanced redstone without wiking anything, you should realize this happens.

How about experimenting with redstone and building up your knowledge? How do you think people managed to write the wiki in the first place?

And design circuits around it.
Not against it, hoping that it will be fixed magicly and then your circuit will work.

This is pretty much what already happens because, short of using a mod, we can't test the circuit to make sure it would work.

Is it just me or does it appear that @William Pearson is the only one who wants this to stay WAI?

@Brandon
No, i'm not.
There's many redstoners that use this.
And, others were arguing about this way before.
They just gave up on responding, this thing has spammed my inbox a ton.
Did you know that gmail resets threads every 100 messages?

Look through all the comments.
Or try.

Did you know that gmail resets threads every 100 messages?

This just shows that there IS a lot to discuss. Simply closing with “Works As Intended” just don’t works here.

At this point Mojang probably doesn't care (or ever did) about feedback but anyway my feedback is, big thumbs down to Mojang for closing this as intended behavior. I prefer predictability rather than having extended unpowered pistons, etc. Instead of fixing this bug as early as possible, you allowed for all these possible contraptions to be built and now you say that we will have to live with it because you can't just break all these contraptions and that the community demands it to not be fixed.

At this point Mojang probably doesn't care (or ever did) about feedback but anyway my feedback is, big thumbs down to Mojang for closing this as intended behavior. I prefer predictability rather than having extended unpowered pistons, etc. Instead of fixing this bug as early as possible, you allowed for all these possible contraptions to be built and now you say that we will have to live with it because you can't just break all these contraptions and that the community demands it to not be fixed.

Negative response.

You realize this is about 2 years old now, from beta 1.7?
The main thing this breaks is transferring data upwards with a stack of pistons and redstone blocks.
And, that would just be a slower and less efficient way of sending signals up.
Please, lets just stop arguing, I don't want more inbox spam.

Grum, I think we need your input on this issue again. This comment section has just turned into a massive argument over nothing. You said that you would try to put a game rule in, and I think that stirred up commotion. I think the options to resolve this problem are: add a game rule(not optimal), remove the BUD, name it as a feature and disable comments here, make a BUD block, or split the piston into a BUD piston and a non-BUD piston. My opinion lays with the split, but other people may have differing opinions. Love to hear what you think and hope it can resolve some of these arguments.

I agree with you. I would choose the split too. But would the old pistons be converted to the BUD pistons?

If we were to split into two types of pistons the old ones would become BUD pistons if they kept the same block ID

I would say keep all current pistons as BUD pistons. That way nothing breaks. The crafting recipe could just reverse the redstone and iron or just use more redstone for the BUD piston.

@William Pearson

lets just stop arguing, I don't want more inbox spam.

Nice way to tell someone to just be quiet because you have run out of arguments, also there's a "Stop watching this issue" link, if you are so worried about spam.

Although you are probably the one who comments the most and keeps coming back, even after your arguments are proven invalid.

@Alex Taffe

This comment section has just turned into a massive argument over nothing.

Agreed, with this, let's move on and try to think of solutions that will make both groups happy.

1. I think that fixing BUD behaviour and adding a bug-free BUD block would be the best option, in my opinion.

2. Spliting pistons with inverted recipes is nice idea but as the gamerule idea, I think keeping bugs like this in the game for backwards-compatibility would only let them grow even less stable.

But at this point, I think they just don't care anymore.
Yesterday I made 3 contraptions and for my amazement all of them had bugs. In 2 of them, the pistons became stuck because of a diagonal powered block (was able to solve it with half-slabs, but still...). In the last 1, got a piston that remained powered in upward position, in an edge detector clock I bult. But unlike the other 2 contraptions, there is no way to easily counteract this behavior.
I have also run across MC-16097 and 2 other diffrent bugs but won't report them because i'm losing the faith in this. Seriously, after wanting to make a decent contraption, yesterday, and finding bugs in almost everything makes me lose the interest in this.

But I would like to make one last appeal.
3. If they don't want fix it, ok, fine. But at very least try to find a way to fix the piston stuck in upward position behavior, because the only way to make it retract, is to replace the block above it.

Couldn't agree with you more.

I have an idea, moving forward, for how to distinguish the two pistons.

The new, "properly functioning" piston has the same recipe we now have – three wood on top, stone edges, iron and redstone in the middle.

The old, "oddly diagonally powered" piston gets a new recipe – the redstone dust is moved from position #8 (bottom middle) to position #1 (top diagonal corner). The wood block goes where the redstone was.

Does that make sense? As much sense as the behavior of the old piston. But it seems that two different piston blocks is the only workable solution that makes everyone happy.

@Keybounce
The main argument about that idea is that it would confuse people to have two recipes.
In my opionion, that is just wrong, sinse the opisition of quasiconnectivity states that the current way is confusing, too.
I, personaly, think that maybe the recipie should use gold, although that doesn't make much sense from a design perspective.

It should use the same block id.
Or something like that, i'm fairly tired right now.

Another idea is to keep the old recipe, but have two outputs. Them being the BUD and non BUD pistons.

I don't think it's necessary to have a recipe for the BUD pistons at all. Usual survival players don't know of the BUD behaviour and expect a bugless piston. Bugless survival mode should be the goal to strive for after all. Those who use BUDs rather use it for mapmaking or experimental builds and would use the creative menu or the /give command to get the pistons anyway.

That's a good idea. I think that idea is probably the best way to solve the problem unless someone else comes up.

That isn't really a compromise, though. The typical survival player doesn't use redstone. And the budding pistons are used in most large doors and stuff, such as 3by3's, so a crafting recipe would be nice to keep so that I don't need to go and make 2000000 pistons so that I can have bud pistons. IE, those who would want it would want it, and you shouldn't make it annoying; that's basically removing bud pistons but not breaking builds, but it would break designs that already exist.

Even if the recipe is surrounding a piston with redstone in the crafting grid or using a repeater or torch instead.

Some recipes:

Yes, this is sugestiony, but I feel like we need to show the recipies, and I didn't feel like trying to use symbols.

@Tim H

I don't think it's necessary to have a recipe for the BUD pistons at all. Usual survival players don't know of the BUD behaviour and expect a bugless piston. Bugless survival mode should be the goal to strive for after all. Those who use BUDs rather use it for mapmaking or experimental builds and would use the creative menu or the /give command to get the pistons anyway.

Never thought about it in that way, it seems like really good idea.

@William Pearson
Good work elaborating the images.
In your post, the gold/iron one seems interesting and I also like the redstone torch/redstone dust since the materials are similar because you just add a stick to the redstone.
If that idea is to be executed, why not just differentiate them with stone/cobblestone? They would also need to be visually distinguishable, so that way one would have a cobblestone cover and the other a smooth stone cover.
That way the materials would basically remain the same since stone is smelted cobblestone.

This really needs to be fixed .'

@Lewis Moore
It was decided that it wont be fixed, although various solutionoids have been made.
Check my earlier post.
(Would you support two types of pistons?)

Tails, screenshot2-.jpg depicts of the situation I've been talking about. The piston remains extended even after receiving no power because the redstone block still powers it at an incorrect position.

~Jouster500

@Zachary
Yes, that is a bug, but Mojang decided they wont fix it due to various connected bugs.
Slog thru all the comments.

Yes, that is a bug, but Mojang decided they wont fix it due to various connected bugs.

Mainly because some AAA Youtubers will be pissed if Mojang would fix that bug because it brakes their Redstone builds causing bad promotion and possible loss of said Youtubers and thereby less Minecraft sales.

Assumption: Not fixing the bug is mainly a promotional issue. (And you can’t prove me wrong!)

@Dirk Sohler

Actually it is working as intended because it is a bug turned feature by demand of the community. Would you rather have is break all existing maps and make certain constructs impossible?

Try making a 10x10 wall of pistons that all move together without this quasiconnectivity (use that mod above).
If you can make alternatives for all the existing structures we might consider it.

(That's from grum in the comments a while ago)

Iirc there are already videos proving that this is possible.

@Dirk Sohler
Look, this is a very usefull thing to have in the game.
The upwards piston behavior is annoying, but realy, its basicly a feature request there.
How many times are you going to use that?
This behavior is highly useful.

> This behavior is highly useful.

The problem is: Proper behavior is also highly useful.

• BOTH* behaviors have use.

It is apparently easier to mimic the bugged useful behavior with a proper piston than to mimic the proper useful behavior with a bugged piston.

The whole issue can be solved by having both kinds of pistons.

Either form, by itself, will make some things easier and some things harder.

But what is currently there is inconsistent, and confusing.

If I were to retype what I had said before 20 times, I would be able to answer every duplicate statement. IE, @Keybounce, don't you realize that I posted the design earlier?

I wish that we had both kinds, but if they don't implement this, its better to keep it like this.
Think of it like torch burnout: You don't find it useful but instead annoying, and you need to design your circuits around it, but there are some pretty amazing machines that work using it.

So you mean that the piston no longer responds to redstone/block updates?

...No, wha? Nothing has changed...

Is there any known way to work around this? It ruined my contraption.

@Paul Smith
The easiest way to work around this is with slabs. BTW, this has been in the game sinse pistons were added.

What are you trying to do with your contraption?

If the issue you are having is actually related to MC-11193 (this video:http://www.youtube.com/watch?v=e5hUYLC8Tms), then slabs MAY fix your problem, but so could a number of other things.

If need be, you can upload a picture of your contraption and I can try to fix it.

Someone please fix this glitch, whether it is intentional or not the majority of us find it annoying.

Someone please fix this glitch, whether it is intentional or not the majority of us find it annoying.

1, I would like to see some stats on that. It is rather annoying.

2, It is confusing until you learn how to do it, but so is A) Java, B) Most of (or all of) all other redstone, C) The human body, D) Command blocks, and E) Nbt stuff.
3, It is rather easy to work around it, once you understand WHAT is happening, it is easy to figure out how to avoid it.

Generally, play around with using upsidedown slabs (/give @p 44 1 8) to insulate from this behavior. It wont be changed, so figure out how to avoid it until you start using it.
Sometime, they may add a non-quasi piston, but this will not be removed.

I understand that, it's a useful tool. But the fact that the piston 'head' counts as a redstone block when extended is the annoying part. It makes it so you cannot put pressure plates within the vicinity of it. I do wish that part could be fixed, with the current piston or a new one.

I understand that, it's a useful tool. But the fact that the piston 'head' counts as a redstone block when extended is the annoying part. It makes it so you cannot put pressure plates within the vicinity of it. I do wish that part could be fixed, with the current piston or a new one.

By it counting as a redstone block when extended, do you mean that it can receive redstone?

Can you post a picture or diagram of your current design?

I haven't found a way to independently control rows of pistons (in a vertical grid) due to this behavior. It may allow some designs to be more compact, but it makes others completely impossible.

I haven't found a way to independently control rows of pistons (in a vertical grid) due to this behavior. It may allow some designs to be more compact, but it makes others completely impossible.

Ah, that problem. Yea, that's the one major problem with this behavior: it can make that almost impossible.

You can pulse the row and then give a 2-tick pulse to the row below, but that still is a pain.
It can be done, however.
This is a old (now broken) design that depended on this and a additional block-updating behavior, there is a version for 1.5+ but I'm not sure where.
http://www.youtube.com/watch?v=sN6EmfmgJic&list=TLlmJrzHq6S3ahyn8m0I-OhyXDs4LvZ3xT

8 = PISTON
O = BLOCK
_ = PRESSURE PLATE

........................
................_
...................O
...................8

This kind of setup doesn't work due to this bug. when the piston extends, it wont deactivate due to the pressure plate now powering it.

Below is the piston pushing the block level to the pressure plate.

................_O
....................|
...................8

Even if the signal cuts off, the piston stays in place due to its extended head counting as a redstone block type.

Try this:
 ▂▂ 
▀▀┯
████
I cant tell exactly what you are doing, but if you want to try redrawing your symbols, heres the text I used for mine:

{color:brown} ▂▂ {color}
▀▀┯
{color:white}██{color}██

Can't We Just Lock This Page?
IT WORKS AS INTENDED.
I, as redstoner, I don't want this "BUG" (not in my opinion a bug) to be removed. All systems will break with BUD-switches.
So said Grum that already

>I, as redstoner, I don't want this "BUG" (not in my opinion a bug) to be removed. All systems will break with BUD-switches

You don't understand.

I'm not asking / wanting the behavior of piston block 33:0 or sticky piston block 29:0 (I hope I have those numbers correct – odd that they are not adjacent numbers) to change. I don't think anyone else contributing to this thread is asking for existing behavior to change.

I want them relabeled to something like "Quasi Piston", or "Quasi Sticky piston".

I want the crafting recipe for them changed, with the redstone in an odd place, to indicate that they can get power from an odd place.

I want new pistons added – either new blocks or new meta data – that behave sanely.

I fully agree with Mojang that "Fixing this would break too many things". Never mind that the timing changes to pistons in 1.5 broke things, and as far as I can tell, ruined dependability (if a piston is guaranteed to make its state change in 1.5 redstone ticks, then you know exactly what the status will be at 1 redstone tick, and at 2 redstone ticks. If the piston is guaranteed to make its state change in 2 redstone ticks, then is it at the beginning of that tick before anything else happens, somewhere in the middle, at the end, how does it interact with other things happening, etc.)

Mojang has a history of "We will break things".
I'm not asking for "Break things".

"Works as intended" is not a valid resolution.
"Will not fix" is.
"Unexpected, but now desired" is.
"Will fix without breaking things" is.

The current system makes little to no sense, causes all sorts of problematic work-arounds, and yet still has uses.

I really cannot believe "This was the goal from day one" ("working as intended") is accurate.
Say something like "We want this current, strange system", "Fixing it is more hassle then we think it is worth", "Yea, it needs to be fixed, but it's a very low priority for us", "We'd like to fix it, but we don't see an easy way to fix it", or something else.

In short, the entire problem is because the bugtracker can't let you lock it, and Mojang only includes a few resolutions.

Mojang includes "Won't Fix" as a resolution, which they've used in the past. I'd argue that they should have used it here, too, but that's really the least important thing in this issue. I agree with Keybounce - it would be nice if they could fix this without breaking pre-existing builds.

And I don't see why the tracker should let you lock discussions. It's bad enough that it lets you lock votes. If you don't want to participate in the discussion, and don't want to be reminded of this thread anymore, then simply click "Stop watching this issue" at the top of the page. Considering Grum said he may reconsider the resolution if there's enough of a push for it, it doesn't make sense to lock the discussion.