-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
UUID Migration #112
Comments
Just to add to this: Minecraft natively allows for UUID -> lastKnownName and Bukkit achieves this through Bukkit#getOfflinePlayer(UUID) Considering 1.7.5/1.7.6 already allows for this in Bukkit, it would be possible to start the migration work now. The only consideration is that when the MC server is started in offline mode, the UUID is generated and not recalled from Mojang's Servers (this also applies to NPC's created by plugins like Citizens). |
Has there been any progress toward implementing UUID support? I'd love to be able to enable the Asshat Module again and dump the crappy external plugin I'm using now, :p. |
It should be possible. I personally haven't spent the time to touch VoxelGuest yet. I'll talk to TVPT and see if it's graspable to upgrade to UUID. |
As mentioned in the issue description - UUIDs should be quite easy to implement. However, I'm busy with my finals at the moment which is part of the reason I haven't been working on VoxelGuest for the past couple of months. |
Hah, I'm a complete noob when it comes to Java. I've been reading and gaining a general understanding of Java, but the most I've done is language fixes and a remapping of Minecraft classes (those arbitrary 3-letter names) within a mod from 1.7.5 to 1.7.9 (talk about tedious). When do you expect to once again have the time to work on VG? :3 |
That's hard to tell :P I kinda expected to have time in June but well, I'm still somewhat occupied. |
Okay. hugs |
I can dedicate some time this weekend. I'm done with finals. |
Yeah, I can't figure it out on my own. I see the new and the deprecated API and have a vague understanding, but implementing it is beyond my scope of knowledge. |
Alright, it's done, finally :P - I'm going to do a little more testing and |
You're incredible. Thank you so much. I had feared that the temporary closing of The Voxel Box would result in development hiatus for VG. |
---- Addresses #112 Non-UUID classes in the Asshat module have been marked deprecated and will be removed soon. A system to convert the old DB table is still required but should be very easy to implement. However, names were stored lower-case while Mojang's API is case-sensitive. Tab-completion for the UUID table is currently not supported. Player-login and /ban, /unban, /banreason, /gag, /ungag commands can slow down the server's main event loop since a synchronous web request is sent to resolve a player's UUID.
A little late, but I still had a nasty bug to fix. There is currently no way to migrate your old bans/mutes since they were all stored using lower-case names and Mojang's API requires exact names. I'll probably write a small migration job that'll at least try to upgrade some data (i.e. all players whose names are actually all-lower-case). |
Migration isn't an issue; we've done "migrations" before (which consisted of the manual re-banning of about 200 people) since we'd been using a 'global' banning plugin that didn't save bans locally, but this time, we're granting people a second chance. This was planned to happen for 1.8, but now that VG is ready before then, we'll just do it now. Anyway, nevermind that. I'm extremely grateful for your excellent work. |
Possibly one way is to keep the old data and if the player name matches (equalsIgnoreCase) add it to the new ban list via UUID. Just a thought. This way it can be "over time conversion". Toggle might be an added feature for this. |
Mojang will probably move to a UUID based system for player names. Hence migration code is required to make sure banned players stay banned.
Possible solution:
An upgrade routine will go through all player names and query mojang's DB for corresponding UUIDs - player names in our DB will be replaced by their UUIDs.
Commands with player name parameters will internally translate them into UUIDs so we are only using UUIDs internally. Messages outputting player names will have to translate UUIDs into names. - Mojang will eventually implement bi-diretional lookups.
The text was updated successfully, but these errors were encountered: