As many are aware, Mojang is transitioning to using a unique, random identifier for each player rather than continuing the use of usernames. While player names are not completely going away (you will still see names over players’ heads and in chat), the problem is that it will no longer be guaranteed that a certain player’s Minecraft name will still be owned by that player once he or she disconnects. That may be caused by a player changing his or her name to something else, freeing up the older name for someone else to use.
Many things may actually not break
Since names are not going away and it’s only the 1-to-1 name-to-person correspondence that is going away, the change over to UUID may not be that dire. For example, if permission is given to “frank_m3256″ to use creative mode, there is no reason as to why old software would be unable to continue comparing names. When frank_m3256 signs on, he will receive his creative powers as usual. When the trouble develops is when Frank chooses to change his username. Nothing would break, but whoever takes the frank_m3256 name would then receive the powers of the original Frank. The original Frank, who would be using a new name, would not be recognized as the original Frank.
What’s involved in updating code for UUIDs
For most operations that need to work on players that are currently connected, the changeover to UUIDs does not present much of a problem.
When offline players are involved, the situation becomes much more complicated. When a player is logged onto a server, it is guaranteed that that player’s name is only assigned to that player. Remember, it’s when people disconnect that the 1-to-1 correspondence disappears. That results in complications for plugins, mods, and other projects that ask for a username once a player has disconnected from the game, because the code now needs to map the username to a unique identifier. While there might be a temporary cache to answer “what was the UUID of the last player connected that used this name?” it would not be wise to look there, because, if you recall, the name may be reassigned to someone else. The only way to actually accurately perform this name-to-ID conversion is to contact the Mojang servers and request for the equivalent UUID, which means these operations may need to now wait on a webpage request sent to Mojang.
The other difficulty regards plugins and mods that store data in the world. Imagine a chest that stored its owner in its NBT data: that name, as well as names of hundreds of other players, are now buried deep inside the data of blocks strewn across the world. Conversion of the names to the UUIDs cannot be done without actually opening every chunk and searching for names to change over. As noted previously, the fact that names are still used does not necessarily mean anything will break, but it may cause problems in the future for players that change their names.
Regarding my projects
As far as my projects go, we do plan to update for full UUID support.
- WorldEdit is not particularly impacted by this change because it currently does not persist per-player data long after a player has disconnected.
- WorldGuard has many names stored, primarily for region protection. Fortunately, this data is completely centralized, so it can be converted somewhat easily. An update should hopefully come out soon (as soon as time permits, rather) to add full support for UUID. It’s likely that nothing may break (if an update is not immediately available), but be aware about the issue with players changing their name.
- CraftBook stores names on signs, which presents a problem because the unique identifiers in use by Mojang do not fit on the signs (nor did names, but there was only a 1 character length discrepancy). Me4502 is working on converting names to use an internal ID which will fit on the signs.
- CommandBook is being updated to use UUIDs by Dark_Arc.
- CommandHelper is being updated to use UUIDs by Lady_Caitlin.