Make cTeam use UUID's instead of player names ($10)

[PureTryOut]

Currently, as explained by @tigerw here, cTeam manages it's members by player names. As Minecraft currently uses UUID's, this should be used instead.

[PureTryOut]

A note, I put a $10 bounty on this issue over on Bountysource.

Maybe something for you again @PlasmaPower?

[PlasmaPower]

Do I need to support backwards compatibility? If so, how?

[PureTryOut]

Keep names as an alternative you mean? Not sure why you would, Minecraft has been using UUID's for a long time now.

[PlasmaPower]

We don't want to break everything using the current API though.

[PureTryOut]

I honestly think there are 0 plugins out there right now using this, and even if plugins do use it, it's good for them to update to UUID's anyway, but sure make it backwards compatible. It will probably be a lot more work then though.

[PlasmaPower]

It won't be more work (I can just copy and paste). The reason not to is that then you have to add UUID to every function name. Also, plugin authors might gravitate towards the easier name based API. Maybe we should just replace the API then.

Anyone else have an opinion/would a huge breaking change get merged?

[ghost]

UUID have a special structure right? You can check if it's a UUID or not.

[madmaxoft]

Actually, if I read things correct, Minecraft still uses player names for its team management, both in the commands and in the underlying storage. http://minecraft.gamepedia.com/Scoreboard , see the commands (scoreboard players XYZ) and the NBT structure (/data/teams[]/players)

Therefore I suggest we keep things as they are, but only improve the documentation so that it says what it uses.

If desired, we could add API functions that take UUIDs instead of player names, and internally translate to names. If Mojang ever decides to switch to UUIDs in team management, we could simply swap the internals and still support both kinds of functions.

[PureTryOut]

If desired, we could add API functions that take UUIDs instead of player names, and internally translate to names.

I would prefer that then. I really dislike the idea of having to use player names where it asks for UUID's everywhere else. UUID's is more robust anyways, you don't get problems if players change their names.

[PlasmaPower]

@Schwertspize I'm not sure how that's relevant, older plugins won't be checking if it's a UUID and will therefore break with an update.

[Pokechu22]

Names are used for players, but entities in the scoreboard use their UUIDs (as strings). (On the other hand, cuberite doesn't implement entity UUIDs fully yet, so it probably is a moot point)

[ghost]

@PlasmaPower i mean if cuberite checks if the argument doesn't fit the UUID scheme, then assumes it's a name.

Anyway, it doesn't have to be back backwards compatible

[madmaxoft]

@Schwertspize No, that's a really bad idea. Then a player comes along whose name is an uuid for some reason and all hell breaks lose. No, keep them separate and make separate functions.

[PlasmaPower]

@Schwertspize What about functions that take a team and return a UUID?

@madmaxoft not possible, MC usernames have a max of 16 chars, UUIDs are much longer.

[tigerw]

Please, none of this backwards compatibility stuff. Just change the names to the unique identifiers and deal with any complaints (probably none) which come. It's not worth the mess of having two functions.

(edited by madmaxoft to remove email cruft)

[madmaxoft]

It's not about backward compatibility, it's about ease of use. Sometimes it's easier to use a UUID (when you have a cPlayer object), sometimes it's easier to use a name (when handling a command with playername as param). It's perfectly worth having two functions.

[PlasmaPower]

when you have a cPlayer object

Player.getUUID()?

It's perfectly worth having two functions

Operating on the same data set or different data sets? The former is very complicated.

[mathiascode]