Skip to content
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

PlayerID has changed #73

Open
Valacarnage opened this issue Dec 26, 2018 · 14 comments
Open

PlayerID has changed #73

Valacarnage opened this issue Dec 26, 2018 · 14 comments

Comments

@Valacarnage
Copy link

It appears the PlayerIDs have changed to a new format. They old IDs now map to the new IDs in the DB, however, VIZ does not map them. Is is possible for VIZ to map the old player ID to the new player ID so all the players don't have to be remapped manually?

@Plethora777
Copy link
Owner

Can you send an example?

@Valacarnage
Copy link
Author

After doing some digging, this is less of an issue for me now as I've used another tool to sort out the player ids. Universal Minecraft Editor was a quick way to sort out the nbt data in this case.

Legacy PlayerID = 2018d51a-cc02-3e56-a372-a2431c0a677c

This record originally contained the user data, but now contains 3 entries as a pointer to the new player id:

MsaId: 5a775961-fc85-3ad3-b4b4-3cecc91d65ae
SelfSignedID: 2018d51a-cc02-3e56-a372-a2431c0a677c
ServerId: player_server_235966a2-b0d2-403e-b3ab-e333f2c53cd2

The new player ids are now created as: server_235966a2-b0d2-403e-b3ab-e333f2c53cd2

I have updated my cfg file to point to the new server_XXX player ID records, so it's not an issue for me, however, and as players join the world, a new server_XXX id is created for them with the old player ID pointing to the new record.

@Plethora777
Copy link
Owner

So player-id mapping is okay? Or not? I'd be happy to fix it / improve it, but I don't have an easy way to test it. So, I'd welcome specific requests here :)

@creuzerm
Copy link

WISHLIST item would be a separate file for PlayerIDs so we can easily move that file forward through the versions of this tool.

Old Legacy ID appears to be the same as SelfSignedID which is coming from a device?
This is a REALMs map, so the ServerID could be more stable long term?

The use case for this is trying to find our children when they wander off on the map and can't figure out how to get back to the main build areas. It's also useful to look into ender-chests for stolen items.

@JRTasel
Copy link

JRTasel commented Dec 27, 2018

This is also extremely useful for us larger Realm bedrock owners. Especially since we have 40+ members. Tracking down who is where is very useful when trying to piece together any griefing issues over multiple backups. And the ability to have a file that can be moved forward so we can add "player ID names" to make it more readable would be a godsend. If you need a file to work off with a bunch of Player IDs, let me know and I can grab one.
(Also let me know if we can ever donate in some way... this tool has been so useful over the years and ecstatic that it's working again!)

@Plethora777
Copy link
Owner

So how about if there was an optional config file called "playerid.cfg" that you would use like this:

player-id: the-long-string-in-the-data-file PrettyPlayerName

Does that solve all the things?

@JRTasel
Copy link

JRTasel commented Dec 27, 2018

I think that might work. In theory, player IDs should be unique and not change across realms/backups.

The issue might be how to translate that file forward. Perhaps when generating if it pulled from a "base" playerid.cfg file. Then when running the scan, it just copies the file and added new Player IDs to the copied file. And you could then just slowly update the base text file as you went along.

@Valacarnage
Copy link
Author

Would it be possible for the file to pull in all known player ids from the world file, and for the ones that we've defined, it carries those forward, and appends any new ids we haven't so we wouldnt have to hunt down new ids, simply add PrettyPlayerName in place of unknown.

@Plethora777
Copy link
Owner

Here's my idea to handle this in a simple way -- I'll dump any un-mapped Remote Players to the console log (the one you see in the GUI). This will keep it simple.

You can use mcpe_viz.local.cfg to store these and it will not be overwritten by new versions -- however, you will need to copy the file to the new executable dir each time there's a new release.

@Plethora777
Copy link
Owner

Pushed an update - give it a try

@Plethora777
Copy link
Owner

Is this solution working for folks? I'd like to close this ticket.

@Valacarnage
Copy link
Author

I was able to finally run the app without it crashing, so I can comment on this now.

I wasn't sure where to find the player id information at first. I eventually found it, through it was somewhat buried. However, it did work. Looking at this data, are these only the IDs not already defined by us in the cfg file?

@Plethora777
Copy link
Owner

@Valacarnage Yep it will only output un-mapped playerid's -- I'm unsure how the new playerid stuff works so it might be spitting out more than it should. I can add some smarts about which playerid's to output and which to not output.

BTW, the unmapped playerid's are output to the screen / gui so they should be easy to find :)

Let me know how it goes.

@Valacarnage
Copy link
Author

It may only be worth outputting the legacy player id if it has not been mapped to the new player id format. Otherwise this could get confusing. I created a new world to test this. a new play generated 2 of the old id formats, which both mapped to the new player id format.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants