The bug
In the game there are so called "random ticks" that make crops grow, copper oxidize, cauldrons to fill up, amethyst shards to grow, etc. However, there is a bug in the game that discards half of the random ticks in the world, thus resulting in slower growth of crops, making copper oxidize slower, and cauldrons taking longer to fill up. Code digging confirming this issue has been published here: https://twitter.com/fragmites/status/1450965142045278214?s=20
If this issue is fixed, it may also fix other issues that involve random ticks, some of which are described in the reports linked as “relates to” below.
Steps to reproduce
Step 1: Make this setup of dripstone and 10 cauldrons:
or use the provided world download:
Step 2: Wait 13 minutes
(Note: Randomtickspeed must be set to the default:
Bedrock: 1
Java: 3)
Step 3: Count how many cauldrons are completely filled
Step 4: Repeat it multiple times and also compare this to Java Edition as well
Expected result
About 50% of all the cauldrons are filled, like how it is proposed in Java
Observed result
About 20% of all the cauldrons are filled
Notes
Even though Bedrock has randomtickspeed 1 compared to that of Java with randomtickspeed 3. Bedrock should randomly tick 2.5 blocks per gametick and 3 blocks on Java edition, however on Bedrock edition they tick 1.25 blocks per gametick because of a bug. See the code analysis by Rufus provided by the Twitter link as well as the comment below this bugreport: https://bugs.mojang.com/browse/MCPE-145612?focusedCommentId=1094552&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-1094552
Linked issues
is duplicated by 3
relates to 2
Attachments
Comments 5
The comparison needs to be made at the default tick speed in each version because this is a parity bug. According to the code-digging in the linked tweet
Bedrock's random ticking mechanic has an internal multiplier, and
the chance of cauldron filling is only slightly different than in Java because it accounts for the internal multiplier in order to achieve outcome parity at the vanilla/default tick speed settings.
So the expected result is that at default random tick speed the cauldrons would fill at the same rate.
Here are a few pictures taken from Bedrock Edition and Java respectively.
The first two are Bedrock:
https://cdn.discordapp.com/attachments/711018807019307040/899814669903085568/Minecraft_2021_10_19_8_53_10.png
https://cdn.discordapp.com/attachments/711018807019307040/899814688756494387/Minecraft_2021_10_19_8_53_16.png
The next two are Java:
https://cdn.discordapp.com/attachments/711018807019307040/899814824408653895/81.png
https://cdn.discordapp.com/attachments/711018807019307040/899814844885241866/82.png
Both tests were conducted on exactly similar setups:
16x16 cauldrons, 16x16 pointed dripstones, 16x16 lava blocks.
Default Random Tick speed.
Chunk aligned to prevent luck swings.
Same computer, no particularly heavy background load.
They were both conducted for exactly 13 minutes, starting with unticked empty cauldrons. At the end of the test, the setup was reset and all the lava cauldrons were replaced with empty cauldrons.
The fill/replace command output clearly shows that only 75 cauldrons had been filled in Bedrock Edition (expected = ~124), vs 124 (expected =~124) in Java.
This issue affects my realm, and inhibits progress! Many things are affected, like copper not oxidizing, glowberries not growing, and dripstone not growing! Realms are also plagued with lag, and this might affect the tick rate! it has been years that our online multiplayer realms have had immense lag and it has never been fixed! It is widely known the lag is a problem, and has been an issue for years! Combine constant lag on realms and multiplayer worlds, with a coding error that causes ticks to be discarded, and you will have over 50% of ticks being lost and can entirely inhibit any progress being made!
Code Analysis
In `Level::tickBlocks()` the game uses signed integer arithmetic to generate the positions of random blocks to tick in a chunk. As a result, the random y level is negative 50% of the time, and BE selects a random block of air underneath the chunk instead of a block in the chunk. This causes the observed loss of 50% of random ticks.
A Proposed Fix
Use unsigned integer arithmetic to generate the positions of random blocks.