MC-98244Same UUID infinite times possible + changing UUID possible via entitydata
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:
/entitydata @e[type=Zombie,r=1] {UUIDLeast:3L,UUIDMost:3L}
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
1. /summon Zombie ~ ~1 ~ {UUIDLeast:33L,UUIDMost:33L,NoAI:1}
2. /entitydata @e[type=Zombie,r=2] {UUIDLeast:3L,UUIDMost:3L}
>>> Data tag successfully changes (white text, you can see the changed UUID)
3. /entitydata @e[type=Zombie,r=2] {}
>>> Results in: "That entity cannot be found"
4. /tp @e[type=Zombie,r=2] @p
>>> "That entity cannot be found"
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
1. /summon Zombie ~ ~1 ~ {UUIDLeast:33L,UUIDMost:33L,NoAI:1}
2. /entitydata @e[type=Zombie,r=2] {UUIDLeast:3L,UUIDMost:3L}
>>> UUID gets successfully changed, but entity cannot be found for this session.
Although the Zombie's UUID got changed into UUIDLeast:3,UUIDMost:3, it is NOT possible to summon a Zombie with UUIDLeast:33,UUIDMost:33!
It's as if the entity got at the same time both UUIDs.
3. /summon Zombie ~ ~1 ~ {UUIDLeast:3L,UUIDMost:3L,NoAI:1}
>>> You can summon a Zombie with UUIDLeast:3,UUIDMost:3 though although it shouldn't be possible as the other Zombie already got that UUID after you changed it via /entitydata.
4. Run:
/entitydata @e[type=Zombie,r=2] {}
5. If you relog again, then one of those Zombies will automatically be gone, but the UUID output will be 2 times, although only 1 Zombie is (visibly) left.
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).
I run
/entitydata @e[type=Zombie,r=1] {}
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".
Edit:
After you did those steps above, if you run
/entitydata @e[type=Zombie] {}
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
Linked Issues
Attachments9
- Fixed
Meri Diana- 6
- 5
- Community Consensus
- UUID duplicate entity
1.8.9 - 17w43b
1.8.9 1.9-pre3 1.9-pre4 1.9 1.9.1-pre1 1.9.1-pre2 1.9.1-pre3 1.9.1 1.9.2 16w14a 16w15a 16w15b 1.9.3-pre1 1.9.3-pre2 1.9.3-pre3 1.9.3 1.9.4 16w20a 16w21a 16w21b 1.10-pre1 1.10-pre2 1.10 1.10.1 1.10.2 16w32a 16w32b 16w33a 16w35a 16w36a 16w38a 16w39a 16w39b 16w39c 16w40a 16w41a 16w42a 16w43a 16w44a 1.11-pre1 1.11 16w50a 1.11.2 17w06a 17w14a 17w15a 17w16a 17w16b 17w17a 17w17b 17w18a 17w18b 1.12-pre1 1.12-pre2 1.12-pre3 1.12-pre4 1.12-pre5 1.12-pre6 1.12-pre7 1.12 1.12.1-pre1 1.12.1 1.12.2-pre1 1.12.2-pre2 1.12.2 17w43a 17w43b- 17w45b
Created Issue:
Same UUID infinite times possible + changing UUID possible via entitydata
Usual Disclaimer: Sorry if it's already here on Mojira, I'm bad at finding bugposts ;-;
In 1.8.x you can not change an entity's UUID by using e.g. this command:
/entitydata @e[type=Zombie,r=1] {UUIDLeast:3L,UUIDMost:3L}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
1. /summon Zombie ~ ~1 ~ {UUIDLeast:33L,UUIDMost:33L,NoAI:1} 2. /entitydata @e[type=Zombie,r=2] {UUIDLeast:3L,UUIDMost:3L} >>> Data tag successfully changes (white text, you can see the changed UUID) 3. /entitydata @e[type=Zombie,r=2] {} >>> Results in: "That entity cannot be found" 4. /tp @e[type=Zombie,r=2] @p >>> "That entity cannot be found"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
1. /summon Zombie ~ ~1 ~ {UUIDLeast:33L,UUIDMost:33L,NoAI:1} 2. /entitydata @e[type=Zombie,r=2] {UUIDLeast:3L,UUIDMost:3L} >>> UUID gets successfully changed, but entity cannot be found for this session. Although the Zombie's UUID got changed into UIDLeast:3,UUIDMost:3, it is NOT possible to summon a Zombie with UUIDLeast:33,UUIDMost:33! It's as if the entity got at the same time both UUIDs. 3. /summon Zombie ~ ~1 ~ {UUIDLeast:3L,UUIDMost:3L,NoAI:1} >>> You can summon a Zombie with UUIDLeast:3,UUIDMost:3 though although it shouldn't be possible as the other Zombie already got that UUID after you changed it via /entitydata. 4. Relog into the world, run: /entitydata @e[type=Zombie,r=2] {} >>> both Zombies got the same UUID, UUIDLeast:3,UUIDMost:3L (see screenshots) 5. If you relog again though, then one of those Zombies will automatically be gone.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).I run
/entitydata @e[type=Zombie,r=1] {}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".
Environment
doesn't matter
Attachments9
Usual Disclaimer: Sorry if it's already here on Mojira, I'm bad at finding bugposts ;-;
In 1.8.x you can not change an entity's UUID by using e.g. this command:
/entitydata @e[type=Zombie,r=1] {UUIDLeast:3L,UUIDMost:3L}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
1. /summon Zombie ~ ~1 ~ {UUIDLeast:33L,UUIDMost:33L,NoAI:1} 2. /entitydata @e[type=Zombie,r=2] {UUIDLeast:3L,UUIDMost:3L} >>> Data tag successfully changes (white text, you can see the changed UUID) 3. /entitydata @e[type=Zombie,r=2] {} >>> Results in: "That entity cannot be found" 4. /tp @e[type=Zombie,r=2] @p >>> "That entity cannot be found"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
1. /summon Zombie ~ ~1 ~ {UUIDLeast:33L,UUIDMost:33L,NoAI:1} 2. /entitydata @e[type=Zombie,r=2] {UUIDLeast:3L,UUIDMost:3L} >>> UUID gets successfully changed, but entity cannot be found for this session. Although the Zombie's UUID got changed into UUIDLeast:3,UUIDMost:3, it is NOT possible to summon a Zombie with UUIDLeast:33,UUIDMost:33! It's as if the entity got at the same time both UUIDs. 3. /summon Zombie ~ ~1 ~ {UUIDLeast:3L,UUIDMost:3L,NoAI:1} >>> You can summon a Zombie with UUIDLeast:3,UUIDMost:3 though although it shouldn't be possible as the other Zombie already got that UUID after you changed it via /entitydata. 4. Relog into the world, run: /entitydata @e[type=Zombie,r=2] {} >>> both Zombies got the same UUID, UUIDLeast:3,UUIDMost:3L (see screenshots) 5. If you relog again though, then one of those Zombies will automatically be gone.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).I run
/entitydata @e[type=Zombie,r=1] {}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".
Usual Disclaimer: Sorry if it's already here on Mojira, I'm bad at finding bugposts ;-;
In 1.8.x you can not change an entity's UUID by using e.g. this command:
/entitydata @e[type=Zombie,r=1] {UUIDLeast:3L,UUIDMost:3L}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
1. /summon Zombie ~ ~1 ~ {UUIDLeast:33L,UUIDMost:33L,NoAI:1} 2. /entitydata @e[type=Zombie,r=2] {UUIDLeast:3L,UUIDMost:3L} >>> Data tag successfully changes (white text, you can see the changed UUID) 3. /entitydata @e[type=Zombie,r=2] {} >>> Results in: "That entity cannot be found" 4. /tp @e[type=Zombie,r=2] @p >>> "That entity cannot be found"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
1. /summon Zombie ~ ~1 ~ {UUIDLeast:33L,UUIDMost:33L,NoAI:1} 2. /entitydata @e[type=Zombie,r=2] {UUIDLeast:3L,UUIDMost:3L} >>> UUID gets successfully changed, but entity cannot be found for this session. Although the Zombie's UUID got changed into UUIDLeast:3,UUIDMost:3, it is NOT possible to summon a Zombie with UUIDLeast:33,UUIDMost:33! It's as if the entity got at the same time both UUIDs. 3. /summon Zombie ~ ~1 ~ {UUIDLeast:3L,UUIDMost:3L,NoAI:1} >>> You can summon a Zombie with UUIDLeast:3,UUIDMost:3 though although it shouldn't be possible as the other Zombie already got that UUID after you changed it via /entitydata. 4. Relog into the world, run: /entitydata @e[type=Zombie,r=2] {} >>> both Zombies got the same UUID, UUIDLeast:3,UUIDMost:3L (see screenshots) 5. If you relog again though, then one of those Zombies will automatically be gone.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).I run
/entitydata @e[type=Zombie,r=1] {}
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".
Usual Disclaimer: Sorry if it's already here on Mojira, I'm bad at finding bugposts ;-;
In 1.8.x you can not change an entity's UUID by using e.g. this command:
/entitydata @e[type=Zombie,r=1] {UUIDLeast:3L,UUIDMost:3L}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
1. /summon Zombie ~ ~1 ~ {UUIDLeast:33L,UUIDMost:33L,NoAI:1} 2. /entitydata @e[type=Zombie,r=2] {UUIDLeast:3L,UUIDMost:3L} >>> Data tag successfully changes (white text, you can see the changed UUID) 3. /entitydata @e[type=Zombie,r=2] {} >>> Results in: "That entity cannot be found" 4. /tp @e[type=Zombie,r=2] @p >>> "That entity cannot be found"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
1. /summon Zombie ~ ~1 ~ {UUIDLeast:33L,UUIDMost:33L,NoAI:1} 2. /entitydata @e[type=Zombie,r=2] {UUIDLeast:3L,UUIDMost:3L} >>> UUID gets successfully changed, but entity cannot be found for this session. Although the Zombie's UUID got changed into UUIDLeast:3,UUIDMost:3, it is NOT possible to summon a Zombie with UUIDLeast:33,UUIDMost:33! It's as if the entity got at the same time both UUIDs. 3. /summon Zombie ~ ~1 ~ {UUIDLeast:3L,UUIDMost:3L,NoAI:1} >>> You can summon a Zombie with UUIDLeast:3,UUIDMost:3 though although it shouldn't be possible as the other Zombie already got that UUID after you changed it via /entitydata. 4. Run: /entitydata @e[type=Zombie,r=2] {} >>> both Zombies got the same UUID, UUIDLeast:3,UUIDMost:3L (see screenshots) 5. If you relog again though, then one of those Zombies will automatically be gone, but the UUID output will be 2 times, although only 1 Zombie is (visibly) left.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).I run
ftfore (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".
Usual Disclaimer: Sorry if it's already here on Mojira, I'm bad at finding bugposts ;-;
In 1.8.x you can not change an entity's UUID by using e.g. this command:
/entitydata @e[type=Zombie,r=1] {UUIDLeast:3L,UUIDMost:3L}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
1. /summon Zombie ~ ~1 ~ {UUIDLeast:33L,UUIDMost:33L,NoAI:1} 2. /entitydata @e[type=Zombie,r=2] {UUIDLeast:3L,UUIDMost:3L} >>> Data tag successfully changes (white text, you can see the changed UUID) 3. /entitydata @e[type=Zombie,r=2] {} >>> Results in: "That entity cannot be found" 4. /tp @e[type=Zombie,r=2] @p >>> "That entity cannot be found"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
1. /summon Zombie ~ ~1 ~ {UUIDLeast:33L,UUIDMost:33L,NoAI:1} 2. /entitydata @e[type=Zombie,r=2] {UUIDLeast:3L,UUIDMost:3L} >>> UUID gets successfully changed, but entity cannot be found for this session. Although the Zombie's UUID got changed into UUIDLeast:3,UUIDMost:3, it is NOT possible to summon a Zombie with UUIDLeast:33,UUIDMost:33! It's as if the entity got at the same time both UUIDs. 3. /summon Zombie ~ ~1 ~ {UUIDLeast:3L,UUIDMost:3L,NoAI:1} >>> You can summon a Zombie with UUIDLeast:3,UUIDMost:3 though although it shouldn't be possible as the other Zombie already got that UUID after you changed it via /entitydata. 4. Run: /entitydata @e[type=Zombie,r=2] {}>>> both Zombies got the same UUID, UUIDLeast:3,UUIDMost:3L (see screenshots)5. If you relog againthough, then one of those Zombies will automatically be gone, but the UUID output will be 2 times, although only 1 Zombie is (visibly) left.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).I run
ftfore (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".
Usual Disclaimer: Sorry if it's already here on Mojira, I'm bad at finding bugposts ;-;
In 1.8.x you can not change an entity's UUID by using e.g. this command:
/entitydata @e[type=Zombie,r=1] {UUIDLeast:3L,UUIDMost:3L}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
1. /summon Zombie ~ ~1 ~ {UUIDLeast:33L,UUIDMost:33L,NoAI:1} 2. /entitydata @e[type=Zombie,r=2] {UUIDLeast:3L,UUIDMost:3L} >>> Data tag successfully changes (white text, you can see the changed UUID) 3. /entitydata @e[type=Zombie,r=2] {} >>> Results in: "That entity cannot be found" 4. /tp @e[type=Zombie,r=2] @p >>> "That entity cannot be found"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
1. /summon Zombie ~ ~1 ~ {UUIDLeast:33L,UUIDMost:33L,NoAI:1} 2. /entitydata @e[type=Zombie,r=2] {UUIDLeast:3L,UUIDMost:3L} >>> UUID gets successfully changed, but entity cannot be found for this session. Although the Zombie's UUID got changed into UUIDLeast:3,UUIDMost:3, it is NOT possible to summon a Zombie with UUIDLeast:33,UUIDMost:33! It's as if the entity got at the same time both UUIDs. 3. /summon Zombie ~ ~1 ~ {UUIDLeast:3L,UUIDMost:3L,NoAI:1} >>> You can summon a Zombie with UUIDLeast:3,UUIDMost:3 though although it shouldn't be possible as the other Zombie already got that UUID after you changed it via /entitydata. 4. Run: /entitydata @e[type=Zombie,r=2] {} 5. If you relog again, then one of those Zombies will automatically be gone, but the UUID output will be 2 times, although only 1 Zombie is (visibly) left.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).I run
ftfore (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".
Usual Disclaimer: Sorry if it's already here on Mojira, I'm bad at finding bugposts ;-;
In 1.8.x you can not change an entity's UUID by using e.g. this command:
/entitydata @e[type=Zombie,r=1] {UUIDLeast:3L,UUIDMost:3L}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
1. /summon Zombie ~ ~1 ~ {UUIDLeast:33L,UUIDMost:33L,NoAI:1} 2. /entitydata @e[type=Zombie,r=2] {UUIDLeast:3L,UUIDMost:3L} >>> Data tag successfully changes (white text, you can see the changed UUID) 3. /entitydata @e[type=Zombie,r=2] {} >>> Results in: "That entity cannot be found" 4. /tp @e[type=Zombie,r=2] @p >>> "That entity cannot be found"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
1. /summon Zombie ~ ~1 ~ {UUIDLeast:33L,UUIDMost:33L,NoAI:1} 2. /entitydata @e[type=Zombie,r=2] {UUIDLeast:3L,UUIDMost:3L} >>> UUID gets successfully changed, but entity cannot be found for this session. Although the Zombie's UUID got changed into UUIDLeast:3,UUIDMost:3, it is NOT possible to summon a Zombie with UUIDLeast:33,UUIDMost:33! It's as if the entity got at the same time both UUIDs. 3. /summon Zombie ~ ~1 ~ {UUIDLeast:3L,UUIDMost:3L,NoAI:1} >>> You can summon a Zombie with UUIDLeast:3,UUIDMost:3 though although it shouldn't be possible as the other Zombie already got that UUID after you changed it via /entitydata. 4. Run: /entitydata @e[type=Zombie,r=2] {} 5. If you relog again, then one of those Zombies will automatically be gone, but the UUID output will be 2 times, although only 1 Zombie is (visibly) left.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).I run
/entitydata @e[type=Zombie,r=1] {}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".
Sorry for the frequent changes, my cat ran over my keyboard and deleted text, saw it afterwards
Usual Disclaimer: Sorry if it's already here on Mojira, I'm bad at finding bugposts ;-;
In 1.8.x you can not change an entity's UUID by using e.g. this command:
/entitydata @e[type=Zombie,r=1] {UUIDLeast:3L,UUIDMost:3L}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
1. /summon Zombie ~ ~1 ~ {UUIDLeast:33L,UUIDMost:33L,NoAI:1} 2. /entitydata @e[type=Zombie,r=2] {UUIDLeast:3L,UUIDMost:3L} >>> Data tag successfully changes (white text, you can see the changed UUID) 3. /entitydata @e[type=Zombie,r=2] {} >>> Results in: "That entity cannot be found" 4. /tp @e[type=Zombie,r=2] @p >>> "That entity cannot be found"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
1. /summon Zombie ~ ~1 ~ {UUIDLeast:33L,UUIDMost:33L,NoAI:1} 2. /entitydata @e[type=Zombie,r=2] {UUIDLeast:3L,UUIDMost:3L} >>> UUID gets successfully changed, but entity cannot be found for this session. Although the Zombie's UUID got changed into UUIDLeast:3,UUIDMost:3, it is NOT possible to summon a Zombie with UUIDLeast:33,UUIDMost:33! It's as if the entity got at the same time both UUIDs. 3. /summon Zombie ~ ~1 ~ {UUIDLeast:3L,UUIDMost:3L,NoAI:1} >>> You can summon a Zombie with UUIDLeast:3,UUIDMost:3 though although it shouldn't be possible as the other Zombie already got that UUID after you changed it via /entitydata. 4. Run: /entitydata @e[type=Zombie,r=2] {} 5. If you relog again, then one of those Zombies will automatically be gone, but the UUID output will be 2 times, although only 1 Zombie is (visibly) left.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).I run
/entitydata @e[type=Zombie,r=1] {}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".
Sorry for the frequent changes, my cat ran over my keyboard and deleted text, saw it afterwards
Usual Disclaimer: Sorry if it's already here on Mojira, I'm bad at finding bugposts ;-;
In 1.8.x you can not change an entity's UUID by using e.g. this command:
/entitydata @e[type=Zombie,r=1] {UUIDLeast:3L,UUIDMost:3L}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
1. /summon Zombie ~ ~1 ~ {UUIDLeast:33L,UUIDMost:33L,NoAI:1} 2. /entitydata @e[type=Zombie,r=2] {UUIDLeast:3L,UUIDMost:3L} >>> Data tag successfully changes (white text, you can see the changed UUID) 3. /entitydata @e[type=Zombie,r=2] {} >>> Results in: "That entity cannot be found" 4. /tp @e[type=Zombie,r=2] @p >>> "That entity cannot be found"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
1. /summon Zombie ~ ~1 ~ {UUIDLeast:33L,UUIDMost:33L,NoAI:1} 2. /entitydata @e[type=Zombie,r=2] {UUIDLeast:3L,UUIDMost:3L} >>> UUID gets successfully changed, but entity cannot be found for this session. Although the Zombie's UUID got changed into UUIDLeast:3,UUIDMost:3, it is NOT possible to summon a Zombie with UUIDLeast:33,UUIDMost:33! It's as if the entity got at the same time both UUIDs. 3. /summon Zombie ~ ~1 ~ {UUIDLeast:3L,UUIDMost:3L,NoAI:1} >>> You can summon a Zombie with UUIDLeast:3,UUIDMost:3 though although it shouldn't be possible as the other Zombie already got that UUID after you changed it via /entitydata. 4. Run: /entitydata @e[type=Zombie,r=2] {} 5. If you relog again, then one of those Zombies will automatically be gone, but the UUID output will be 2 times, although only 1 Zombie is (visibly) left.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).I run
/entitydata @e[type=Zombie,r=1] {}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".
Edit:
After you did those steps above, if you run/entitydata @e[type=Zombie] {}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
![[Mod] redstonehelper](../../../data/avatars/users/10122.svg){kind=small}
doesn't matter
Usual Disclaimer: Sorry if it's already here on Mojira, I'm bad at finding bugposts ;-;
Please read [SkylinerW's comment|]
In 1.8.x you can not change an entity's UUID by using e.g. this command:
/entitydata @e[type=Zombie,r=1] {UUIDLeast:3L,UUIDMost:3L}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
1. /summon Zombie ~ ~1 ~ {UUIDLeast:33L,UUIDMost:33L,NoAI:1} 2. /entitydata @e[type=Zombie,r=2] {UUIDLeast:3L,UUIDMost:3L} >>> Data tag successfully changes (white text, you can see the changed UUID) 3. /entitydata @e[type=Zombie,r=2] {} >>> Results in: "That entity cannot be found" 4. /tp @e[type=Zombie,r=2] @p >>> "That entity cannot be found"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
1. /summon Zombie ~ ~1 ~ {UUIDLeast:33L,UUIDMost:33L,NoAI:1} 2. /entitydata @e[type=Zombie,r=2] {UUIDLeast:3L,UUIDMost:3L} >>> UUID gets successfully changed, but entity cannot be found for this session. Although the Zombie's UUID got changed into UUIDLeast:3,UUIDMost:3, it is NOT possible to summon a Zombie with UUIDLeast:33,UUIDMost:33! It's as if the entity got at the same time both UUIDs. 3. /summon Zombie ~ ~1 ~ {UUIDLeast:3L,UUIDMost:3L,NoAI:1} >>> You can summon a Zombie with UUIDLeast:3,UUIDMost:3 though although it shouldn't be possible as the other Zombie already got that UUID after you changed it via /entitydata. 4. Run: /entitydata @e[type=Zombie,r=2] {} 5. If you relog again, then one of those Zombies will automatically be gone, but the UUID output will be 2 times, although only 1 Zombie is (visibly) left.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).I run
/entitydata @e[type=Zombie,r=1] {}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".
Edit:
After you did those steps above, if you run/entitydata @e[type=Zombie] {}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
Usual Disclaimer: Sorry if it's already here on Mojira, I'm bad at finding bugposts ;-;
Please read [SkylinerW's comment|]
In 1.8.x you can not change an entity's UUID by using e.g. this command:
/entitydata @e[type=Zombie,r=1] {UUIDLeast:3L,UUIDMost:3L}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
1. /summon Zombie ~ ~1 ~ {UUIDLeast:33L,UUIDMost:33L,NoAI:1} 2. /entitydata @e[type=Zombie,r=2] {UUIDLeast:3L,UUIDMost:3L} >>> Data tag successfully changes (white text, you can see the changed UUID) 3. /entitydata @e[type=Zombie,r=2] {} >>> Results in: "That entity cannot be found" 4. /tp @e[type=Zombie,r=2] @p >>> "That entity cannot be found"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
1. /summon Zombie ~ ~1 ~ {UUIDLeast:33L,UUIDMost:33L,NoAI:1} 2. /entitydata @e[type=Zombie,r=2] {UUIDLeast:3L,UUIDMost:3L} >>> UUID gets successfully changed, but entity cannot be found for this session. Although the Zombie's UUID got changed into UUIDLeast:3,UUIDMost:3, it is NOT possible to summon a Zombie with UUIDLeast:33,UUIDMost:33! It's as if the entity got at the same time both UUIDs. 3. /summon Zombie ~ ~1 ~ {UUIDLeast:3L,UUIDMost:3L,NoAI:1} >>> You can summon a Zombie with UUIDLeast:3,UUIDMost:3 though although it shouldn't be possible as the other Zombie already got that UUID after you changed it via /entitydata. 4. Run: /entitydata @e[type=Zombie,r=2] {} 5. If you relog again, then one of those Zombies will automatically be gone, but the UUID output will be 2 times, although only 1 Zombie is (visibly) left.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).I run
/entitydata @e[type=Zombie,r=1] {}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".
Edit:
After you did those steps above, if you run/entitydata @e[type=Zombie] {}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
Usual Disclaimer: Sorry if it's already here on Mojira, I'm bad at finding bugposts ;-;
Please read SkylinerW's comment with code analysis
In 1.8.x you can not change an entity's UUID by using e.g. this command:
/entitydata @e[type=Zombie,r=1] {UUIDLeast:3L,UUIDMost:3L}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
1. /summon Zombie ~ ~1 ~ {UUIDLeast:33L,UUIDMost:33L,NoAI:1} 2. /entitydata @e[type=Zombie,r=2] {UUIDLeast:3L,UUIDMost:3L} >>> Data tag successfully changes (white text, you can see the changed UUID) 3. /entitydata @e[type=Zombie,r=2] {} >>> Results in: "That entity cannot be found" 4. /tp @e[type=Zombie,r=2] @p >>> "That entity cannot be found"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
1. /summon Zombie ~ ~1 ~ {UUIDLeast:33L,UUIDMost:33L,NoAI:1} 2. /entitydata @e[type=Zombie,r=2] {UUIDLeast:3L,UUIDMost:3L} >>> UUID gets successfully changed, but entity cannot be found for this session. Although the Zombie's UUID got changed into UUIDLeast:3,UUIDMost:3, it is NOT possible to summon a Zombie with UUIDLeast:33,UUIDMost:33! It's as if the entity got at the same time both UUIDs. 3. /summon Zombie ~ ~1 ~ {UUIDLeast:3L,UUIDMost:3L,NoAI:1} >>> You can summon a Zombie with UUIDLeast:3,UUIDMost:3 though although it shouldn't be possible as the other Zombie already got that UUID after you changed it via /entitydata. 4. Run: /entitydata @e[type=Zombie,r=2] {} 5. If you relog again, then one of those Zombies will automatically be gone, but the UUID output will be 2 times, although only 1 Zombie is (visibly) left.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).I run
/entitydata @e[type=Zombie,r=1] {}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".
Edit:
After you did those steps above, if you run/entitydata @e[type=Zombie] {}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
Usual Disclaimer: Sorry if it's already here on Mojira, I'm bad at finding bugposts ;-;
Please read SkylinerW's comment with code analysis
In 1.8.x you can not change an entity's UUID by using e.g. this command:
/entitydata @e[type=Zombie,r=1] {UUIDLeast:3L,UUIDMost:3L}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
1. /summon Zombie ~ ~1 ~ {UUIDLeast:33L,UUIDMost:33L,NoAI:1} 2. /entitydata @e[type=Zombie,r=2] {UUIDLeast:3L,UUIDMost:3L} >>> Data tag successfully changes (white text, you can see the changed UUID) 3. /entitydata @e[type=Zombie,r=2] {} >>> Results in: "That entity cannot be found" 4. /tp @e[type=Zombie,r=2] @p >>> "That entity cannot be found"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
1. /summon Zombie ~ ~1 ~ {UUIDLeast:33L,UUIDMost:33L,NoAI:1} 2. /entitydata @e[type=Zombie,r=2] {UUIDLeast:3L,UUIDMost:3L} >>> UUID gets successfully changed, but entity cannot be found for this session. Although the Zombie's UUID got changed into UUIDLeast:3,UUIDMost:3, it is NOT possible to summon a Zombie with UUIDLeast:33,UUIDMost:33! It's as if the entity got at the same time both UUIDs. 3. /summon Zombie ~ ~1 ~ {UUIDLeast:3L,UUIDMost:3L,NoAI:1} >>> You can summon a Zombie with UUIDLeast:3,UUIDMost:3 though although it shouldn't be possible as the other Zombie already got that UUID after you changed it via /entitydata. 4. Run: /entitydata @e[type=Zombie,r=2] {} 5. If you relog again, then one of those Zombies will automatically be gone, but the UUID output will be 2 times, although only 1 Zombie is (visibly) left.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).I run
/entitydata @e[type=Zombie,r=1] {}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".
Edit:
After you did those steps above, if you run/entitydata @e[type=Zombie] {}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
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:
/entitydata @e[type=Zombie,r=1] {UUIDLeast:3L,UUIDMost:3L}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
1. /summon Zombie ~ ~1 ~ {UUIDLeast:33L,UUIDMost:33L,NoAI:1} 2. /entitydata @e[type=Zombie,r=2] {UUIDLeast:3L,UUIDMost:3L} >>> Data tag successfully changes (white text, you can see the changed UUID) 3. /entitydata @e[type=Zombie,r=2] {} >>> Results in: "That entity cannot be found" 4. /tp @e[type=Zombie,r=2] @p >>> "That entity cannot be found"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
1. /summon Zombie ~ ~1 ~ {UUIDLeast:33L,UUIDMost:33L,NoAI:1} 2. /entitydata @e[type=Zombie,r=2] {UUIDLeast:3L,UUIDMost:3L} >>> UUID gets successfully changed, but entity cannot be found for this session. Although the Zombie's UUID got changed into UUIDLeast:3,UUIDMost:3, it is NOT possible to summon a Zombie with UUIDLeast:33,UUIDMost:33! It's as if the entity got at the same time both UUIDs. 3. /summon Zombie ~ ~1 ~ {UUIDLeast:3L,UUIDMost:3L,NoAI:1} >>> You can summon a Zombie with UUIDLeast:3,UUIDMost:3 though although it shouldn't be possible as the other Zombie already got that UUID after you changed it via /entitydata. 4. Run: /entitydata @e[type=Zombie,r=2] {} 5. If you relog again, then one of those Zombies will automatically be gone, but the UUID output will be 2 times, although only 1 Zombie is (visibly) left.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).I run
/entitydata @e[type=Zombie,r=1] {}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".
Edit:
After you did those steps above, if you run/entitydata @e[type=Zombie] {}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
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:
/entitydata @e[type=Zombie,r=1] {UUIDLeast:3L,UUIDMost:3L}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
1. /summon Zombie ~ ~1 ~ {UUIDLeast:33L,UUIDMost:33L,NoAI:1} 2. /entitydata @e[type=Zombie,r=2] {UUIDLeast:3L,UUIDMost:3L} >>> Data tag successfully changes (white text, you can see the changed UUID) 3. /entitydata @e[type=Zombie,r=2] {} >>> Results in: "That entity cannot be found" 4. /tp @e[type=Zombie,r=2] @p >>> "That entity cannot be found"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
1. /summon Zombie ~ ~1 ~ {UUIDLeast:33L,UUIDMost:33L,NoAI:1} 2. /entitydata @e[type=Zombie,r=2] {UUIDLeast:3L,UUIDMost:3L} >>> UUID gets successfully changed, but entity cannot be found for this session. Although the Zombie's UUID got changed into UUIDLeast:3,UUIDMost:3, it is NOT possible to summon a Zombie with UUIDLeast:33,UUIDMost:33! It's as if the entity got at the same time both UUIDs. 3. /summon Zombie ~ ~1 ~ {UUIDLeast:3L,UUIDMost:3L,NoAI:1} >>> You can summon a Zombie with UUIDLeast:3,UUIDMost:3 though although it shouldn't be possible as the other Zombie already got that UUID after you changed it via /entitydata. 4. Run: /entitydata @e[type=Zombie,r=2] {} 5. If you relog again, then one of those Zombies will automatically be gone, but the UUID output will be 2 times, although only 1 Zombie is (visibly) left.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).I run
/entitydata @e[type=Zombie,r=1] {}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".
Edit:
After you did those steps above, if you run/entitydata @e[type=Zombie] {}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
relates to
![[Mod] Skylinerw](../../../data/assets/gravatar/skylinerw.png){kind=small}
The bug
Spawn eggs can spawn entities with already used UUIDs. This should not be possible since UUIDs are supposed to be unique and duplicate UUIDs can and will cause errors.
How to reproduce
- Give yourself a spawn egg
/give @s spawn_egg{EntityTag:{id:"minecraft:husk",UUIDLeast:1L,UUIDMost:1L}} - Use the spawn egg at least twice
- Use the following command to list all entities with the used UUID
/say @e[nbt={UUIDMost:1L,UUIDLeast:1L}]→ It lists multiple entities
Code analysis and fix note
Based on 1.12.2 decompiled using MCP 9.40
The method net.minecraft.item.ItemMonsterPlacer.applyItemEntityDataToEntity(World, EntityPlayer, ItemStack, Entity) is apparently supposed to use the randomly generated UUID instead of the provided one, however does this incorrectly by setting the original UUID before merging the NBT data, see also MC-98244.
However, this is not required and probably not the correct behavior. Since the entity is a new one, the method applyItemEntityDataToEntity does not have to do anything to prevent UUID manipulation. Instead the methods ItemMonsterPlacer.onItemUse(EntityPlayer, World, BlockPos, EnumHand, EnumFacing, float, float, float), ItemMonsterPlacer.onItemRightClick(World, EntityPlayer, EnumHand) and net.minecraft.init.Bootstrap.registerDispenserBehaviors().new BehaviorDefaultDispenseItem() {...}.dispenseStack(IBlockSource, ItemStack) should first create the entity, then apply the NBT data and then try to spawn it. This would then fail as expected like it is currently the case for armor stands.
Confirmed. In 1.8, /entitydata specifically strips the UUIDLeast and UUIDMost tags from dataTag input.
In 1.9 the following steps are made:
1. The entity's NBT data is obtained
2. The dataTag input is parsed
3. The entity's current UUID is copied (in 1.8, this is where UUIDLeast and UUIDMost are removed from input instead)
4. The NBT data is merged together (not applied to the entity yet)
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.
Please link to Skylinerw's explanation in the description
This appears to be fixed in 17w45b for /data merge|remove and /execute store result|success entity