Chests missing when upgrading world from 1.7.x to 1.8

its just that ur minecraft files got messed up a bit, itl happen when updating, not a bug, i dont beleive

First update that parts of the world have disappeared, I consider that a bug. Looks to me similar to this one https://bugs.mojang.com/browse/MC-66631 which apparently was incorrectly assigned as a duplicate of a bug where chests were invisible. To confirm, these chests are not invisible, they are gone.

Additional tidbit - one door was half invisible, required breaking and replacing.

Seems to me that this version is better described as 1.7 was - the Update that Changed the World. 😉

Further update. I restored the world back to 1.7.9, upgraded the server again to 1.8 (this time going through the 1.7.10 update first in case that was significant). Exact same issue, chests disappear, sections of the world corrupt.

The corruption is weird - as per the second attached picture, not only is some water removed, but the sand is turned to andicite.

I suspect that the 1.8 update was not tested on worlds with old terrain?

Can you attach a ZIP or 7Z of that world to this ticket or a download link ?
And provide the exact coordinates of chests disappearing.

Yes I can, but not directly, zipped up it is 450Mb. I will try to get it to you later today as a dropbox link.

Checked two other worlds with old (Alpha/Beta) terrain yesterday, and they appear to be OK, no corruption. So it's possible the corruption is limited to the one world. Will perform one more test tonight.

Confirming the chest problem: Many (probably older) chests just disappeared after the upgrade to 1.8. We've also rolled back and upgraded sequentially, but the chests disappeared again with 1.8.
Unfortunately the world is too large to upload anywhere - Peter, did you manage to upload yours somewhere?

MC-6726 talks about the same issue, and that one is a duplicate of MC-2548, so this one is too.

But if single chests are missing and the other structures like walls and frames are remain that speaks against a chunk reset.
Maybe the missing chests had some non-standard data value ?

I don't think this ticket and MC-6726 are duplicates of MC-2548. MC-2548 tells about complete chunk resets, while MC-6726 and this ticket only tell about lost chests (and some strange water behaviour), while the remainder of the world (e.g. the houses the chests were in) stays intact.

I agree that this bug is not a duplicate of MC-2548, but that would mean that MC-6726 is valid, and that this is a duplicate of that one.

Eventually. There's one difference between those bugs, though: MC-6726 had that error when migrating to MC 1.4.7. At least our world had no problems during that update, but is now breaking with 1.8. This may indicate that it's a different error. In any case a defect example world is probably needed first.

That's the thing Mojang never got. If there was an error several versions that got fixed, and then it pops up again several builds down the line, it's not a duplicate and it needs to be looked at again. They've always done this and hopefully now that Microsoft is the owner we can get some real programmers in on the job.

@unknown, @unknown said it may indicate that it is another bug. To keep the bug tracker clean, issues may be resolved as duplicates of others until enough proof has been found that they are seperate issues.

now that Microsoft is the owner we can get some real programmers in on the job

For your information, Microsoft is not planning on drastically changing the Minecraft team in the near future.

I did not upload my world, because I wasn't seeing anybody else had the same problem. Now I do, I'll try to upload it tonight.

Hello Kumasasa. The world is uploaded at this link: https://dl.dropboxusercontent.com/u/10365435/world%20-%201.7.9%20before%20update.zip. This is a 1.7.9 world.

Replicate the issue as follows:
Load this world on a 1.7.9 (or 1.7.10) server.
Tp 340 103 21. View chests.
Tp 336 109 21. View water.
Reload this world on a 1.8 server.
Go to the same Tp points - note missing chests and corrupted water feature.

These is only one location I have found with the corrupted water. However, multiple chests are missing in the more central locations of this world after the 1.8 upgrade.

Please can you confirm that you are seeing the same issues I am seeing? Thanks.

Can confirm with 1.7.10 / 1.8 single player.

OK, thanks. Should the Status be changed to Reopened?

Is there any way we can test if this issue duplicates or relates to MC-6726?

Not sure - all I can say is that this is the first time I've had this problem since the world was initially generated in Beta 1.x. MC 1.4.7 did not cause any problems.

After some research, I've gathered the following data points on this bug:

This appears to affect worlds created in beta1.7.3 and earlier.

Creating a world in beta1.7.3, placing a chest, and loading it in 1.8 results in a missing chest. Creating a world in beta1.8 or later, placing a chest, and loading it in 1.8 results in a still-present chest.

The bug appears to manifest in 14w26c and later, and not in 14w21b and earlier. (Among the versions available in the launcher, anyway.)

