Sticky Pistons will not drop blocks in some setups.
A sticky piston powered as in the picture below will create less than one tick pulses but the piston still holds on to the block. Powering the repeater to the left causes this. What I would expect to happen is the block to be left in the extended position as it does in nearly every other setup with 1 tick or shorter pulses.
Created Issue:
Sticky Pistons
A sticky piston powered as in the picture below will create less than one tick pulses but the piston still holds on to the block. Powering the repeater to the left causes this.
Sticky Pistons will not drop blocks in some setups.
relates to
relates to
relates to
A sticky piston powered as in the picture below will create less than one tick pulses but the piston still holds on to the block. Powering the repeater to the left causes this. What I would expect to happen is the block to be left in the extended position as it does in nearly every other setup with 1 tick or shorter pulses.
no it's not an issue.
MC-5726has been marked as works as intended and this "bug" has received 1 upvote in 4 years. In fact fixing this bug would break countless contraptions.
People using it in no way proves that it's intended. In fact, MC-6099 shows that Mojang broke a common form of the mechanism that used it once with a change to circuit timings. MC-11107 shows 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.

Confirmed.
Also wanted to know why when you place a sticky piston, a boco in front and a torch on top of the block, the piston pushes and pulls back the block. This was to be a pulse of 1 tick.
Tails, can you explain?
Only Mojang knows.
To whom and how do I ask?
I can explain this.
in 1.4, a block pushed out by a piston will actually stop being there after about 1.5 ticks.
within those 1.5 ticks, there wont be a single update the the dot of redstone behind the block, causing it to stay on for 1.5 ticks. Adding a repeater to the redstone (in 1.5 with another piece of redstone on the end and no block intersections) will cause it to turn off after 1 tick.
In both 1.5, and 1.4, there is another factor for this not being a 1 tick pulse.
if a piston gets unpowered for only 1 tick, it will not extend immediately when the power returns. its still retracting. This causes the block to stay for longer, which makes it a 1.5 tick pulse.
If this is the case, then why does stringing a line of repeaters after the block to the right show a series of 1 on 2 off pulses? Also, the dust is graphically flickering for less than one tick.
Is this still a concern in the latest Minecraft version 14w30c? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.
Still happens in 14w30c
I just want to point out that this is not a bug to start with. It makes total sense. (And it's useful.)
The easiest way to fix it is to attach another piston to the block which when pushed updates the sticky piston.
In earlier versions, the piston would leave the block behind. This was quite useful as a mono stable circuit that only fires once until it gets reset (pulling the block back in). I had a segmented farm setup that took advantage of this nicely. The piston removes its power source the instant it is powered, so it should create a <1 tick pulse and leave the block behind. "Fixing" it by adding another piston isn't very practical in survival and/or compact setups.
Is this still a concern in the current Minecraft version 1.8.1 Prerelease 3 / Launcher version 1.5.3 or later? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.
This is not actually a bug, it's an exception to
MC-5726. IfMC-5726is resolved as WAI, then this will become a legitimate bug, but until then, this is intended behavior.Confirmed in 1.8.2-pre6, but see my previous comment as to why this is invalid.
Invalid? This bug is about more than leaving the block behind or not... The idea here is that in the majority of configurations the pistons will leave blocks behind with a short pulse but in this one it will not. An inconsistency is bad regardless of which outcome was intended.
Agreed. Which is why
MC-5726should 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.Is this still an issue in 1.9 or 1.9.1-pre3?
Yes, this still happens in 1.9.1-pre3. Now that the related piston report is 'works as intended' I believe we can agree this is not intended behavior
To quickly clarify why this bug occurs:
When the piston pushes the block, it does not update directly after. The first update comes from finishing the extension, after 1.5 ticks. Thus, the piston starts its retraction 1.5 ticks after extending, making it not leave the block behind, because for that it needs to extend for less than 1.5 ticks (most often referred to as receiving a 1-tick pulse).
To confirm this, you can have a repeater coming from the redstone dust that powers the piston, which updates the piston (without powering it).
This is not necessarily a bug, we might eventually see what Mojang thinks of it. If it were fixed, many buds would definitely break, such as the sticky piston with a slimeblock and a redstone block bud, or the one with glass and sand on top. Thus I would prefer to see this report's solution also become 'works as intended'. Generally, redstone changes are bad, because they often break many contraptions that rely on current redstone mechanics. This one certainly would break quite a few if it were Fixed.
Is this still an issue in the most recent versions (currently that is 1.10.2, or 16w42a) of Minecraft? If so, please update the affected versions and help us keeping this ticket updated from time to time. If you are the owner/reporter of this ticket, you can modify the affected version(s) yourself.
Cannot reproduce in 18w47b
@Connor Steppie
I can reproduce this in 18w47b.
Please check if that's still an issue for you in the latest 1.15.2 stable release or the latest 1.16 development snapshot.