Still experiencing this issue in 1.15.2 (banners were generated in 1.14.4).
Videos are attached.
It appears that one set of banners has the NBT value `tab.BlockEntity.id` while the other banner lacks this value.
Note: It appears that the banners can be fixed by placing the banner on the ground, and mining it. This makes it so the banner does not have `tab.BlockEntity.id` attribute. (Works in 1.15.2, but does not seem to work in 1.14.4).
Has anyone else experienced the MC-156013 while using a patched version (the current Paper Minecraft)?
I did experience issues with mining straight down, but I can't seem to recreate that problem.
Perhaps this is actually a workable solution after all?
Under lag (~100ms) this does seem to re-add MC-156013. It does not seem to have a problem under normal conditions however.
The latest server version form papermc.io already has this patched. For those of you looking for a fix now.
Again the code fix is here. https://github.com/PaperMC/Paper/pull/2396/files
(Full disclosure, yes I patched it.)
I found a solution. The patch is here. https://github.com/PaperMC/Paper/pull/2396/files
I used the same fix as MC-5694.
I have only tested this on [Paper | https://papermc.io] but I expect this will work on vanilla Minecraft as well.
Can confirm. 1.14.4 Pick with Efficiency 5 mining ice.
Affects 1.14.3
Occurs on Farmland and Grass Path as well.
I can confirm that this issues also appears in Windows 10 (Minecraft 1.12.2) when open to LAN with cheats off.
However, even if I (the player running the server) can confirm that I still have cheats, I can not bring up the menu on a structure block.
Importantly though, a second player joining the server (in creative mode) could assess the GUI on the structure block.
It is interesting to note that this second player could not place structure blocks, despite seemingly being the sole player capable of operating a structure block.
The dx, dy, and dz target selectors are not currently supported. As-of 1.0.5 and 1.1, the supported target selectors are:
x
y
z
r
rm
name
type
m
It seems the game no longer updates the TIME
uniform; its value is always 0. Consequently, any shaders which rely on that uniform for animation appear "frozen".
This seems to be fixed in 1.0.5. I'm not sure which build fixed it.
This issue seems to be fixed in 1.0.5.13.
Added a second crashlog from 1.0.5.3 with unrelated processes filtered out. Should contain a bit more information about the crash than the first log.
This same issue still occurs with the 1.0.5.3 beta build. Reinstalling the app doesn't fix the issue, nor does clearing cache or data.
Attached a crash log containing the main stack trace. Device is a rooted Samsung Galaxy S5 on Android 4.4.2. The error stems from line 178 of the MainActivity.java file in the onCreate method; the exception is:
NullPointerException: package name is null
This is a duplicate of MCPE-11418. The developers have stated before that they have no intention of fixing issues that occur when teleporting past a certain distance. Under normal playing conditions, there is no way this would be a valid issue for the vast majority of players; it's highly unrealistic to expect players to reach 4 million blocks from the origin in normal play without explicitly teleporting to those locations. On top of that, there is no easy or practical way to fix the issue; it's a limitation of the both the platform the game runs on and the game engine itself.
The reason for this is because of floating-point precision. This can be remedied by using high precision floats in the fragment shader for certain variables, though this fix doesn't work for older devices that don't support highp floats in fragment shaders.
Here is an example screenshot after applying this fix: http://i.imgur.com/lUcEyro.png
Oddly enough, this also fixes the crash when viewing end portals/gateways in non-fancy mode.
One last thing worth mentioning:
Go to the Windows 10 Settings app
Find Mouse & touchpad settings
Under Touchpad settings, make sure the "No Delay" option is selected like so: http://i.imgur.com/YbnRqdS.png
From the crash log, it looks like the error was an UnhandledException that occurred somewhere in the OptionsItem::render function. The error happens at or before the call to destroy string. Not sure why it happens, but hopefully that info is useful to staff.
I had a ghost dirt block occur on a server, with the client and server both running on the same physical machine. (Eff 5 shovel of course).
So it can clearly occur on low latency connections as well. Still rare, I got it this once but I could not cause it again.