The bug
When using /setblock or /fill to replace a block entity, this keeps the old NBT (if no NBT is specified), but clears the inventories, even if the command fails.
Additionally, the command will fail if the specified block state matches the existing one, even if there is new NBT to apply. The result is only inventories clearing.
How to reproduce
Example 1:
/setblock ~1 ~ ~ dropper[facing=up]{CustomName:"\"first\"",Items:[{id:stone,Count:1b,Slot:0b}]}This places a dropper as expected. Now run the following command:
/setblock ~1 ~ ~ dropper[facing=up]{CustomName:"\"updated\"",Items:[{id:stone,Count:1b,Slot:0b}]}Expected behavior: command succeeds (because NBT differs), dropper updates name.
Actual behavior: command fails (because the blockstates are the same), dropper does not update name, inventory clear.
Note: Leaving off the NBT in the last command has the same effect.
Example 2:
/setblock ~1 ~ ~ command_block[facing=up]{Command:"first"}This places a command block as expected. Now run the following command:
/setblock ~1 ~ ~ command_block[facing=down]Expected behavior: command block is empty
Actual behavior: command block contains the command "first".
Note: including NBT in the last command successfully places a new block as expected.
Linked issues
is duplicated by 12
MC-118677
Return "No block filled" when try to empty chest with /fill command
Resolved
MC-119249
setblock replace not working for mob_spawners
Resolved
MC-119806
Skulls bug
Resolved
MC-119826
Cannot setblock a sign on the position of another sign
Resolved
MC-120438
Signs don't replace signs
Resolved
relates to 2
Comments 33
Hey @Bertie2011, we did some testing and I rewrote your report to be more detailed. Hope you don't mind!
@tryashtar
No, I don't mind. I didn't have much time to test things out, thanks for expanding my post =)
Could be related to MC-50166 since replacing all blocks with air / barrier blocks first was likely done to remove tile entities.
It seems like this issue doesn't necessarily have anything to do with inventories. What happens is that the target block just gets "cleared" of data, and simply not (re)populated with the specified NBT.
As if replacing a block with differing NBT is interpreted as invalid data for the block and just forced erased upon replace.
I've had the same problem with lecterns, and no matter how much I replaced the block with air and then put in the new lecternwithnbt, the new lectern has the old NBTs. (although in the meantime I've put in a block of air to 'clear').
And 1.20 last pre realase.
The first example is fixed in 25w02a, and the second example is now intended, per these changes in the changelog:
If the block entity data is not specified, and the existing block has data, the block entity data will be preserved
If the block entity data is specified, the block entity data will be set to the specified value
To clear the block entity data explicitly, you must now specify the block entity data as {}
The operation is now successful if either the block state changed or the block entity data changed
The bug seems to completely erase the nbt data of the block, to reprodice simply put this command in a command block and run it twice.
The first time the command is run there will be a stone block in the dropper and the second time the dropper will be empty.