Michael McIntyre

Pierre,

I appreciate where you're coming from on this, but the problem is so many users aren't sophisticated enough to know what's happening when they get this error message. All they know is the game stops working and something incomprehensible pops on the screen. Your analogy to the car is flawed in that the majority of car users can identify when they've been in a wreck. A better analogy is the car simply stops running, an ambiguous light appears on the dashboard, there is no reference to this light anywhere in the owner's manual, and the car won't run again after that. Most peoples' next move is to take the car to someone who can fix it. In the case of a car, that's a mechanic, but in the case of a game, who do you take it to?

I agree, it's not a 'bug' but for a typical, unsophisticated user, it's simply the game ceasing to work, which to them is synonymous with 'bug.'

Maybe the 'bug' should be that io.netty.handler.timeout.ReadTimeoutException fails to provide meaningful error message to the player. I don't know enough to know if Mojang can edit this screen, but something along the lines of: "OH NO! Minecraft has lost communication with the server! Please check your network connection or contact your server administrator."

I used to have this problem back when chicken jockeys were causing chickens to live in dark places, laying eggs for zombies to pick up and never despawn. My friend who hosted the server couldn't find the root of why the server couldn't keep up with Minecraft, either. We think it just had something to do with the zombie pathing algorithm running amok and since we systematically cleared out the zombies, it hasn't been so bad in a while.

But I, as a relatively ignorant player, see this as a game flaw too. Can there not be some sort of fail safe put in place for when the server can't keep up enough to avoid a timeout? I can understand if the issue is in the player's connection, but if the game starts trying to run faster than the system running it, what's supposed to happen? And shouldn't there be a mechanism for recovery? Many people find that they alone can no longer log back onto a server, EVER. Shouldn't the server be able to drop them, recover, then let them back on at some point in time? It seems (to me, again, pretty ignorant, but just thinking logically) that this is a flaw in the way that the game handles itself.

Can someone explain where I'm off base?

I starting following Grum's Twitter feed (this issue is assigned to him). On there, he was recently claiming there was nothing to fix, that it was network issues causing no data in the packet. As of this morning, he seemed to embrace that it might be a bug but that they haven't been able to reproduce it, so there's nothing he can do. (Thus the recent comment on here looking for a way to reproduce it, I presume.)

I haven't been able to determine the exact factors that contribute to this happening, but what Kyle Tuft wrote earlier today looks to be very similar to what I've seen on our server.

EDIT: I see Kevin van der Burg beat my comment with a reproduction of the bug! Well done, sir! Well done indeed! I just wish I spoke Dutch or whatever it is so I knew what you were saying.

I can't run proper stress tests, but this is almost certainly related to world travel on the server I play on. Every time this bug hits, someone who was logged on reports "I was on a minecart in the nether" or something similar.

I built a nether cart track to a portal to a mesa biome. This is strictly off limits because going to that portal triggers the bug seemingly without fail.

It is terrible for me. Boats have been literally unusable for me since 1.7.1. Once I floated off the edge of the world - there was no chunk there, only waterfalls into the void. All the other time I try to ride a boat I can get a few chunks away and then suddenly snap back to where I started (or close to it) and the boat breaks. I can only enter, ride, and exit a boat successfully if I stay within a couple chunks of where I start. Playing on a server in vanilla 1.7.4.