kiddailey
Comments
There is also a level.dat and level.dat_old after the backup and I can see the primary difference is the lack of a "player" node in the new dat file. It appears that what might be happening is that Singleplayer expects inventory to be in the level.dat rather than in the player data folders based on UUID. I don't remember it being this way with backups in the past, but that would explain what's going on here.
Maybe the fix is to somehow move the NBT player data from the UUID file to level.dat? Or run the backup on an online server instead. Hopefully someone can help confirm. In any case, these seems like it's a big issue for any non-technical people.
Just wanted to post an update after about a week or so and let you guys know that everything has been smooth since your last message and we've not had any more issues. Hoping it continues. Thank you!
As of last night, no - we had a crash again after restoring from a backup. It was stuck in "FIXING" mode for at least 30 minutes.
I've been testing off-and-on today and no major issues yet. However, earlier tonight I did have some odd game tick-lag that occurred suddenly. I immediately disconnected, waited a few minutes to unload the chunks and after reconnecting it appeared to have resolved itself. I'll keep my eye on it.
Wanted to add a note that this has also happened multiple times to a few-years-old Realms server that a few friends of mine and I play on.
The first time it seemed to fix itself with no issues
Right before it happened the second time, I noticed that the server began to spontaneously replace blocks as I mined them. Not one-at-a-time, but in batches. In other words, I would mine 20 blocks and then it would suddenly replace the last 10 mined – sometimes even catching me inside them if I happened to move to a location where blocks had just been removed. Chests also took many seconds to display their contents. After I was disconnected, it fixed itself with no obvious issues.
The third time it happened, after reconnecting I discovered that all of the chunks that were loaded around me were completely reset to their initial world-gen state. In addition, my inventory was missing some items and because the world had been reset, I spawned in a block that had been previously removed.
After the chunks had been reset this time, we restored from a backup and it seemed to work. However, two days later it then happened a fourth time and the server became unavailable, stuck displaying the "stuck in FIXING" error message. As I type this message, it is still stuck.
I'm attaching screenshots of some of the error messages we saw for reference.
This is in a freshly generated 1.13 world. I also see that there are at least three duplicates of this issue here in JIRA, some of them reporting the chunk-resetting problem that we also experienced. This suggests that it isn't an isolated issue and it's serious. For that reason, I will not be playing on the Realms server anymore until the issue is resolved for fear of making this worse 😞 I have instructed the owner of the Realms server to submit a support request.
Edit: An additional note that the server eventually came back, but had reverted to its state a few hours prior :/
Thanks for keeping me in check 😃 I need to get better searching apparently.
Confirming Scott Miller's finding and also adding that it exists in the latest snapshot for 1.13 (18w20c)
I actually came to the bug tracker to report the same issue and stumbled upon this. Recently, I was attempting to move a Wither Skeleton into The End in 1.12.2 (and to an End City in pursuit of the "How Did We Get Here Advancement") and wondered why it would not move and instead simply flailed its arms around. The initial spawn point in The End happened to be underground. I moved the skeleton manually out into the open but the behavior was the same and I eventually had to use mine carts or boats to move it.
For 1.13, I didn't manually move a wither skeleton into The End, but I did reproduce the bug easily in creative mode with similar instructions to the original report:
1. Build a 3x3 shade platform 4 blocks above the ground
2. Spawn a wither skeleton under the shade platform
3. While near the skeleton but out of reach, switch to Adventure mode
At this point the skeleton should "do the dance" and not move out into the open
Notes:
If you spawn the skeleton in the open area, he will behave normally
If you spawn the skeleton in the open area, but then cover him in shade, he will still pathfind normally and leave the shade
If you spawn the skeleton under shade, he will not leave the shade
If you spawn the skeleton under shade and remove the shade, he will pathfind normally in 1.13. However, as I mentioned, this was not my experience in 1.12.2 so I'm not sure if it's been partially fixed in the 1.13 snapshots or there's another issue at play.
After some testing, I can confirm that if you set up a Minecraft server, copy the Realms backup into the server folder, rename it to "world" start and then and connect to the server, all player data and positions are maintained as expected.
This is unfortunate. I would expect the Realms account holder to be able to make a backup, login locally to that backup and see their player data retained. Instead, it appears you now have to set up a server instead.
I think the fix here is to have the Realms system set the "local" player data in the backup to either the same as the person making the backup (if possible) or the Realms owner at the very least.