mcpe_viz
mcpe_viz copied to clipboard
Plethora777
PlayerID has changed
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?
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.
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 :)
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.
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!)
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?
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.
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.
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.
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?
@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.
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.