It has been reported that /clone also clones blocks even if there are no changes to be made (You clone a cube to the location of a simulair cube and it still replaces everything, for example). BUT now I noticed that when doing so by with redstone, repeaters and all other blocks that need another block in the proximity will be dropped as Items on the ground. Very annoying of course.
To be clear, it's the old redstone that is being dropped (not the ones that are getting cloned) since you still see redstone placed where it should be.
Screenshots and more explanation:
http://imgur.com/a/CRxF6
Comments 5
Is this still an issue in the current Minecraft Snapshot 15w46a or later? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.
Ticket resolved as incomplete, because no answer in a reasonable amount of time (1+ year), if it still happens, please update the ticket.
Requesting to re-open this issue. As of version 1.19 release, this is still an issue. Specific details:
When cloning a region (with move), certain attached items get destroyed and drop as items (or drop their contents, in the case of chests) at the original location. The blocks are still cloned successfully at the target location. That is, for example, chests get re-created at the target with their contents intact – but the contents also drop at the original location. In effect, it creates duplicates. This also happens with doors, beds, etc. They get cloned, but also drop as items in the original location (I assume because the supporting/attached blocks are now destroyed).
My guess is that when the clone command executes, it creates a copy of the cloned blocks at the target location, then destroys the blocks at the source location. But instead of complete destruction, including contents of chests, or attached/supported items, the code treats it like the player destroyed the item. Thus, it executes the code to drop container contents, drop supported/attached items (torches, signs, etc), and so on. This is likely due to block update mechanics.
What should happen is that the code for destroying each block should first check any attached/supported/contained items, and destroy them before destroying itself.
I have also noted similar behavior when using something like "fill ~1 ~1 ~ ~1 ~2 ~ minecraft:oak_door[facing=north,hinge=right]". Instead of properly filling the lower and upper halfs, it fills the incorrect half(s) and immediate drops as an item on the next block update.
This also occurs when "clearing" an area, such as "fill ~ ~ ~ ~8 ~8 ~8 minecraft:air replace". Blocks such as doors, containers, signs, etc, all drop as items when their respective supporting/attached/containing blocks are replaced with air. That is, it acts nearly the same as if the final part of the command was "destroy" instead of "replace".
Are you using /clone x1 y1 z1 x2 y2 z2 x3 y3 z3 destroy ?
If you are, Works as intended, setblock does the same.
If you aren't, update description with EXACT command.