Of significant note, attempting to load the world in 14w25b causes the game to crash, with a rather telling crash report. (http://pastebin.com/RKRn6y1i for details.) Of particular note is the following:

java.lang.IllegalArgumentException: Cannot set property ayl{name=facing, clazz=class dt, values=[north, south, west, east]} to down on block minecraft:chest, it is not an allowed value

Examining the worlds using MCEdit, the only notable difference between a pre-beta1.8 chest and a newer chest is that the data value for the old chest is 52:0. According to the wiki, this is not a valid value. It should range from 52:2 to 52:5, depending on which way the chest is facing.

MCEdit does not show block states, so I don't know what the chests' "facing" state is set to, but based on the linked crash report I suspect it is set so something invalid.

Interestingly, loading a pre-beta1.7.3 world in beta1.8 before loading it in 1.8 results in a still-present chest, while loading a pre-beta 1.7.3 world in 1.7.10 and then 1.8 results in a missing chest. It seems that beta1.8 converts old chests into the new format (possibly only for loaded chunks) while later versions don't.

Great research, thanks Nathan.

The only thing I would add is that, in my experience, whether pre-beta 1.8 chests make it through the 1.8 update may not necessarily be predicated on whether they went through the beta 1.8 update. My world began in Beta 1.x - 1.3/1.4? I believe we did take this world through Beta 1.8 - I remember the chests reorienting themselves randomly after that update. Of those chests, I'd guess that 60% are now missing - so some survived the 1.8 massacre. 😉

Anyway, it does begin to look like old Beta worlds do not cleanly update to 1.8.

@unknown's analysis showed that this is not a bug in 1.8, but a bug in Beta 1.7.3

Hi Kumasasa,

I'm not convinced by that interpretation of Nathan's analysis. The bug appears to be in how 1.8 (specifically 14w26c and later) mishandles worlds first created in Beta 1.7.3 and earlier. If there was a support statement or something that worlds originally generated in Beta 1.7.3 and earlier are not supported on 1.8 or greater, then that would be something (though not great). However, as far as I am aware, that's not Mojang's current position?

I don't believe this is any fault of Beta 1.7.3 or earlier, but normal behavior of those versions. Back then chests didn't store their orientation, as evidenced by the fact that they would change their orientation based on which sides were up against walls (in those versions). Now chests store which direction they're facing in the world data.

The issue really is that 1.8 is not backwards-compatible to the old behavior.

Ok, see your point.

The issue really is that 1.8 is not backwards-compatible to the old behavior.

This also shows that MC-6726 has a different cause.

I've created a little script that can fix / convert the chests in broken worlds:
https://gist.github.com/Gargaj/2891b8fc558e01b8ddf2
(The chests might end up facing the wrong way.)

I haven't tried fixing doors but I'm assuming it's the same datavalue issue, so the fix would pretty much be the same as well.

Thanks Gargaj. I wonder if this is something that will get looked at? Probably it's too late now, we've moved on in our MP world, despite missing chests, and I suspect others will have also.

But, should this ever be assigned I'd ask that future upgrades be tested on old worlds - some of us just keep building on what we have from a long time ago!

Gargaj, I'm having this exact same issue. It took a lot of searching to finally come across this thread. How/where do I run that script you wrote to fix the chests in my broken world?

Tyler: It's a C# program that's built on https://github.com/jaquadro/Substrate

for further infos, you might wanna check out this thread.. http://www.minecraftforum.net/forums/support/unmodified-minecraft-client/1868459-all-items-in-single-player-survival-world?page=2
/
thanks gargaj, you certainly helped me a lot

Yesterday me and my flatmate struggled to get Gargaj's script to work. When the scripts processed our world, it crashed with a NullPointerException when trying to access chunk.Blocks.XDim in some chunks. If this also happens to you, we found two solutions to this problem:

Solution 1 (the safer one; requires having a backup copy of your world before conversion to 1.8):

• Make a copy of the backup copy somewhere; say, C:\world (so the script doesn't modify your backup in case something goes wrong).

• Run the script on that.

• Voila, everything should be OK now. If the script crashes even when you run it on < 1.8 world, you can try solution 2 (below).

Solution 2 (the less safe one):

• Use this modification of Gargaj's script (I added a condition to this script that skips the chunks for which the script crashes, but because of that I can't guarantee that all of the chunks you'd want processed will be processed. I didn't read into why for some chunks chunk.Blocks == null; this might be a bug in some worlds or in Substrate, or maybe just the way Minecraft works).

Attaching a world that was first created years ago, last played also years ago. Steps to see this issue:

1. Upon selecting this world, it will convert to the newer format.
2. When the game starts, it takes about 10 seconds to the world actually start rendering.
3. When it finally renders, the player is stuck (this is another bug!). The player needs to break the two blocks in their feet to get unstuck and start moving.
4. Right where you start there should have been a lot of chests, but there are none. Also, if you walk forward in the same floor, you will see a downwards stair leading to a double door, but the door on the left will be glitched (this is the "half-door" has also been mentioned earlier in this issue report).

Opening in 1.7.2, 1.7.4, 1.7.10 seems to work fine.
Opening in 1.8 or 1.8.1 is broken, and has the behavior described by this issue.
Opening in 1.7.x and then opening in 1.8 also reproduces this bug.

So, this bug is related to the conversion to 1.8 format.

Yes, I think this one is confirmed now - though I suspect it's never going to be fixed, too late now for most of us. However - it would be good in 1.9 or something to change the upgrade to properly handle old chests, so that dusty worlds we have hanging about from years ago at least could be upgraded to a new version without corruption.

I changed the title to more accurately reflect the problem - Chest are missing after upgrade from 1.7.x to 1.8, not Beta version to 1.8. The worlds that are affected by the upgrade corruption are a subset - those that were initially created prior to Beta 1.8.

If someone wants to try the script written by Gargaj, I'm attaching a compiled version. I used Visual Studio Community 2013 to compile both Substrate and Gargaj's script into a .NET 4 executable.

I also made a video showing this bug in the World1 level attached to this issue: https://youtu.be/BZoom0KzE9g

Mojang developers: it would be great to have this fixed, if not for 1.8, at least for 1.9.

Fixed somewhere between 1.8 & 1.8.8. (Haven't tested with a server)

I made a new .minecraft directory, I created separate worlds in 1.7.2, 1.7.9 & 1.7.10, made a copy of all of them, then updated to 1.8.8. None of the worlds had any corrupted chests.
I then updated to 15w45a. All the chests in the copied worlds were good, and the worlds tested in 1.8.8.

The affected chests were not created with any 1.7.x version, but in way older versions. I don't think anybody researched the exact version where the chest behavior was changed, but https://bugs.mojang.com/browse/MC-70813?focusedCommentId=202853&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-202853 explains the technical problem (i.e. the way chests are saved seems to have been changed somewhen, and since version 1.8 Minecraft is not able to understand the old format any more, though it's still present in the maps for old chests).

Thus marking this problems as fixed is definitely not correct - but I guess most people won't care about a fix any more because they either lost their data already or converted the map in the meantime (e.g. by using one of the attached scripts).

I've just tested the attached "World1" on 1.8.8. The bug is still present, it is NOT fixed. Please reopen this issue.

Video: https://youtu.be/-R3NcdsBY0g

Snippet of the game output log:

[21:10:04] [Server thread/INFO]: Starting integrated minecraft server version 1.8.8
[21:10:04] [Server thread/INFO]: Generating keypair
[21:10:04] [Server thread/INFO]: Converting map!
[21:10:04] [Server thread/INFO]: Scanning folders...
[21:10:04] [Server thread/INFO]: Total conversion count is 4
[21:10:05] [Server thread/INFO]: Converting... 20%
[21:10:06] [Server thread/INFO]: Converting... 25%
[21:10:08] [Server thread/INFO]: Converting... 55%
[21:10:09] [Server thread/INFO]: Converting... 66%
[21:10:10] [Server thread/INFO]: Converting... 88%
[21:10:10] [Server thread/INFO]: Preparing start region for level 0
[21:10:10] [Server thread/WARN]: Wrong location! (3, -10) should be (3, -11), uq['Painting'/52, l='World1', x=58.50, y=80.00, z=-159.97]
[21:10:11] [Server thread/INFO]: Changing view distance to 12, from 10

I did a comparison of opening "World1" in several Minecraft versions: https://youtu.be/-ck2NcqBIPA

Opening it in 1.0 or 1.1 works fine, besides some lighting issues.

Opening it in 1.2 will convert the format to Anvil. There will be some lighting issues as well, and the doors will be placed in the wrong orientation (i.e. using a different logic than in earlier versions). However, the orientation of the chests is correctly fixed during the conversion.

Opening it in 1.3, 1.4, or any version up to 1.7 has the same results: the conversion will not correct the orientation of the chests. The door conversion seems to be the same as 1.2 (i.e. wrong orientation).

Opening it in 1.8 has disastrous results. All chests will be gone, several doors will be glitched, and the paintings will be dropped from walls. Also note that I had 3 paintings hanging on walls, but only 2 were to be found inside the room. I suspect the third one was dropped elsewhere, at the wrong location, possibly behind a wall.

If I first convert the world in 1.2 (the only version the corrects the chests orientations), and then open the 1.2-converted world in later versions, at least the chests will be preserved. The doors will still have the wrong orientation, and 1.8 will still have the same issues (glitched doors, dropped paintings, spawning inside a block).

Yes, it's not fixed, but at the same time after a few months languishing in bug limbo, we figured out it was never going to get fixed. Onwards and upwards to the next bug! 🙂

I'm curious, I see Mojang have Resolved this issue, marking Resolution as "Done". What was done to fix this one?

Changing resolution to Fixed.

To be clear, the resolution is to open the world in the latest version, today it's 1.15.2