I used a lot of pistons in my friend's Bedrock server to build redstone circuits.
However, when my machine started running, the server became stuttering abnormally.
I've learned from other players that when the Pistons needs to push/pull back, but can't succeed, it tries every Redstone tick until it succeeds. I think this is a glitch (programming flaw).
(Next is my thoughts, please read carefully)
So, I'm thinking. Whether replacing a better detection algorithm can reduce the performance overhead.(This method may work for Java Edition)
When the piston is pushed out or pulled back, the driven block is like a tree. Slime blocks and honey blocks are like trunks and branches, and the blocks that are driven are like leaves.
So, we can build a "moving block tree" and when the piston fails to push or pull back, only check if it can be pushed out or pulled back when the blocks around the "moving block tree" are updated.
Linked issues
is duplicated by 1
Attachments
Comments 3
The video has been uploaded.
And, thank you for your attention and reminder. I found that my idea that when multiple pistons can affect the same block, it can cause more lag.
So I optimized it, combining the game's original algorithm with my ideas.
If multiple pistons can affect the same block, precomputing and caching the block tree may result in higher stuttering.
We no longer precompute and cache block trees. Instead, it is calculated when the piston/viscous piston needs to push or pull the block. If the push or pull is unsuccessful, the block tree is cached. At the same time, when adding a block, only check if the block joins or blocks (or even exists at the same time) the existing surrounding block tree, and recalculates the surrounding block tree when replacing or removing the block.
The supplement proposed here should be able to solve the problem of multiple pistons affecting the same block or several blocks more effectively, and optimize the block tree update logic.
If possible, I will try to show the optimization algorithm in the form of a flowchart (limited by my academic level (1st year of high school), I may not be able to complete this flowchart)
You may be able to add this optimization algorithm to the game as an experimental gameplay to allow other players in the community to test its stability and lag together
I see the effect in your video, but I could not reproduce it when I powered a bank of 1,200 pistons in a single-player world in 1.20.41. Therefore, I do not see an impact that I would consider a bug. This seems to be more an issue of testing the limits of your hardware or giving a suggestion to the developers to optimize the game. We do not accept suggestions through the bug tracker.
Note that visual lag related to block updates in the version you reported this was confirmed at MCPE-173706 and has since been fixed.
You may continue to keep the report updated, if you wish, by adding affected versions, and I will leave this report for others to consider.
Please attach a video showing the issue or world save that can be used to recreate the issue.
The description of a report should focus on precise steps that would allow the developers to reproduce what you are seeing. I agree that pistons seem more laggy in 1.20, but that is not enough information to confirm a bug.
(In my experience the increased lag surrounding pistons in 1.20 is client-sided and causes delayed or skipped visual block updates but does not much affect server-side block updates until it gets so bad that the client can't communicate with the server properly.)
Just for concision, I understand your suggestion for optimizing piston/moving block lag to be this:
That's actually how the redstone system in Bedrock works, and why it is so much less laggy than redstone in Java Edition. I don't know how helpful that would be for potential moving blocks, especially where more that one piston can affect the same block. Currently randomizing tile entity update order sorts out conflicts.