Travis Watkins
Assigned
Reported
Comments
Doing whole chunk updates after a certain threshold is meant as an optimization. It can be very expensive in bandwidth and CPU to transmit lots of block changes and modify the chunk mesh for them. At a certain point it's cheaper to just resend and rebuild the whole thing.
Not all Intel GPUs have this issue, please don't take away my performance improvements. Intel HD3000 on OS X works fine.
Seeing the same thing on OS X.
I believe Dinnerbone mentioned, back around 1.4 or 1.5, all chunk sections below the heightmap are now always created because of this issue. I'd have to do some checking to make sure but if that's the case wouldn't this just be MC-7508 now? Specifically, is the problem that the heightmap (really it's a lightmap, ignores transparent blocks) is broken or does this still always happen regardless of what the heightmap is? To test that I suppose you'd want to test a more vanilla-like environment where you're carving a hole deep underground. The key point is that you have a lot of ground above your hole, at least 16 blocks.
Closed since the reporter says the problem is fixed.
No one said that error can't happen in vanilla, that's why the ticket is still open. Dinnerbone was saying the "pretending to 1.7.8" error can't happen in vanilla.
The client verifies the skin blob exists, that it is signed and the signature is correct, that the blob hasn't expired, and that the UUID and name in the blob match what is in the packet. You couldn't pretend to be Notch unless he was on your server.
You bring up the server being able to hold back a skin update (currently for up to 24 hours) and in the same comment suggest the solution to this problem is to not have an expiry?
They've stated they don't want the server to be able to screw with the skin in any way so what other option is there?
Since this is intentional to avoid the server faking or withholding a player's skin I'd suggest a non-avoidable kick somewhere around 24 hours after the player has joined the server.
I have in the past (beta 1.7) seen this problem or something very similar to it with just some redstone wire and torches hooked up to pistons. No clocks, it was just all wired to a lever to open/close doors to let combatants out of their rooms. Breaking a random piece of redstone or torch would solve the problem even if you put it back right away. It was a different piece each time though so you'd end up tearing the machine apart each time.
In this case the server kept working just fine, no extra CPU usage or anything. The clients in the area though had low FPS and would end up "falling behind" in chat and such.
This only appears if you've pressed F3-H to turn on showing extra item info. Previously this showed the item ID (and still does) but the name is meant to replace the ID in the future so it makes sense that it would be shown as well.
Logging to html file would be a log4j thing, not a minecraft thing.
People who have this issue with something other than ocelots (since that is a separate issue) should upload a copy of their world (or a small enough subset of their world that still shows the issue). Since this is likely some kind of corruption knowing what is corrupted and how would be extremely helpful for fixing it.
This is a CraftBukkit issue.
He already filed MC-657 about that issue so presumably he was trying to describe something else here.
This is an intentional difference in the two buttons.
Was this on a server? Some people have modified 1.3.2 servers to work with 1.4.2 which can cause client crashes like this when doing certain actions.
Minecraft has two light values: sun light and block light. The sun light value never changes as that would be very expensive. This is how it worked before beta 1.8 and sunrise/sunset were laggy.
The game knowns to ignore sun light values during the night for spawning and such so there is no problem with this setup. It even uses the sun light values for deciding where and how intensely it should render the blue "moonlit night" shade for a world instead of just pitch black darkness.
The other report has the actual issue triaged and has a Mojang developer assigned to it. To make it a duplicate of this we'd have to copy that description over here and mess with who is assigned to what which we don't like to do. As for the duplicates of this being moved to duplicates of that, yeah, that should probably be done.