/clear [player] [identifier] does not behave correctly for blocks of data values above 0
If you have block that has a data value above 0 (E.g Spruce Planks) and you don't specify a data value in the command (E.g /clear @p planks), then the spruce planks won't be cleared. However, if you have oak planks in your inventory in a slot further over than the spruce, and you run the same command, it will clear the spruce planks but only the spruce planks. You have to run it again for it to clear the oak planks. I've also reproduced the issue with wool and dirt/coarse dirt.
Steps to reproduce:
- Run /clear
- Put spruce planks in your first inventory slot
- Run /clear @p planks
- The planks are not cleared from you inventory
- Place oak planks in your secondary inventory slot
- Run /clear @p planks
- The spruce planks are cleared from your inventory but the oak is not
Linked Issues
Created Issue:
/clear [player] [identifier] does not behave correctly for blocks of data values above 0
If you have block that has a data value above 0 (E.g Spruce Planks) and you don't specify a data value in the command (E.g /clear @p planks), then the spruce planks won't be cleared. However, if you have oak planks in your inventory in a slot further over than the spruce, and you run the same command, it will clear the spruce planks but only the spruce planks. You have to run it again for it to clear the oak planks. I've also reproduced the issue with wool and dirt/coarse dirt.
Steps to reproduce:
- Run /clear
- Put spruce planks in your first inventory slot
- Run /clear @p planks
- The planks are not cleared from you inventory
- Place oak planks in your secondary inventory slot
- Run /clear @p planks
- The spruce planks are cleared from your inventory but the oak is not
relates to
Steps to reproduce
- /clear
- /give @p sapling 1 0
- /give @p sapling 1 1
- /clear @p sapling 1 1
Expected result
You end up with 1 oak sapling in your inventory.
Actual result
You end up with 1 spruce sapling in your inventory.
Analysis
The /clear command has to do 2 things:
(1) Determine that the correct item is in the inventory.
(2) Remove the correct item from the inventory.
The bug here is that after it correctly performs (1) it ignores the [data] argument when doing (2) and removes the first matching item type that it finds. So, in the reproduction steps above,
- If you skip step #3 then the command in step #4 will fail, because (1) works correctly.
- If you run step #3 before step #2 then you will get the expected result and not see the bug, apparently because (2) checks inventory slots in order from first to last.
- If you select the hotbar slot with the spruce sapling after step #3 (i.e. hold the item in the main hand) then you will get the expected result and not see the bug, apparently because (2) always begins with whatever hotbar slot is currently selected (i.e. with the item held in the main hand), then it proceeds through the hotbar and inventory slots.
This bug is similar to issues with /clear that were reported in earlier versions but which I cannot reproduce in the current version: MCPE-86111 and MCPE-47378.
Very weird behavior. I wonder what causes that.
I have also run into this, in another manner; normally you can target every datatype of a block by specifying -1 as the datatype. This now only targets datatype 0. Below is the example command. Give yourself several varieties of concrete, one of which is white, before trying. They should all disappear, but instead only white does.
clear @s concrete -1
This is extremely destructive to worlds and realms using command blocks, as the functionality of targeting every type of a given block is used everywhere. I run two separate realms where the main mechanic was people's ability to protect purchased land. This no longer works with this bug. Unbelievable that this sort of glitch can be introduced; what the hell happened to QA before release?!?!?!
Update 1: It appears that this only affects the clear command. Detect arguments in Execute commands and Replace arguments in Fill commands can target blocks with the -1 datatype.
This was fixed at some point