[MCPE-15476] Stuck pistons stay stuck forever Created: 15/Jun/16  Updated: 23/Jan/17  Resolved: 20/Jul/16

Status: Resolved
Project: Minecraft (Bedrock codebase)
Component/s: None
Affects Version/s: 0.15.1 Beta 1, 0.15.1, 0.15.2
Fix Version/s: 0.15.3

Type: Bug
Reporter: Azelef
Resolution: Fixed Votes: 2
Labels: None

Attachments: PNG File Screenshot_2016-06-15-15-05-24.png    
Issue Links:
Duplicate
is duplicated by MCPE-14632 Piston power Resolved
is duplicated by MCPE-15606 Powered piston not extending if it wa... Resolved
is duplicated by MCPE-16134 Piston Block Pushing Limit Bug Resolved
Relates
relates to MCPE-15606 Powered piston not extending if it wa... Resolved
relates to MCPE-15607 Pistons take 3 redstone ticks to exte... Resolved
Confirmation Status: Unconfirmed
Platform: Android

 Description   

Steps to reproduce :
-Power a piston while it is stuck, then remove the block that blocked it
OR
-Build this flying machine

What I expected to happen :
-Since nothing blocks the piston and it is powered, it should extend

What would happen in PC edition (probably unintended)
-The piston would stay stuck until receiving a block update

What happened :
-There's no way to extend the piston without removing the redstone block

Maybe this is intended, but it is :
-Very bug-like
-Not QC
-Super annoying for flying machines (worse than the removal of QC)

A theoretical way to update unstuck pistons without slow useless updates :
-When a piston is stuck, go to the block or blocks that blocked it (up to 12 blocks) and those blocks "remember" they blocked the piston
-When a block changes, it looks at the list of pistons it blocked and updates them.



 Comments   
Comment by Vincent Vermilya [ 20/Jul/16 ]

Thanks for typing all that out, the only thing I'm waiting for now is Microsoft to distribute the patch. My piston stone generator doesn't rely on things happening at the exact same time, so I'm good.

Comment by [Mojang] Tomas Alaeus [ 20/Jul/16 ]

Previously we had some code in place that tried to optimize this so it didn't have to recheck all the time, but that was apparently a bit broken (it's hard to do without cluttering down everything). The fix was just to remove that optimization. Now if a piston got power, it will check the push conditions every tick (redstone tick) regardless if it could do it before or not. It will require more performance on the host/server, but that's something we have to live with until we can provide an optimization that's bug free.

Randomness: This fix had nothing to do with randomess. However, pistons (and all other ticking block entities like hoppers) do depend on their ticking order (if two pistons push the same block from different angles in the exact same tick, only the first ticked will activate). In 0.15.2 this order was undefined*, while now it's randomized every tick. We've had many discussions here around how to make the order stable and dependable, but we haven't got to any conclusion yet. In the meantime, it's random so no one can depend on any order.

*) Undefined order
In technical terms all block entities are stored in a non-ordered hashmap per chunk. When playing and no block entities are placed, the order would be stable (meaning it's the same order every tick). However, when placing new block entities in the same chunk the hashmap sometimes needs to grow when it's getting full (this depends on the platform, in the development platform it grows when it reaches 64 block entities). When it grows all entries in it will be shuffled, and thus the order will change.

They were generally ticked in the same order that they were placed (up until the hashmap had to grow). This meant that users could start to depend on it, and then get frustrated when the order suddenly changed if they placed too many in the same chunk. With the added randomness in the ticking order, users have to make machines that work with any ticking order (delay one of the pistons with 1 tick). Those machines will not break regardless of the amount of block entities added, and they will not break if we later figure out a way to order them properly.

Comment by Azelef [ 20/Jul/16 ]

Yep. I wonder how the fix was implemented, because it is lag free, but seems to have some degree of randomness (or maybe pistons are inherently random).

Comment by ItsPlantseed [ 20/Jul/16 ]

This was fixed in 0.15.3.

Comment by Azelef [ 13/Jul/16 ]

Of course ! Due to MCPE-14769, I have tons of villagers in the ocean, in my base, and in every place where NPCs aren't supposed to go. Thers are like 40 NPCs reafy to be sacrificed. Once the fix is added to an actual version.

I have a testworld with my reported bugs to see if they are still in every version, but updating every report one by one is quite tedious, so I only do it when asked to.

Comment by Vincent Vermilya [ 13/Jul/16 ]

Do you accept human sacrifices? In all seriousness, why has this taken so long? Will we see it next update? And thanks for fixing this.
Edit: Affects 15.2 would be good to add.

Comment by PHO [ 13/Jul/16 ]

Maybe a Mojangle temple?

Comment by Azelef [ 22/Jun/16 ]

One of the bugs I reported got fixed ! I found faith. Where do I convert to Mojangism ?

Comment by [Mojang] Tomas Alaeus [ 22/Jun/16 ]

Bah, non-believer! I pushed a fix for it ~4 hours after the comment.

Comment by Azelef [ 21/Jun/16 ]

Yay, a direct answer from a developer (I bet you aren't the developer who will have to fix it )!

Comment by [Mojang] Tomas Alaeus [ 21/Jun/16 ]

Confirmed a bug.

Azelef: There you go.

Comment by Azelef [ 20/Jun/16 ]

Agreed. @PlantSeed : "This has been confirmed by a developer that it's a bug, not an intended behavior." Where ?

Comment by PHO [ 20/Jun/16 ]

I think this is the same bug as MCPE-15606.

Generated at Sat Jan 11 15:07:49 UTC 2025 using Jira 9.12.2#9120002-sha1:301bf498dd45d800842af0b84230f1bb58606c13.