Minecraft 1.8.9, Minecraft 1.9 Pre-Release 3, Minecraft 1.9 Pre-Release 4, Minecraft 1.9, Minecraft 1.9.1 Pre-Release 1, Minecraft 1.9.1 Pre-Release 2, Minecraft 1.9.1 Pre-Release 3, Minecraft 1.9.1, Minecraft 1.9.2, Minecraft 16w14a, Minecraft 16w15a, Minecraft 16w15b, Minecraft 1.9.3 Pre-Release 1, Minecraft 1.9.3 Pre-Release 2, Minecraft 1.9.3 Pre-Release 3, Minecraft 1.9.3, Minecraft 1.9.4, Minecraft 16w20a, Minecraft 16w21a, Minecraft 16w21b, Minecraft 1.10 Pre-Release 1, Minecraft 1.10 Pre-Release 2, Minecraft 1.10, Minecraft 1.10.1, Minecraft 1.10.2, Minecraft 16w32a, Minecraft 16w32b, Minecraft 16w33a, Minecraft 16w35a, Minecraft 16w36a, Minecraft 16w38a, Minecraft 16w39a, Minecraft 16w39b, Minecraft 16w39c, Minecraft 16w40a, Minecraft 16w41a, Minecraft 16w42a, Minecraft 16w43a, Minecraft 16w44a, Minecraft 1.11 Pre-Release 1, Minecraft 1.11, Minecraft 16w50a, Minecraft 1.11.2, Minecraft 17w06a, Minecraft 17w14a, Minecraft 17w15a, Minecraft 17w16a, Minecraft 17w16b, Minecraft 17w17a, Minecraft 17w17b, Minecraft 17w18a, Minecraft 17w18b, Minecraft 1.12 Pre-Release 1, Minecraft 1.12 Pre-Release 2, Minecraft 1.12 Pre-Release 3, Minecraft 1.12 Pre-Release 4, Minecraft 1.12 Pre-Release 5, Minecraft 1.12 Pre-Release 6, Minecraft 1.12 Pre-Release 7, Minecraft 1.12, Minecraft 1.12.1 Pre-Release 1, Minecraft 1.12.1, Minecraft 1.12.2 Pre-Release 1, Minecraft 1.12.2 Pre-Release 2, Minecraft 1.12.2, Minecraft 17w43a, Minecraft 17w43b
Please read SkylinerW's comment with code analysis
5. The entity has its UUID set to the copied UUID
6. The new merged NBT data is applied to the entity (which then overwrites the UUID)
Step 5 needs to happen after step 6, or the tags need to be stripped explicitly.
In 1.8.x you can not change an entity's UUID by using e.g. this command:
You will get a message in red saying "The data tag did not change."
Also, in 1.8.9 you can accidentially summon 2 entities with the same UUID which can cause harm to your world.
This is not possible in 1.9 snapshots, incl. pre-4 (but I found a way to do that).
In 1.9 pre4 you can change an entity's UUID though which results in "unresponsiveness" of said entity for the duration of your session:
"The entity can not be found."
If you relog, the entity can be found again.
Steps to reproduce
I don't know if it is intended that one can change an entity's UUID at all via entitydata in 1.9 as you couldn't in 1.8, but if it is intended, there's at least said bug that you cannot find such an entity afterwards for the duration of your session.
Due to this bug you can apparently successfully get infinitely many times the same UUID though, which should definitely not be possible.
Steps to reproduce
Now comes the oddity:
The Zombie that is gone (at least not visible), the one whose entitydata got changed, still outputs its data with that changed UUID (output will be only once).
right next to where the Zombie was before (but is not anymore upon relog), and the other, visible, Zombie can't be the reason for the output.
If I run the same at the "leftover", visible, Zombie, it will output its data as well with the exact UUID (output will be only once).
If I run the same with r=2 while standing in the middle between the visible and the "ghost" Zombie, it will output the data with the same UUID twice, as if both Zombies would still be there.
This happens every time, also if I relog, so I guess the world is now corrupted?
You can keep changing the UUID via entitydata as you please, which results in more and more outputs of the same UUID, from those "ghosts".
After you did those steps above, if you run
without any radius, then it will output the data only once.
If you use r=1 at the "ghost" Zombie position or the visible Zombie, it will output each once.
If you run r=2 between them, it will output twice.
Sorry for the frequent changes, my cat ran over my keyboard and deleted text, saw it afterwards