Sticky pistons do not retract a block which they have pushed when given a short pulse
[Mojang] Jeb (Jens Bergensten) resolved this report as "Works As Intended". He also commented roughly one year later as response to the following:
Panda4994 (source):
I always viewed the breaking of the sticky piston connection as inertia, and taking away the block teleportation part, I don't think this behaviour is buggy at all.
Jeb (source):
The reason why the piston behavior "technically a bug" is because the block in front of the sticky piston is supposed to act as if fixated to the piston. Your interpretation as "it's inertia" actually makes sense.
The bug
When a sticky piston is powered with a very short pulse ("0-tick pulse"), it will push the block, but not retract it.
To reproduce
Build the contraption in this screenshot:
The redstone block will not be pulled back.
After 1.14, it is also possible to reproduce this by placing a button on the side of a sticky piston, and press the button to move a block.
Linked Issues
is duplicated by21
MC-5763strange piston behavior with redstone blocksDuplicateMC-5862Pistons retract when powered by a block they're pushing with pulling block backDuplicateMC-6092When powering a sticky piston with a redstone block the piston retracts without pulling the redstone blockDuplicateMC-8752Piston ProblemDuplicateMC-9033Sticky pistons occasionaly do not retract a block which they have pushedDuplicateMC-11888Sticky piston + block of redstone clock will not work with a repeater on 1-tick delayDuplicateMC-12960Sticky Pistons don't grab certain itemsDuplicateMC-18450Sticky pistons, even on a long pulse, will occasionally not retract with the block they are meant to retract.DuplicateMC-19334Un-sticky Pistons?DuplicateMC-27986Sticky pistons not working properly when powered by a short chargeDuplicateMC-40661Sticky piston no longer sticking when redstone placed in a certain wayDuplicateMC-41010Pressure plates and sticky pistonsDuplicateMC-52525Sticky pistons won't pull dirtDuplicateMC-75848Sticky piston wont retract blocks if it's retracted too quicklyDuplicateMC-104775Sticky Pistons Leave Block BehindDuplicateMC-106750Sticky Piston Glitch in 16w35aDuplicateMC-157827The Sticky piston won't pull the block back if it's moving fast.DuplicateMC-159534Sticky piston bugDuplicateMC-170380Sticky pistons no longer work.DuplicateMC-182314If sticky pistons instantly retracts, it will not pull blocks back.DuplicateMC-183250issue with sticky pistonsDuplicateAttachments1
![[Mod] violine1101](../../../data/avatars/users/92858.png){kind=small}
Created Issue:
Sticky Piston lets go of Redstone Block
Sticky piston lets go of a redstone block when powered quickly.
Using this setup you can see the piston attaches out to pull the block in, but pushes the block away and does not pull it back. (Intended?)
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
relates to
relates to
StickyPistonlets go of Redstone BlockSticky pistons occasionaly do not retract a block which they have pushed
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
Sticky pistonsoccasionalydo not retract a block which they have pushedSticky pistons do not retract a block which they have pushed when given a short pulse
is duplicated by
![[Mod] Torabi](../../../data/assets/gravatar/torabi.png){kind=small}
is duplicated by
relates to
is duplicated by
![[Mojang] Grum (Erik Broes)](../../../data/assets/gravatar/grum.png){kind=small}
![[Mojang] Jeb (Jens Bergensten)](../../../data/assets/gravatar/jeb.jpeg){kind=small}
[Mojang] Jeb (Jens Bergensten)A comment with security level 'global-moderators' was removed.
A comment with security level 'global-moderators' was removed.
is duplicated by
is duplicated by
My Titlea block of text surrounded with a panel
yet another lineSticky piston lets go of a redstone block when powered quickly.
Using this setup you can see the piston attaches out to pull the block in, but pushes the block away and does not pull it back. (Intended?)
My Titlea block of text surrounded with a panel
yet anotherlineSticky piston lets go of a redstone block when powered quickly.
Using this setup you can see the piston attaches out to pull the block in, but pushes the block away and does not pull it back. (Intended?)Resolution note[Mojang] Jeb (Jens Bergensten) resolved this report as "Works As Intended". He also commented roughly one year later as response to the following:
Panda4994 (source):I always viewed the breaking of the sticky piston connection as inertia, and taking away the block teleportation part, I don't think this behaviour is buggy at all.
Jeb (source):
The reason why the piston behavior "technically a bug" is because the block in front of the sticky piston is supposed to act as if fixated to the piston. Your interpretation as "it's inertia" actually makes sense.
Sticky piston lets go of a redstone block when powered quickly.
Using this setup you can see the piston attaches out to pull the block in, but pushes the block away and does not pull it back. (Intended?)
is duplicated by
is duplicated by
Resolution note[Mojang] Jeb (Jens Bergensten) resolved this report as "Works As Intended". He also commented roughly one year later as response to the following:
Panda4994 (source):I always viewed the breaking of the sticky piston connection as inertia, and taking away the block teleportation part, I don't think this behaviour is buggy at all.
Jeb (source):
The reason why the piston behavior "technically a bug" is because the block in front of the sticky piston is supposed to act as if fixated to the piston. Your interpretation as "it's inertia" actually makes sense.
Sticky piston lets go of a redstone block when powered quickly.
Using this setup you can see the piston attaches out to pull the block in, but pushes the block away and does not pull it back. (Intended?)
https://i.imgur.com/f5VMb.pngResolution note[Mojang] Jeb (Jens Bergensten) resolved this report as "Works As Intended". He also commented roughly one year later as response to the following:
Panda4994 (source):
I always viewed the breaking of the sticky piston connection as inertia, and taking away the block teleportation part, I don't think this behaviour is buggy at all.
Jeb (source):
The reason why the piston behavior "technically a bug" is because the block in front of the sticky piston is supposed to act as if fixated to the piston. Your interpretation as "it's inertia" actually makes sense.
The bug
When a sticky piston is powered with a very short pulse ("0-tick pulse"), it will push the block, but not retract it.
To reproduce
Build the contraption in this screenshot:
The redstone block will not be pulled back.After 1.14, it is also possible to reproduce this by placing a button on the side of a sticky piston, and press the button to move a block.
is duplicated by
is duplicated by
![[Mod] tryashtar](../../../data/avatars/users/41963.png){kind=small}
is duplicated by
Duplicate of MC-5726 , please use the search function to see if your bug has already been submitted. Currently over 40% of tickets are being closed as duplicate.
Duplicate of MC-5726, please use the search function to see if your bug has already been submitted. Currently over 51% of tickets are being closed as duplicate.
At the very end in the video it tells you to increase the repeater delay. Duplicate of MC-5726.
Duplicate of MC-5726 - If you have not, please use the search function in the future, to see if your bug has already been submitted. If you could not find the original report, please comment with the keywords you searched for.
Agreed. Which is why MC-5726 should be fixed. If it is fixed, this won't be an issue anymore. Until then, this still isn't a bug. This is what's supposed to happen, you're just used to the bug happening, so you see this as a bug itself.
I don't think they will remove QC, because if they really wanted precise feature parity, they would have made the PE/win10 pistons as fast as the PC pistons (they are currently twice as slow, and retraction does not remove the block instantly). Another QC like bug they fixed in PE is MC-5726, which nobody seems to see as a bug.
"Piston warping does not exist in WIN10 MC" It does, but it's not the same as PC piston warping. A piston can push you inside an other piston, and if you power this other piston, you can move again. It's buggy and unreliable, but it exists.
"The sooner this gets either fixed or at least declared as a bug officially, the better." I think everyone agrees on this point.
Azelef Maybe at this point we should consider a Redditpost over on Mojira or we might go into meta, or to things not 100% applicable to this bug, but let me state something quick:
Another QC like bug they fixed in PE is
MC-5726
They did not "fix a (JAVA-MC) QC like bug in PE", there has never been QC in the first place in PE/WIN10.
I also already said that their pistons are buggy (as hell), they are brand new and a matter of a lot of improvements.
Additions are rarely without any bugs, so you can't tell by their current behaviour how they might end up to be.
The only thing we can do is to give reasonable input.
I've read now from several Mojang/Microsoft-MC Devs that they consider QC annoying, unreliable,
How big is the chance that QC will remain in Java-MCPC, or other things that are obviously bugs like this where you can pull an entity through a piston?
I tried and still try my best to convince them to introduce things that can replace QC, as the BUD block can't from what I saw (although it adds a lot of more neat possibilities), and I hope others will still contribute for a general topic about improving Redstone generally, not only pistons.
![[Mod] Neko](../../../data/avatars/users/92901.png){kind=small}
Dupe of MC-5726
[~Dominic Burke], MC-5726 was resolved as Works As Intended. It's not a bug, it's a feature.
That feature was there at least since 13w01a (2013), and you found it only in 16w35a (2016).
[Mojang] Jeb (Jens Bergensten) marked MC-5726 as "Works as Intended" himself. If you really want this to be changed, you can submit a feature suggestion/change at Minecraft Suggestions on Reddit.
When powering a sticky piston (with a movable block in front) with a short pulse (e.g. monostable circuit, observer, etc.), it pushes the block forwards as expected but leaves behind an extra arm. This does not occur when a sticky piston retracts a block or when a regular piston pushes a block. According to MC-5726 and prior versions, the sticky piston should only push the block forwards and then immediately retract.
https://gfycat.com/CheerfulAnxiousDipper (file was too large to attach)
The Bug
Usually sticky pistons pull blocks back that are placed in front of them. A piston, that is powered using a short pulse, however, leaves its block behind when retracting. This behavior broke in this week's snapshot.
This was an actually intended feature, see: MC-5726.
Speculations
I can imagine that this happend by accident when cleaning the code. It was the case before, that a sticky piston that updated and is no longer powered, would tell the block in front of it to immediately turn from block 36 to its normal block again. Maybe some rewriting changed when that happens, and thus the block now turns into a normal block before the piston starts retracting again.
![[Mod] NeunEinser](../../../data/avatars/users/39263.png){kind=small}
The Bug
Usually sticky pistons pull blocks back that are placed in front of them. A piston, that is powered using a short pulse, however, leaves its block behind when retracting. This behavior broke in this week's snapshot.
This was an actually intended feature, see: MC-5726.
Speculations
I can imagine that this happend by accident when cleaning the code. It was the case before, that a sticky piston that updated and is no longer powered, would tell the block in front of it to immediately turn from block 36 to its normal block again. Maybe some rewriting changed when that happens, and thus the block now turns into a normal block before the piston starts retracting again.
Then why was MC-5726 marked as WAI? And why has that not been updated if this is intended behaviour? It should be resolved, not working as intended, if this really was intentional.
And on Nov 10th, 2015 _jeb marked MC-5726 WAI. I guess he changed his mind, but it has been codified in the games source code since then in a very explicit and intentional way.
Another issue with this chunk loading (or not loading) behaviour:
I created this setup and powered the pistons:
2019-05-03_01.37.21.png
Then I unpowered the pistons again, resulting in a display of what was previously powered:
2019-05-03_01.40.35.png
At some point the pistons do not get powered anymore (might be intended, but probably not) and for some reason they get a single tick pulse when I fly over to them, triggering MC-5726 (which should be reopened BTW). This can also be seen without using bugs by looking at the repeater clock: It pulses instead of being permanently on.
2019-05-03_01.41.02.png
The distance to the beginning is much further than the 2 chunks render distance I used for this test, about 10 or 11 chunks:
2019-05-03_01.44.32.png
Does MC-5726 describe your issue?
Thank you for your report!
We're actually already tracking this issue in MC-5726, so I resolved and linked this ticket as a duplicate.
However, that ticket has already been resolved. Depending on the resolution, that can mean that it either will be fixed in the next version, or that it is not considered a bug and won't be fixed.
If you haven't already, you might like to make use of the search feature in the future to see if the issue has already been reported.
Thank you for your report!
We're actually already tracking this issue in MC-5726, so I resolved and linked this ticket as a duplicate.
However, that ticket has already been resolved. That means that this is not considered a bug and won't be fixed. Please do not leave a comment on the linked ticket.
If you haven't already, you might like to make use of the search feature in the future to see if the issue has already been reported.
Quick Links:
📓 Issue Guidelines – 💬 Community Support – 📧 Customer Support – 📖 Game Wiki
, but taking no time to propagate the negative 
, which results in the bug, that was previously reported here:
To add on, the circuit as shown in the book is still valid, but only on the Java edition of the game, because it requires that sticky piston spit out their blocks, which is a Java-only feature (MC-5726). Sticky pistons not doing so on Bedrock is also currently working as intended (MCPE-36986), hence this circuit will not work on Bedrock.
Redstone on the MCPE/Bedrock Edition couldn't even be placed on the ground until late 2015.
It's ordinary for sticky pistons to do this when powered for a single tick, and is in fact crucial to many designs (I think Mojang has stated that this is considered a feature). You can achieve the same results by placing an ordinary block in that location, and using another repeater and a torch to push power into it.
Oh, I gotcha. In that case I'll close this up, if possible.
Edit: Doesn't seem like I can. Shoot.
Ok, tested for ~4 hours here using a standard ender-ender, with a command block killing all enderman every ~45 seconds. For those interested, the design alternates redstone with repeaters to ensure each piston fires individually. After 4 hours I found a total of 9 (out of 272) pistons that had not retrieved their block, all of which were just the redstone, none with the repeater if that makes sense. What this tells me is that if for some reason the piston is set off for just one block (as WolfieMario says) is setoff for just one tick, it leaves the block, while 99% of the time the pressure plates on mob farms give at least two ticks and thus don't leave the block. Based on this, my initial thinking is that if mobs land just barely on the edge of the pressure plate, they get a single tick and leave the block, otherwise they last long enough the piston retracts.
As far as fixes go, either a player needs to take this into account and use a repeater going into pistons everywhere this happens (and thus 3x the redstone), or some sort of more complex and/or accurate (depending on perspective) timer on the pressure plates. While the latter might be easier in theory for the player, I'm going to switch all of my farms to all repeaters and no single-pieces of redstone to work around this at least for now, despite the cost.
Further input/testing welcome of course...
This is actually not a bug but a 'feature', it is actually meant to be like this.
Do you have a link to an official statement to back that up? It's not even documented on the wiki.
This is intended and is featured in many redstone contraptions. Some call it a T flip flop. Depending on if the pulse is extremely brief, the sticky piston will actually leave the block in place. And it may pull it back on the next activation.
A quick search on youtube shows this being featured
https://www.youtube.com/watch?v=sncm4CoRSJQ
People using it in no way proves that it's intended. In fact,
MC-6099shows that Mojang broke a common form of the mechanism that used it once with a change to circuit timings.MC-11107shows another mechanism also broken by changes to piston timing. So this obviously isn't a particularly protected behavior, one that Mojang has taken steps to preserve despite other changes to the game. I believe they're aware of it, because I vaguely remember seeing one of them comment on it a long time ago. But unless you can find an actual statement from one of the developers claiming that it's an intended feature, then we'll just leave this ticket open until one of them makes a decision about it.Found some info on it. I'm not sure if you will accept it as evidence
http://minecraft.gamepedia.com/Tutorials/Piston_circuits#T-Flip_Flops
They call it the "1-wide Sticky Piston TFF"
"A circuit breaker is used to give a 0.5 ticks pulse to the sticky piston. This makes the sticky piston leave the redstone block, which then provides power to the output. When powered again, the sticky piston will pull the redstone block switching the output off."
http://minecraft.wikia.com/wiki/Redstone_Circuits
"With Beta 1.7.3 operation of the Sticky Pistons was changed. If a sticky piston is activated with a one-tick pulse, it will push or pull a block, but not push and pull it back. This makes it possible to build more compact T flip-flops."
All that shows is that players are aware of the behavior. The wiki is not maintained or moderated by Mojang, and thus cannot be considered a statement of intent by them. Only a statement made by one of the developers, such as a tweet, comment on the tracker, blog posting, video, forum post, etc. would constitute proof. Or one of them can resolve the ticket themselves. We've been given explicit instructions not to resolve tickets as Works As Intended without proof.
Confirmed for 1.8.2 pre-4. I really hope this is fixed. While bugs like this one and
MC-108can sometimes appear to be useful, leaving them in the game is never a good idea long term, as they will eventually pile up and cause the game to become unplayable.KingSupernova, this "bug" is indeed a feature many many many players use. Removing it would essentially destroy a lot of mechanics.
qmagnet and KingSupernova The ticket has been flagged for review by Mojang to determine if it is an intended (or now desired) feature, it is up to them to make that decision.
Just because a few people use it doesn't mean it should stay in the game. It doesn't make any sense storyline-wise, why would sticky pistons stop being sticky for a moment? And while it can be helpful in some cases, it causes more problems than it solves.
https://xkcd.com/1172/
I can tell you a TON of people use this. TONS. However, no need to continue the conversation.
We will wait for Mojang.
I'm not sure why it affects you anyway. Sticky pistons can work with only sticking with anything more than a tick. Both mechanics work currently. If you'd like to continue this conversation, hit me up on twitter.
It makes perfect sense flavor-wise; a quick pulse pulls so hard it detaches the block, like a fast tug. That said, gameplay is more important than realism, so it doesn't matter if it "makes sense" as long as it's useful. In most cases, if you're getting a 1-tick-pulse into a sticky piston, it's because you're trying to cause this behavior. And it's used a lot, for example as a form of T-flip-flop. So, yeah, I'm glad it's marked as WAI because if it changed, it'd break builds, whereas having it in doesn't break anything.
I edited the ticket for better searchability. This does not change anything about the fact that this behaviour is intended.