VoicefulBread66
- VoicefulBread66
- voicefulbread66
- Asia/Singapore
- Yes
- No
REALMS-3367
MCPE-180398MCPE-187016
This issue is present on my device, which has an Arm Mali-G57 MC2 GPU.
blockstate-commands.mp4
The developers retained the ability to use the unflattened IDs for backwards compatibility. However, this seems to have been implemented incorrectly, resulting in the new flattened IDs retaining the old block states, including in flattened IDs that do not share the same name as an unflattened ID, although they do not show up in autocomplete unless the property is typed in. (e.g. the "color" block state being retained in purple_wool).
For example, one can type in /setblock ~ ~ ~ purple_wool ["color"="black"], which would result in the game placing black wool. (It places it with the correct ID for black wool, black_wool
, but this should not be possible in the first place.)The developers retained the ability to use the unflattened IDs for backwards compatibility. However, this seems to have been implemented incorrectly, resulting in the new flattened IDs retaining the old block states, including in flattened IDs that do not share the same name as an unflattened ID, although they do not show up in autocomplete unless the property is typed in. (e.g. the "color" block state being retained in purple_wool).
For example, one can type in /setblock ~ ~ ~ purple_wool ["color"="black"], which would result in the game placing black wool. (It places it with the correct ID for black wool, black_wool (as shown by /testforblock [x y z] purple_wool), but this should not be possible in the first place.)
In addition, testing any flattened block with the /testforblock command also has this issue. Using the black wool example again, /testforblock [x y z] purple_wool ["color"="black"] on Black Wool will return that the block has been found, even if it is normally placed black wool.
Despite the flattening of Mushroom Stems into their own distinct block, mushroom_stem, red_mushroom_block ["huge_mushroom_bits"=15] and brown_mushroom_block ["huge_mushroom_bits"=15] still exist as distinct blocks.
This can be seen by how doing /setblock [x y z] red_mushroom_block ["huge_mushroom_bits"=15] followed by /testforblock [x y z] mushroom_stem shows that the game views the block placed as a Red Mushroom Block, and not a Mushroom Stem. The same applies for Brown Mushroom Block with the state set to 15. Per how blocks have been flattened, using the old syntax should convert them to mushroom_stem.
In addition, the new mushroom_stem block has an unused huge_mushroom_bits block state that serves no function, yet continues to not just
workwithout the game throwing an error, but in fact be suggested after typing in /setblock [x y z] mushroom_stem [Despite the flattening of Mushroom Stems into their own distinct block, mushroom_stem, red_mushroom_block ["huge_mushroom_bits"=15] and brown_mushroom_block ["huge_mushroom_bits"=15] still exist as distinct blocks.
This can be seen by how doing /setblock [x y z] red_mushroom_block ["huge_mushroom_bits"=15] followed by /testforblock [x y z] mushroom_stem shows that the game views the block placed as a Red Mushroom Block, and not a Mushroom Stem. The same applies for Brown Mushroom Block with the state set to 15. Per how blocks have been flattened, using the old syntax should convert them to mushroom_stem.
In addition, the new mushroom_stem block has an unused huge_mushroom_bits block state that serves no function, yet continues to not just be allowed in commands without the game throwing an error, but in fact be suggested after typing in /setblock [x y z] mushroom_stem [
Despite the flattening of Mushroom Stems into their own distinct block, mushroom_stem, red_mushroom_block ["huge_mushroom_bits"=15] and brown_mushroom_block ["huge_mushroom_bits"=15] still exist as distinct blocks.
This can be seen by how doing /setblock [x y z] red_mushroom_block ["huge_mushroom_bits"=15] followed by /testforblock [x y z] mushroom_stem shows that the game views the block placed as a Red Mushroom Block, and not a Mushroom Stem. The same applies for Brown Mushroom Block with the state set to 15. Per how blocks have been flattened, using the old syntax should convert them to mushroom_stem.
In addition, the new mushroom_stem block has an unused huge_mushroom_bits block state that serves no function, yet continues to not just be allowed in commands without the game throwing an error, but in fact be suggested after typing in /setblock [x y z] mushroom_stem [ into the text box.
I've only had this issue with Potatoes (not Baked), Sweet Berries and Carrots.
Beetroot and Melon seem to have worked consistently.
This issue randomly pops up as and when for all members of the Realm when it happens.
Also found this on my realm, but found it worked in non-realms too.
It also happens on Bedrock with Android 9.
Attached below is my experience on Android.
VID_20200519151614.mp4
Also in 1.16.40 Hotfix and on Android.
May be related to
MCPE-98305.This should be reopened as a Java Parity issue as on Java Edition, the temple structure is split into stronghold, desert_pyramid, igloo, jungle_pyramid and swamp_hut.
Affects 1.20.41
I can confirm that this is an issue on my device (POCO M5, 4/64, with Mali-G57 MC2 GPU), and that it is still present in 1.20.41.