Steps to reproduce
Place a sticky piston facing a chunk border, so that it will extend across the chunk border.
Attach a clock circuit to the sticky piston, and place a block on its face so that it pushes the block back and force.
After a period of time, force-close or crash the game.
Expected result
The setup is as you left it.
Actual result
The setup sometimes breaks, with a standalone moving block that is not moved by the sticky piston, or the piston head overlapping the block it was pushing, or the piston stuck and unable to extend into seemingly empty space where a wireframe show when you point at the piston as in the thumbnail below.
[media]
This is an incredibly strange bug, knowing how chunk data is stored within the game.
Long story short, I have a world containing a fully automatic chicken farm, using what is known as an Ethos Hopper Clock, which is a form of redstone clock that uses items moving between two hoppers as precise timing, a redstone block on top to power one of the two hoppers, observers on the sides, and pistons to push the redstone block side to side to create an update for an observer block to use to power an output.
Now, the bug.
Somehow, and I have no idea how this happened as I noticed it after my chicken farm stopped producing food for a while, the piston arm, and the redstone block used in the design, ended up occupying the exact same space. Neither the piston arm, nor the block, were in their moving block entity form, and were fully solid, interactive blocks. This seems to be a rare bug, and I can only theorize it to have been caused by the chunk unloading at the very moment the piston began moving, either by quitting the world and reopening it, or by traveling away and unloading the chunk via simulation distance.
This bug may be very difficult to reproduce as a result of the incredibly precise timing in my theory, but if any other method is found, hopefully it'll be fixable, as I can imagine this could potentially break many sensitive redstone designs that require precise timings.
In the screenshot provided, you can see that the piston is in it's extended state, with the redstone block directly in front of it. I had to time my screenshot so that the Z-Fighting of the piston arm and the redstone block could be seen, to confirm the piston arm wasn't simply overwritten by the redstone block. It should also be noted that breaking the block that's occupying the space that the arm is in will result in the piston being completely deleted, not even dropping as an item, futher confirming that neither block was in it's moving entity state.
Linked issues
is duplicated by
Attachments
Comments
GoldenHelmet
Gamershy
Apologies for the late response, GoldenHelmet, hadn't checked here for a while. The piston's position is 764, 65, 47 while the redstone block is at 764, 65, 48. After doing a bit of math, it appears that neither block is moving into a chunk border, however, the piston came out to 2.937, which means it is against the border, but pushes away from it.
GoldenHelmet
In the positive X and Z directions you have to account for 0 being a coordinate, so you would need to add 1 before dividing by 16 to check. The chunks spans are like this:
-64 to -49
-48 to -33
-32 to -17
-16 to -1
0 to 15
16 to 31
32 to 47
48 to 63
So your piston and redstone block are in separate chunks, and it’s likely the piston extending while the chunk with the red stone block is unloaded that causes the overlap.
Gamershy
Ahhh, my bad, didn't think about that. Then yes, that confirms that it's yet another chunk border issues. Seems Bedrock seriously struggles with chunk borders, I wonder if it's in the dev's plans to rework the chunk save/load system at some point.
[Mojang] Mega_Spud (Jay)
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 add a comment or update the affected version field.
To make your bug report as effective as possible, please try and include the following steps to reproduce the problem:
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
Gamershy
I'm unsure if this issue still occurs given its extremely specific circumstances, but I've been watching for it. I recently built a new auto chicken farm in a new world, so my personal testing is ready to begin again
Gamershy
Oh wow, I actually forgot this bug even existed after all this time. Guess it's finally happened enough to be considered an actual issue.
migrated
It is a strange glitch, that much is undeniable, agreed.
I didn't experience this in Java edition so this one is new to me, but it appears to be related to a chunk border issue
I could try moving my piston contraption to a different part of the same chunk to see if that helps, I'll have to find some extra space in my build for it, not a big problem,
With people like myself without any knowledge on how programming actually works, it would be hard for me to find where a chunk border is, I guess I should look it up,
I know each chunk represents 16 x 16 blocks and its visibility is affected by render distance, ticking radius is separate, that's all I know of it, beyond those basic things, so I would not
know where to start in finding where a chunk border actually exists at, unless chunks generate by a multiple of 16 blocks from exactly 0 coordinate, if not,
then I'll have to do some research.
Your speculations about how this can happen sound plausible, and in the case shown in the picture it's no doubt because either the two hoppers (and the spaces above them), or the piston and its extended arm, cross the Z = 47 to Z = 48 chunk border. Could you clarify where the chunk border is?