MCPE-187016Flattened IDs retain block states from the unflattened ID that should have been removed
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.
Created Issue:
Flattened IDs retain block states from the unflattened ID that should have been removed
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.)
Attachments2
- Unresolved
- Open
- Unconfirmed
- Multiple
- Android 14, Windows 11
- 1.21.30
blockstate-commands.mp4
![[Mod] Jarl-Penguin](../../../data/avatars/users/92849.png){kind=small}
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.
![[MCQA] Bartłomiej Słodkowski](../../../data/avatars/users/18941.svg){kind=small}
![[MCPE Mod] Celesian](../../../data/avatars/users/81635.png){kind=small}
Can confirm. I was able to reproduce with the following command in 1.21.41:
/setblock ~ ~ ~ purple_wool["color"="black"]
This placed Black Wool, which should not have happened.
Also, it is worth mentioning that these blockstates do not appear in the command suggestion list. You must type them manually, but they do work.