Nathan Roberts
Comments
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.
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.
I play on PC Oculus Rift and the inventory and menus always appearing behind stuff is giving me headaches.
[media]It doesn't seem to matter how close or far way I stand from something before I try to interact with it, the UI still seems to be partially or wholly behind/clipping into geometry. Yes, it is now partially transparent but even so it's still basically impossible to see what is going on 90% of the time. The only time the UI appears fine and unobstructed is when I'm in a completely open area with no blocks within about a 16 block distance in front of me. This is unacceptable for a game as huge as Minecraft.
Why can't you simply give VR users an additional option in VR Settings named something like "HUD Z-Distance Offset" that allows us to set the default Z position of the HUD to be closer (or further away)? If the HUD was drawn just a bit closer to my face than it currently is, it'd be much better in 99% of cases.