-
Bug
-
Resolution: Fixed
-
1.16.210.53 Beta, 1.16.200.52 Beta, 1.14.60 Hotfix, 1.16.40 Hotfix, 1.16.201 Hotfix
-
None
-
Confirmed
-
Windows
-
429808
This can be tested by placing a chest, then placing something inside that chest.
Now place another empty chest above the first.
Use the clone command to clone the first chest over the second chest.
"No blocks cloned"
Open second chest and notice the items that were in the first chest are also in the second chest.
No doubt the reason it says failed is because the blocks are identical and the block itself was not actually replaced, even though the "contents" of the block were replaced.
However, I've seen this behavior in the wild when cloning different blocks over each other (hard to reproduce), which breaks the rest of the conditional command block chain. I've resorted to ensuring the clone update is the LAST operation in the chain because of this unreliability, or spitting out a redstone pulse to a repeater, then to redstone and finally to impulse+redstone command blocks. Ugh.
This does the same thing for signs, which makes it difficult to update signs for mini-games because the conditional command block chain halts at the clone operation, even though the sign is updated correctly with the cloned source contents.
IMHO the result should always be a success unless the clone operation is blocked by some other factor, such as placing blocks outside the valid world boundaries. (I'm sure others that have used this behavior on purpose would disagree with me.)
- is duplicated by
-
MCPE-83478 "No blocks cloned" incorrectly showing when cloning a chest onto another chest that are facing the same way but have different contents.
- Resolved
-
MCPE-117146 Cloned command block command output wrong
- Resolved