Dan Walkowski
Assigned
Reported
Comments
I have found a reproducible case!
I have a remote player that I ran some tests with, and this error occurs only when viewing a large number of animals. For example, I have the remote player connect, and stare at a blank wall or simple, non-moving scenery. They can stay connected for longer than we felt like waiting, 10-15 minutes at least. Then I had them spin 180 degrees and look out and down from their elevated house at three full pens of animals, and within seconds they are disconnected.
This happens every time, seemingly independent of connection speed. And the animals freeze in place just before the disconnect.
Ah, I apologize for submitting a dupe. I did a search before posting, and wasn't able to find anything similar.
Connection Lost Internal Exception: io.netty.handler.timeout.ReadTimeoutException
I have had similar bad results when teleporting beyond a certain distance.
/tp to somewhere 'close' (<100 blocks) works reliably, but /tp to someplace 'far' (>100 blocks), often doesn't load any of the chunks at the destination. Disconnecting from the server and reconnecting will show you in the right place, and the chunks will be loaded. (addendum: this is when using a Command Block)
This is not a game-breaking bug, but it is incredibly ugly. And I reported it months ago on the old bug-tracking Wiki page:
[X] Blocks under an overhang are completely unlit, since 1.3.1. If you move under the overhang, the lighting will be corrected, but only until you logout. Happens with OpenGL and without. Screenshot [3] Robotic Pants
I'd really like it to get fixed. It annoys me to see huge black rectangles all over the mountains.
I am using a 15" Retina MacBook Pro, which has NVIDIA GeForce GT 650M 1024 MB.
Minecraft works fine with no external monitor attached, but if one is attached, and made the primary monitor, then running Minecraft on the laptop screen (which is now the secondary monitor) crashes every time when using 't' or 'e', and likely others. From the crash log, you can see it is failing in AWT getCursorPosition, so it is likely making some incorrect assumption about which screen is primary, and the origin of the screen coordinates.
I noticed those watchdog messages, saying it took more than 60 seconds for a tick.
But there is clearly a deeper issue going on, since this happens with a single client, talking to a dedicated server in the same room, using direct connect. This implies performance is atrocious.