A couple of times, my son who joins (LAN) my single-player adventure mode games, shows up and his stuff is gone and (sometimes) his achievements are reset. As the host, I have never lost my stuff or achievements.
The first time it happened was after the upgrade from 1.7.8 to 1.7.9 so I restored a backup save and set all of our PC's to stay with 1.7.8. That worked for a month or two but last night I played by myself and I noticed the launcher took a very long time to load. I'm not sure if this is related. When I started playing I did confirm that I was still playing in 1.7.8. This morning, when he joined me, his stuff was gone again and so were his achievements.
Any idea what's up? I do fairly regular backups but I still hate losing a few hours of progress each time this happens.
The launcher taking time to load usually involves the launcher updating itself, and there have been two new versions of the launcher this week (1.4.3 and 1.4.4).
Your son's stuff is stored in the game directory of the world you are playing at ".../saves/<save name>/players/<something>.dat"
Where "<something>" identifies the guest player's account.
There are a couple of different things that could be in play here. It may make a difference if you or he or both or neither are playing online or offline (I'm not sure). There's also a change being made in the latest versions of minecraft to allow people to change their names, this means that instead of identifying an account by it's name (which might change), the accounts will be identified by an unchanging identifier string (something that looks like "550e8400-e29b-41d4-a716-446655440000". For a LAN game I'm not sure if this depends on the host's version or the guest's version, so you might want to make sure that your son is also still on 1.7.8
I'd take a look at the contents of the players directory and see what can be seen there. You might be able to tell if there are both name based and uuid based files in there, or an unexpected filename (like a generically named player1.dat)
If you need to restore from backup, you can just try restoring your son's file in this directory and not change anything else in your save.
The last thing to think about is that when you are done playing it might be important that your son disconnects before you shut down minecraft so that his saved data is all up to date.
I think you're right, the pause is a launcher update and for this problem, it's just a red-herring.
I did a bit more digging. Using NBTexplorer (great tool!) I can see that the uncorrupted backup save has three entries in the playerdata with the random strings as you mentioned. There are also three entries in the "players" node that match the usernames of me and the two kids. On the "corrupted" save, there are FOUR entries in playerdata (I suspect my "empty" son is the new entry) but there are still only 3 appropriately named "players". So it looks like sometimes when he joins he gets a new playerdata entry and the old one remains but is not hooked up to a player anymore. So when I encounter this problem I should be able to delete the new playerdata file (noting the file name) and rename his old file with the more recent file name.
That should restore everything, including his inventory, assuming it got saved properly last time we quit. There doesn't appear to be any corruption with his data when I look at it with NBTexplorer.
That's the recovery, as for preventing the problem going forward, how does he end up getting a new identifier string if it's "unchanging"? And why does he *not* get that new string when we play from the backup? How are the player identifiers generated? It seems like the variables UUIDLeast and UUIDMost are involved as well.
Thanks again for your help with this.
EDIT: I also found the save from the last time this happened, and it has the same new playerdata string. So sometimes he's 5bfd(etc)... and sometimes he's 9ac5(etc)....
Well the UUID thing is new, i.e. it's in transition. Older versions don't use it, newer versions do, so you could see a problem when changing versions. The UUID thing is also per login, so if your son isn't being careful about the logged in account, he'd see different UUIDs. Judging from past issues, I'd guess that the primary problem is whether or not he's playing "online" or "offline". This difference used to cause trouble with people's tamed animals (dogs, cats). But that's just a guess.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
A couple of times, my son who joins (LAN) my single-player adventure mode games, shows up and his stuff is gone and (sometimes) his achievements are reset. As the host, I have never lost my stuff or achievements.
The first time it happened was after the upgrade from 1.7.8 to 1.7.9 so I restored a backup save and set all of our PC's to stay with 1.7.8. That worked for a month or two but last night I played by myself and I noticed the launcher took a very long time to load. I'm not sure if this is related. When I started playing I did confirm that I was still playing in 1.7.8. This morning, when he joined me, his stuff was gone again and so were his achievements.
Any idea what's up? I do fairly regular backups but I still hate losing a few hours of progress each time this happens.
Your son's stuff is stored in the game directory of the world you are playing at ".../saves/<save name>/players/<something>.dat"
Where "<something>" identifies the guest player's account.
There are a couple of different things that could be in play here. It may make a difference if you or he or both or neither are playing online or offline (I'm not sure). There's also a change being made in the latest versions of minecraft to allow people to change their names, this means that instead of identifying an account by it's name (which might change), the accounts will be identified by an unchanging identifier string (something that looks like "550e8400-e29b-41d4-a716-446655440000". For a LAN game I'm not sure if this depends on the host's version or the guest's version, so you might want to make sure that your son is also still on 1.7.8
I'd take a look at the contents of the players directory and see what can be seen there. You might be able to tell if there are both name based and uuid based files in there, or an unexpected filename (like a generically named player1.dat)
If you need to restore from backup, you can just try restoring your son's file in this directory and not change anything else in your save.
The last thing to think about is that when you are done playing it might be important that your son disconnects before you shut down minecraft so that his saved data is all up to date.
I think you're right, the pause is a launcher update and for this problem, it's just a red-herring.
I did a bit more digging. Using NBTexplorer (great tool!) I can see that the uncorrupted backup save has three entries in the playerdata with the random strings as you mentioned. There are also three entries in the "players" node that match the usernames of me and the two kids. On the "corrupted" save, there are FOUR entries in playerdata (I suspect my "empty" son is the new entry) but there are still only 3 appropriately named "players". So it looks like sometimes when he joins he gets a new playerdata entry and the old one remains but is not hooked up to a player anymore. So when I encounter this problem I should be able to delete the new playerdata file (noting the file name) and rename his old file with the more recent file name.
That should restore everything, including his inventory, assuming it got saved properly last time we quit. There doesn't appear to be any corruption with his data when I look at it with NBTexplorer.
That's the recovery, as for preventing the problem going forward, how does he end up getting a new identifier string if it's "unchanging"? And why does he *not* get that new string when we play from the backup? How are the player identifiers generated? It seems like the variables UUIDLeast and UUIDMost are involved as well.
Thanks again for your help with this.
EDIT: I also found the save from the last time this happened, and it has the same new playerdata string. So sometimes he's 5bfd(etc)... and sometimes he's 9ac5(etc)....
weird.