Amaranth (Travis Watkins)
- amaranth
- amaranth
- America/Chicago
- Yes
- No
MC-5413
doFireTicks off doesn't always stop firesArrows still set players on fire with doFireTicks
Leave me alone you NPCWolves and ocelots spawn rapidly near player
duplicates
is duplicated by
Anvil BugAnvil rotates when falling through torches
The ScreenScreen blank when connecting to server while fullscreen
duplicates
is duplicated by
Inventory Disables GameCrash in LWJGL when opening inventory
![[Mod] Torabi](../../../data/assets/gravatar/torabi.png){kind=small}
Which resolution is chosen for an issue has little to no consequence, which is why we're open to changing them if we think it best reflects the situation. "Works As Intended" and "Won't Fix" both mean "don't expect it to change". The only difference between them is whether Mojang considers the behavior a bug or not.
The lag is not intended, and the resolution of this issue should not be interpreted as such. It's simply an unavoidable consequence of other intended behavior. In this case, WAI means "Can't Fix", whereas "Won't Fix" would imply that it was possible to fix, and they did not want to for some other reason. TANSTAAFL. Computation requires time and memory. If you change a bunch of blocks, that information has to be processed and transmitted. Light and culling have to be recalculated. As Amaranth (Travis Watkins) so concisely explained, the current implementation is the most performant solution to the issue that they've been able to design. It may not be the best solution possible, and they may discover a way to improve it in the future, but it's the best they can do at this time.
This is indeed fixed in the 1.4 client.
The doFireTicks game rule is meant to control blocks burning, not entities. I'll leave this open though in case a Mojangsta wants to change that.
As mentioned, books need leather now. See the wiki for details.
I wonder if it is rotating back the way it should be. If so,
MC-196being fixed should mean this is too. We'll have to see once a version with that fix is released.Are you trying to connect to a 1.3 server?
As mentioned, this is a duplicated of
MC-54and is thus being closed.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.
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.
This is an intentional difference in the two buttons.
He already filed
MC-657about that issue so presumably he was trying to describe something else here.This is a CraftBukkit issue.
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.
Logging to html file would be a log4j thing, not a minecraft thing.
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.
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.
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.
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?
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?
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.
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.
Closed since the reporter says the problem is fixed.
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-7508now? 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.Seeing the same thing on OS X.
Not all Intel GPUs have this issue, please don't take away my performance improvements. Intel HD3000 on OS X works fine.
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.
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.