Blocks moved by pistons, also known as moving blocks, are immovable. Once the moving blocks get to their desired destination, they become a regular block again, and are movable. This is where the problem occurs. Sometimes the block can be moved again 2 gameticks (1 redstone tick) after the first piston moves the block, other times it takes 4 gameticks (2 redstone ticks) after the first piston moves the block, and if powered with a short redstone pulse, there is a random chance that the block does not get moved at all.
How to reproduce:
1. Place a normal piston (henceforth known as the first piston) and a block in front of the first piston. Then place another piston 2 blocks away with a 1 block offset (henceforth known as the second piston). The second piston will be facing into the area where the block is pushed to, not where the block already is. Build all of this within the same chunk. If you are confused how to build this, copy Example 1.png in attachments. Another setup that will produce the same result is Example 4.png.
2. Put a repeater on 1 redstone tick of delay facing into the second piston.
3. Put a block next to the first piston and the repeater, then place an observer behind this block.
4. Update the observer.
Observed Results:
The block will randomly either be pushed or not pushed by the second piston.
Expected Result:
The block will always be pushed by the second piston.
Linked issues
is duplicated by 1
relates to 2
Attachments
Comments 8
MCPE-15793 Is mostly related on how levers and other producers are affected by the player, because they activate in the 2nd half of a redstone tick (2nd gametick) instead of the 1st half of the redstone tick. Therefor repeaters (producers) activate the same tick as the pistons (consumers), because it takes 1 redstone tick extra to delay the piston with the redstone dust (because its in the 2nd gametick of the previous redstone tick) and the repeater already gets powered in the 2nd gametick so it takes one redstone tick to power, because redstone repeaters have naturally 1 tick delay, resulting in them both activating at the same time.
My point is that that bug is related to activating a producer rather than pistons and moving blocks themself. I want to make sure that everyone knows the difference.
This bug is mostly about moving blocks becoming a block taking either 1 redstone tick or 2 unreliable. If it becomes 1 redstone tick, a lot of redstone contraptions would be faster and less unreliable (instead having to delay each piston with 2 redstone ticks, rather than one)
In an ideal world where this issue and MCPE-15793 are both fixed, we would be splitting game ticks into two kinds: we call even game ticks as Observation Ticks, and odd game ticks as Action Ticks (or vice versa). There would be two strict rules that no redstone components can ever violate: Producers must not change their output state in observation ticks, and Consumers must not observe producers in action ticks.
Repeaters should observe inputs in observation ticks, and change their state in action ticks.
Observers should compare state changes in observation ticks, and possibly produce a pulse in action ticks. In observation ticks they should compare the state of their target block against the last state in the previous observation tick.
If switches (such as levers) are interacted in an observation tick, they should defer changing their state until the next action tick.
Pistons are tricky. They should observe inputs in observation ticks, and should also turn regular blocks into
movingBlockin the same tick. This transformation should not count as a state change, that is, the recalculation of the producer/consumer network should not happen at this time. In action ticks they should turnmovingBlockinto regular blocks, and trigger the recalculation of the network.If a block is placed or removed by any other means than pistons, and if that happened in an observation tick, the game should defer recalculating the network until the next action tick.
If observers themselves are moved (in an action tick), they should schedule a pulse for the next action tick. That is, they should output a high signal in the next action tick, and output a low signal after the next.
With these rules in mind, we can see that the example 1 will work as expected. At t=0 (observation) the observer detects a state change of the right side repeater. At t=1 (action) it turns on. At t=2 (o) the right side piston places a movingBlock in front of the left side piston, replaces the iron with a moving piston head, and the left side repeater schedules for turning on. At t=3 (a) the right side piston replaces the movingBlock with iron, replaces the moving piston head with a static one, the observer turns off, and the left side repeater turns on. At t=4 (o) the left side piston starts pushing the iron. At t=5 (a) the piston finishes pushing it.
To prevent the moving block from being movable in gametick 4, in the proposed action-observation tick system, there could be a pseudo update order created for moving blocks, where a moving block always updates before a piston does, which would allow the movingBlock to be pushed reliably on gametick 2. Also MCPE-15793 is similar behavior to the java "player input bug" that was marked Won't Fix, there is currently another bug report about the "player input bug" that is still unresolved, but the initial one was Won't Fix. So this bug is java parity. Also, could MCPE-15793 bug not be fixed by action ticks being every tick, almost like the redstone system in java, instead of an action-observation tick system.
Thank you for your report!
However, this issue has been temporarily closed as Awaiting Response
Is this still an issue in the latest version? If so, please make sure the ticket description contains the following information:
Steps to Reproduce:
1.
2.
3.Observed Results:
(Briefly describe what happens)Expected Results:
(Briefly describe what should happen)
If your ticket does not look like the example given here, then it's likely to be closed as incomplete.
This ticket will automatically reopen when you reply.
Quick Links:
📓 Issue Guidelines – 💬 Mojang Support – 📧 Suggestions – 📖 Minecraft Wiki
Based on my own testing of the issue, it seems that the moving block is controlled by the piston that moved it. (Discovered by cloning the moving block somewhere else while being moved. It doesn't revert to a regular block when movement finishes, and extending/retracting the piston that created it causes it to move, no matter how far away it is. Destroying the piston causes it to revert to a regular block where it should have reverted to earlier.)
Based on that, I think that what is actually occurring here is that the reverting of the moving block is done during the step of updating the piston that moved it, so the issue is the same as MCPE-16371. The solution here is to have pistons finishing movement always updated before pistons starting movement. There is already a feedback suggestion on that fix.
Interestingly, I have actually managed to implement this fix using commands, by destroying and then replacing the piston midway through movement, which makes the moving blocks revert faster than they are supposed to. This also provides more evidence that the moving blocks are controlled by the piston that created them.
Confirmed on 1.16.50 / iOS. I think this is partly due to MCPE-16371. That is, the transformation from a moving block to a regular block occurs after 2 game ticks rather than immediately, so there is a chance that the second piston is ticked before the moving block, in which case the second piston fails to push it again. However, although the ticking order being randomized is an intentional behavior, a moving block taking 2 game ticks to transform back to a regular one, is a questionable bahavior. I don't think this is actually intended. If it only took 1 game tick, then this problem would not occur.
Also MCPE-15793 partly relates to this, whose root cause is the fact that redstone components observe inputs and determine outputs in the same game tick (every 2 game ticks). The very reason why there should be such a thing as redstone tick is so that they can process inputs and outputs in separate ticks to prevent this kind of problems.