Uploaded image for project: 'Minecraft: Java Edition'
  1. Minecraft: Java Edition
  2. MC-98244

Same UUID infinite times possible + changing UUID possible via entitydata

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved
    • Resolution: Fixed
    • Affects Version/s: 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
    • Fix Version/s: Minecraft 17w45b
    • Confirmation Status:
      Community Consensus

      Description

      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


      More info https://bugs.mojang.com/browse/MC-98244?focusedCommentId=290391&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-290391

        Attachments

        1. 2016-02-28_11.29.24.png
          2016-02-28_11.29.24.png
          463 kB
        2. 2016-02-28_11.30.08.png
          2016-02-28_11.30.08.png
          449 kB
        3. 2016-02-28_11.30.19.png
          2016-02-28_11.30.19.png
          432 kB
        4. 2016-02-28_11.30.57.png
          2016-02-28_11.30.57.png
          433 kB
        5. 2016-02-28_11.31.24.png
          2016-02-28_11.31.24.png
          450 kB
        6. 2016-02-28_11.31.43.png
          2016-02-28_11.31.43.png
          431 kB
        7. 2016-02-28_11.31.54.png
          2016-02-28_11.31.54.png
          431 kB
        8. 2016-02-28_12.16.21.png
          2016-02-28_12.16.21.png
          431 kB
        9. 2016-02-28_12.16.27.png
          2016-02-28_12.16.27.png
          431 kB

          Issue Links

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                LapisDemon Meri Diana
              • Votes:
                6 Vote for this issue
                Watchers:
                5 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  CHK: