Questions about Minecraft 1.8 UUID's

So I heard that Minecraft usernames will be allowed to be changed past version 1.8.

That means any method that I use to identify a player using their Username's will be flawed. For example, I used event.getPlayer().getName() to identify that it's that players data, or that player's health, etc.

With the UUID system, how would I migrate my code to fit that? Would I use a method added in the new Bukkit API for event.getPlayer().getUUID(); ?

If I'm missing the point here, please chime in and help me out.
Thanks.

 

Qwahchees It depends on how you are using it. If you are creating some sort of block logger or something that requires data storage for Player's, you'd use their UUID. If you are creating something that will only apply for the duration that the Player is online (like a message command), then you are still able to use the Player's name. It all depends on how you are using the Player

 

Qwahchees You are confusing the Player type and the UUID type. You can still access all of the player's information without changing your code unless that information is .getName() which you'll want to change to use the UUID's.

 

Not necessarily. Read xTigerRebornx post. You will not have to use UUIDs unless the player data you're storing persists between logins.

 

amhokies Very true, meant to say that but didn't. Thanks.

 

Yes, the data I'll be using is saved into a flatfile and is re-initialized by the plugin upon login of the player. I should switch to UUID's for that, yes?

 

Yes, if you're loading something from the flatfile with the player's name as a sort of key for the data, you will need to switch to UUIDs so that a name change by the player won't cause issues.

 

You have to in this case. Yes.
As soon as a player logs out, you cannot know if a player with the same name that logs in later is really the same as before.
Doing stuff with offline players, like sending mails or managing data in flatfiles or DBs has to utilize the UUID from this point on.
The trick part is, that retrieving the UUID for offline players is a blocking action and the data will not be available in the same tick you request it. So this will need some thinking when implementing such functions.

Mailing like Essentials does it will no longer be safe, as a player will always use the last known name of the target player to send his mail. But if another player has this name now, the wrong UUID will be retrieved.
This whole mechanism will cause a lot of trouble for us in the future.
Simply because humans relate to other humans by names that are easy to remember,
and not by random 32 numeric long identifiers.
So this name changing thing basicly undermines the human way of identifying each other.
I know, it's a bit off-topic. But this is giving me headaches whenever I think of it.

 

What I've done to kind of combat this is creating a table in my database to store the player's UUID and name, then check to make sure they match when they login. If they do match, just leave it, but if they don't match, I update the name to their new name.

 

That seems smart. I save a set of numbers, or stats, to a flat file upon player logout, and retrieve it based on the name of the player matching the name of the flat-file upon login.

Could I store the UUID as the name of the file, instead of the player's name as the flatfile name instead, to work with this new system?

For example: qwahchees.yml would be 12838123812381283812.yml?
Also, what's the method to retrieve the UUID and is it implemented as of Bukkit 1.7.7?

 

Qwahchees
Naming a file with a 16 digit hex number probably isn't the best way to do it. It would get very messy and any kind of manual editting of files you'd have to do would be nearly impossible. The method is Player.getUniqueId(), I believe.

 

I also thought about this. We already have a local UUID storage to uniquely bind a players (unchangable) community forum name to his UUID. So at least this can be resolved reliably.
But the thing even with a local UUID storage is: If the player is online, you will always get the correct UUID anyway by using player.getUniqueId().
But if the player is offline and you need the UUID, you can't be sure you are getting the right ID,
because even with your local storage, you always rely on the last known name which can be a days or weeks old information.
The name can already be changed until you actually use the UUID. That's a problem which is not reliably solvable, unless you encourage players to use UUIDs instead of names to mail other players and stuff....