MCPE-52979Button powering duration is inconsistent
I noticed that the buttons are very unstable with respect to the runtime in the bedrock:
They emit a charge above or below (19 to 21 for stone buttons, 29 to 31 for wood buttons) at random. They rarely execute the exact value of ticks (which is 20 for stone buttons and 30 for wooden buttons).
To analyze the existence of this error, I compared the execution time of the two types of buttons (stone and wood) in Java and Bedrock. To do this, I used a command_block in two situations on both platforms:
- FIRST SITUATION:
1) I put command block in repeat mode, requiring redstone, and used the command "/ say a";
2) I put a type of button (suppose stone) and pressed once;
3) I counted each of the command lines manually.
- In Java, totaled exactly 20 ticks in all tests.
- In Bedrock, they totaled values between 19 and 21, which caused misalignment in succession tests.
- SECOND SITUATION:
1) I created a chat goal with "/ scoreboard add add Bug dummy";
2) I put in the command block: "/ scoreboard add @p Bug 1";
3) I put one of the button types (suppose wood this time) and pressed it once.
- In Java, there was an exact score of 30 ticks.
- In Bedrock, as well as in stone buttons, there was a range of 29 to 31 ticks, damaging, as is supposed, the following tests.
Still with the same error, this made some attempts to run very complex redstone circuits difficult, as noted in ticket MCPE-15793.
This error causes a number of breaks in Minecraft Bedrock's redstone, which is perhaps the most damaging to engineers.
![[Mod] GoldenHelmet](../../../data/avatars/users/18951.svg){kind=small}
Created Issue:
Button loading tick anomaly
I noticed that the buttons are very unstable with respect to the runtime in the bedrock:
They emit a charge above or below (19 to 21 for stone buttons, 29 to 31 for wood buttons) at random. They rarely execute the exact value of ticks (which is 20 for stone buttons and 30 for wooden buttons).To analyze the existence of this error, I compared the execution time of the two types of buttons (stone and wood) in Java and Bedrock. To do this, I used a command_block in two situations on both platforms:
- FIRST SITUATION:
1) I put command block in repeat mode, requiring redstone, and used the command "/ say a";
2) I put a type of button (suppose stone) and pressed once;
3) I counted each of the command lines manually.
- In Java, totaled exactly 20 ticks in all tests.
- In Bedrock, they totaled values between 19 and 21, which caused misalignment in succession tests.
- SECOND SITUATION:
1) I created a chat goal with "/ scoreboard add add Bug dummy";
2) I put in the command block: "/ scoreboard add @p Bug 1";
3) I put one of the button types (suppose wood this time) and pressed it once.
- In Java, there was an exact score of 30 ticks.
- In Bedrock, as well as in stone buttons, there was a range of 29 to 31 ticks, damaging, as is supposed, the following tests.
Still with the same error, this made some attempts to run very complex redstone circuits difficult, as noted in ticket MCPE-15793.
This error causes a number of breaks in Minecraft Bedrock's redstone, which is perhaps the most damaging to engineers.
Buttonloading tickanomalyButton powering duration varies randomly
Button powering durationvaries randomlyButton powering duration is inconsistent
![[MCQA] v-weszaj](../../../data/avatars/users/18941.svg){kind=small}
![[Mojang] Mega_Spud (Jay Wells)](../../../data/avatars/users/92696.png){kind=small}
![[Bot] Arisa](../../../data/avatars/users/43007.png){kind=small}
relates to
relates to
Does it work if you use a wooden button, or remove the one-tick repeater from the activation line?
I think this is a case of MCPE-15793, and the extra repeater between upper and lower buttons accounts for the difference in behavior. MCPE-52979 may also be a factor here.
I forget what I was doing to find this issue, but I've seen this as well on Windows 10. The buttons on Windows 10 are always +/-1 for tick length, never correct. I thought I was losing my mind, so I first set up a repeater row with locking to test it, and each button press gets a different distance down the chain - 14-15 for wooden buttons, 9-10 for stone. Since I typically time all of my circuits in other ways, this hasn't had any terrible effect on any of my redstone contraptions, but it's definitely going to be frustrating if I do need to time something from a button press.
Confirmed in 1.14.60 using a command block setup similar to the one described above.
Updated title to try to make it more clear.
This is still an issue in the latest version (1.16.201)
I reproduced this with the second situation described in the bug report:
Steps to reproduce:
Observed Result:
The player gets either 19 or 21 points from a stone button and either 29 or 31 points from a wooden button.
Expected Result:
The player gets 20 points from a stone button and 30 points from a wooden button.
Still an issue in 1.17.30. Button Timing Demo.mcworld
can be used to test the bug.