Breaking / placing / changing blocks has a delay to disappear / appear

Confirmed for a few seconds.

This is very similar to, if not the same as, MC-62164.

Tested a bit more. I have a case were it gets destroyed instantly when breaking it. and after a few seconds it reappears again. Even /setblock to air doenst solve it and the block is continuously reappearing

I only get it for 1-2 seconds, but my friend gets it for much longer.

Happens even when VBO is off for me.

same here... as soon as we updated to 14w29b. block destroyed act as they should and drop stuff, but visually remain, making it impossible to see the holes you just dug. also door will often open, but visually they look like they are closed, even touches, if placed, you will see the flames but not the torch itself. the world is updating physically but not visualy

Confirmed, it's a really bad bug. Also, when placing blocks they sometimes not appear at all forever, or appear after a few seconds, and yes, light levels don't update correctly when placing light sources... (Also I don't know what VBO is)

Think i found a fix. Leave the server updated, but roll the client back to 14w29a. let me know how this work out for you all.

this happens for me too

Issue does not relate to VBO

Can confirm, survival, with breaking blocks.

Confirm this, this does also happen to me on interacting with doors or other blocks. The door graphically stays shut, but i can walk through it. Sometimes, it fixes itself after a while.

This is the whole refresh issue as well. My ticket was also added. If you also mine the blocks does not remove either. It takes about 20 seconds after it is mined for the block to be removed.. Doors is affected as well as other stuff. If you go in a then the problem does not happen and suggest players goto a to avoid until a patch is released in next snapshot.

http://www.youtube.com/watch?v=jz77EXGnHRQ

Turing off VSync temporarily fixed it for me!

Turning vsync off does reduce the delay but it's still there for me..

For me this bug only occurs if I am moving. Blocks are broken/placed/changed without problems as long as I am standing still.

And I had VSync turned off when I discovered this issue, so turning that off is definitely not a fix.

Okej...I found it because I've forgot to turn on VSync and then saw it...

confirmed, when that happens, you can't see any blocks you break/place, and reloading the world makes everything invisible exept for entitys

@Andrew Same thing with me. I noticed this yesterday. They have moved this to confirmed.

Okey dinnerbone and themogminer are now known with the bug. Infact, I just got sarcastic response from him :/. https://twitter.com/TheMogMiner/status/489802675090124800

...sorry, but I would answer the same way. Of course this has been acknowledged by the Devs. It has been duplicated over 50 times....

@Galaxy_2Alex Yeah it has, but one of them ("MC-62208 Possible render glitch" https://bugs.mojang.com/browse/MC-62208) is not a dup.
It's totally another type of bug,.
You marked it as a dup when you marked my version of this bug...

back in 1.3 or 1.4 there was a massive performance drop. It was duplicated tons of times. After 6 weeks jeb finally noticed it and made some snapshot builds for us bugtrack guys to try out because he, nor the other devs could reproduce it. Besides, normally when something obvious gets reported with lots of dupes the devs tweet out they are aware of the issue, now they didn't. And despite all I still don't think you should respond this way to a simple question.

Also starting new worlds, chunks and blocks will not visually load up, I fixed mine when I went around and went through a small tunnel.

The blocks staying in the world after breaking them, this happened when I opened a previously generated world. It happened to coal ore for a brief moment. It was bizarre. They did vanish after a slight lag from loading. I've only seen that happen once before back in 1.7.2 i believe it was but don't hold me to that 🙂

Dup by MC-62422

Possible Workaround

Turning off VBO could solve the issue, according to MC-62445

ESC -> Options -> Video Settings -> Use VBOs: OFF

@Blah I vanaf confirm that, I have VBO off, and the problem isn't solved. The same thing happens

Yeah, turning off VBOs temporarily fixes it. As does turning it back on. As does changing the render distance or one of many other settings. It's the change of a setting making the game re-render the world, not an effect of a particular configuration.

This is not the same issue as MC-62164. For me, MC-62164 only happens when my system is bogged down by high render distances. It goes away at lower distances.

THIS ticket, MC-62166, however, shows up even at low render distances.

Okay, is this the bug it is talking about?: When I break a block (say it's stone with gold ore behind) it still shows the block (but if I press F3 it says minecraft:gold_ore [or whatever the id is for golden ore], and I can't see the stone's hitbox and am able to break the gold behind).

Edit: Plus, is this related to the see-through chunks, which is really annoying, and when I place a torch I can see the torch particles but the torch itself is invisible, the dubug screen says there is a torch there and is light level of 14 light, 14 block, 0 sky. I can even the hitbox, but it looks like it is a light level of 0. I am in a cave.

Yes, Sam Bone. This is that bug.

I was happy with my improved FPS until I noticed this. Downgraded back to 14w18b.

Apparently threaded chunk rendering occurs as a batch job, not as a real-time operation. Whenever a chunk updates, the game engine waits for the batch job to initiate before the chunk is rerendered. I can't see the code, but based on how the devs described it, this would be an adequate explaination for it.

I have a section with rows of custom heads. A middle row of 13 custom heads does not render at all (heads are invisible blocks with hitboxes). If I place a block next to a head, the heads become visible. Then if I try to break the block I just placed, it stays visible until reloading the world. Upon reloading, the heads are invisible. This only happens with this specific row. I'm guessing the edge of the chunk has something to do with it because the Chunk coordinates are on 0 0 2 to 0 0 14

I would be curious to see if these visual bugs are related to chunk edges with others.

Upside to this bug: X-Ray.

Use 29a for more consistent behavior. 29b is just a 'threaded batching of chunkdata to renderbuffers'-experiment.

Thank you, Grum, for responding.

As MC-62582 is marked as a duplicate of this one, I will mention it here.

Chests, signs, and ender chests do not render if they are in a 16 ³ chunk with no block models
Block models are any block except chests, signs, ender chests, and barriers

And from MC-62583, a more consistent way to reproduce the ghost blocks is to destroy the last block in a 16 ³ chunk

I don't think that the new title is better than the old one...

@@unknown: Then propose a better one... The old was lacking the information that blocks take some to to appear after placing.

Thanks for the explanation. Would be cool if you would tell the people why you changed the title after actually changing it, and not waiting for their questions.

I got this right at the moment the world would not vissualy update anymore:

[13:43:08 INFO]: Client> Exception in thread "Chunk Renderer 1" u: Tesselating block model
[13:43:08 INFO]: Client> 	at cjc.a(SourceFile:81)
[13:43:08 INFO]: Client> 	at cma.b(SourceFile:176)
[13:43:08 INFO]: Client> 	at clv.a(SourceFile:63)
[13:43:08 INFO]: Client> 	at clv.run(SourceFile:45)
[13:43:08 INFO]: Client> 	at java.lang.Thread.run(Unknown Source)
[13:43:08 INFO]: Client> Caused by: java.lang.IndexOutOfBoundsException: Index: 1, Size: 0
[13:43:08 INFO]: Client> 	at java.util.ArrayList.rangeCheck(Unknown Source)
[13:43:08 INFO]: Client> 	at java.util.ArrayList.get(Unknown Source)
[13:43:08 INFO]: Client> 	at crx.b(SourceFile:88)
[13:43:08 INFO]: Client> 	at cgp.a(SourceFile:156)
[13:43:08 INFO]: Client> 	at cje.a(SourceFile:254)
[13:43:08 INFO]: Client> 	at cje.b(SourceFile:111)
[13:43:08 INFO]: Client> 	at cje.a(SourceFile:45)
[13:43:08 INFO]: Client> 	at cje.a(SourceFile:35)
[13:43:08 INFO]: Client> 	at cjc.a(SourceFile:68)
[13:43:08 INFO]: Client> 	... 4 more
[13:44:06 INFO]: Client> [13:44:06] [Client thread/INFO]: [CHAT] Command set: /setblock ~ ~ ~ minecraft:chest 3 {Items:[{id:minecraft:brick,Count:1,tag:{display:{Name:Key 15}}}]}
[13:53:03 INFO]: Client> Exception in thread "Chunk Renderer 0" u: Tesselating block model
[13:53:03 INFO]: Client> 	at cjc.a(SourceFile:81)
[13:53:03 INFO]: Client> 	at cma.b(SourceFile:176)
[13:53:03 INFO]: Client> 	at clv.a(SourceFile:63)
[13:53:03 INFO]: Client> 	at clv.run(SourceFile:45)
[13:53:03 INFO]: Client> 	at java.lang.Thread.run(Unknown Source)
[13:53:03 INFO]: Client> Caused by: java.lang.IndexOutOfBoundsException: Index: 1, Size: 0
[13:53:03 INFO]: Client> 	at java.util.ArrayList.rangeCheck(Unknown Source)
[13:53:03 INFO]: Client> 	at java.util.ArrayList.get(Unknown Source)
[13:53:03 INFO]: Client> 	at crx.b(SourceFile:88)
[13:53:03 INFO]: Client> 	at cgp.a(SourceFile:156)
[13:53:03 INFO]: Client> 	at cje.a(SourceFile:254)
[13:53:03 INFO]: Client> 	at cje.b(SourceFile:105)
[13:53:03 INFO]: Client> 	at cje.a(SourceFile:45)
[13:53:03 INFO]: Client> 	at cje.a(SourceFile:35)
[13:53:03 INFO]: Client> 	at cjc.a(SourceFile:68)
[13:53:03 INFO]: Client> 	... 4 more

no resoursepacks used

then when reloading the world in any way then, MC-62629 happens

Confirmed here - using any version other than 14w29b removes the glitch entirely. Happens with/without VBO (unrelated to the bug.)

After breaking a block, a multi-second delay occurs before the drop appears. During this delay, the block appears to remain in place and can be damaged (all the way to breaking) again.

Tool durability seems to be consumed if you continue breaking the ghost block. - unverified however

Placing blocks also results in a multi-second delay before they appear. During this delay, the block's hitbox is visible, but not the block itself.

This same thing happens with me but can also have slightly different rig.
'Windows 8.1'
'java.version'= '1.7.0_60' (Newer version than mentioned first time around)
Processor AMD FX(tm)-8350 Eight-Core Processor 4.00 GHz
Installed RAM 8.00 GB
System type 64-bit operating system, x64-based processor
Graphics card Geforce GTX660

Mind you the block stays for 2 to 3 secs but cannot be damaged, same when placing blocks a lag appears see wire frame but no block of a while along with when opening doors and closing them taking time at first but if done once seems ok second time around.

this time the exception happend again, but this got a few minutes before the exeption came:

[14:56:47 INFO]: Client> [14:56:47] [Chunk Renderer 1/WARN]: Needed to grow BufferBuilder buffer: Old size 524288 bytes, new size 2621440 bytes

seems like Chunk Renderer 0 makes the bug never end until a restart has been made and Chunk Renderer 1 only temperatily

Appears to be fixed in 14w30, at least for me. Can anyone else confirm if this is fixed?

Fixed
(yay)

I'm still getting this mildly in 14w30a. With banners, however, it's extremely noticeable.

Oh, no no no, this is not fixed, the delay is a half second or more on my machine.

You might experience MC-63020.

Nope Galaxy_2Alex... just standing on stone, breaking stone, and not coordinate specific.

ACTUALLY... I only get the delay if I break / place things while chunks are loading. Things are fine once the chunks are all loaded.

I can confirm. It is better but not fixed.

Confirm. I think it's easier to reproduce if you press Ctrl+A to forcibly reload the chunks, and then start breaking blocks while the chunks are loading.

With Part b of the snapshot. It is fixed and I did this rather quickly. A the fix is not there but with B it is fixed.

No, I still see it in 14w30b.

Reopened (MC-63251)

14w30b confirmed. Average 9-13 fps, delay between block change and screen update has been reduced to about 1/2 second (14w29b was 30 seconds and up, in my experience). Improved vastly, but delay is still there.

The two bugs I had that were labeled as duplicates of this are both fixed...

Well... It's fixed for me, maybe low-end PCs or laptops still experience this problem.

I'd hardly consider my desktop a low-end PC. 8 gigs of ram, intel i5, java 7. I'd say it happens every 50 blocks I change or so - more so when several blocks are being processed at once (e.g. creeper/tnt blast) or under heavier-than-normal load (e.g. chunks [re]loading, recording video). It can be very noticeable when it happens.

Ok, there is a new problem involving this same issue. Rain is causing me to have this same issue. I am experiencing the same issue as before but now rain is causing this same problem.

When it is not raining then I am not having much of a problem but when the rain and thunderstorm starts then the old issue with last snapshot happens, So you have a delay issue in the rain.

For me, the issue is much better than before, and overall performance has greatly improved, but I still notice the issue occasionally. I haven't had much time to troubleshoot, but I'm noticing it on multiplayer (haven't tried single player). AMD FX-8150 @ 4.1GHz, Radeon HD6950 2Gb, Samsung 830 SSD, 8Gb Ram, Latest Java (Devoting anywhere between 1 and 4 Gb to MC made no difference). It is also accompanied with other glitchiness (i.e. seeing through the world when inside of blocks that aren't disappearing right away). Bearable, but still there for me. I notice it most when mining multiple blocks in quick succession. If I'm going slowly, it's not really noticeable.

I'm experiencing this with 14w30b as well running in single-player mode.

Late 2013 Retina MacBook Pro (quad Core-i7 2.3GHz, 16GB RAM, 512GB SSD, nVidia GeForce 750M)

14w30c - problem can be extreme (5-10 seconds before changes appear) if I'm performing a lot of changes, like mining a bunch of blocks or running around gathering stuff. The most painful scenario is when you uncover lava or water and there is no sign of it until the UI "catches up".

I experience it in 14w30 but the problem is very slight.

I've seen this in 14w30c as well (and quite a bit). If I place a block that I can't see then breaking a block next to it will cause it to appear visible again.

Ok, I just downloaded the snapshot and been playing with it. I think the bug is fixed. I am set for 4 chunks and waiting for the rain and this part has not been tested yet.

Still getting this in 30c. Though very rarely. In 30c I'm now periodically getting only top half of door appears open when I open a door.

There is a few bugs that is going on. The bug is not as noticable on my end. I played for about 2 hours and I was wrong but it is improved.

The other people who commented is correct.

For me, the mobs lag. When they try to walk it seems like they do it step by step at a time. When I hit them, they fly up slowly, stop and wait half-a-second, then repeat that process until they land.

its lag when i walk or open chest

Video showing the issue on the current snapshot (14w30c) with both VBO settings: http://youtu.be/Sg_iT9fqE7I

I can confirm this still exists in 14w30c

Same here, but quite rarely.

14w30c - The bug isn't immediately noticeable in a fresh world. It shows up after playing for a while and gets progressively worse. I found that running into a new area and then digging continually would make the bug more obvious earlier on.

After several hours of playing and building a wheat farm, it became so bad, I couldn't trust the visuals at all because they wouldn't update while I was doing something. It became progressively worse over time, until eventually the game was unplayable.

I had to quit and restart a few times after everything froze. Restarting did seem to make things better for a little while, but I can't say for sure.

I've given up on using 14w30c because the worlds eventually stops being usable.

I notice that if you do it in 4 chunks then the problem is not as bad. Anything higher then it messes up.

Check the game ticks as this may be related to the Laggy Mobs (MC-58120) issue. Game ticks seem to be extremely slow in some worlds. See the comments under that issue.

Game ticks should be irrelevant (well, if you have enough cores to keep the server from eating into the client's CPU time). Frame rate is the main factor modulating the severity of this problem. Even with the threaded chunk updates, almost none get through if the frame rate drops too low. This is a major flaw in Minecraft's frame rate control. It's like closing your eyes to improve athletic performance by reducing visual processing demand on the brain; it doesn't help because it isn't what's holding you back, and now you've crippled yourself. Chunk updates should get a proportionate portion of frame time, not just the final sliver left by the true bottleneck.

I'm on a quad core laptop with dual graphics. I never had any fps or chunk lag issus ubtill this snapshot

Still happens on 14w31a. It's not very strong, but it just happened to me.

Confirmed, STILL not fixed in 14w31a.

Still not fixed. Affects 14w31a.

I attached a 7MB gif showing the bug. Note: the delay is only visual. I can, for example, walk through the blocks after they're broken (but before they're visually updated).

It seems to happen more often when moving quickly like in the attached gif.

Seems to be fixed on 14w31a but I'm not sure.

Anyone still having this bug: if you set "/gamerule doMobSpawning false", does the bug go away?

@Jono I have doMobSpawning set to false in my test world and I'm still getting this bug (see attached gif).

@Hawk J: Just curious, what exactly are you doing in the gif? Are you placing and breaking the block almost immediately?

@Kahless Yes.

I ma getting it but it is very mild compared to what it was

14w31a:
1. I created a new world with cheats enabled
2. I gave myself a diamond shovel
3. I dug a big square trench

None of the dirt I'd dug disappeared until after I'd stopped digging and looked around.

4. I waited about a minute to see if this was just a startup issue, then tried it again: I dug three more blocks then turned around to look. None of the blocks had dissappeared. A few seconds later, they all disappeared.

5. I thought I might be able to work around this by digging one block at a time, but found that the screen wouldn't update even after digging just one block until I'd waited about 2 seconds.

In short, the problem seems to have gotten worse in 14w31a... even with a new world (survival mode). Is no one else seeing this?

Well, in general there are all kinds of weird render stuff in 14w31a (and 30, as we've seen). It's impossible to identify individual problems because most of them are entirely related to machine performance and video settings, so everyone gets different results (hence this and a million other render-related tickets have been marked as fixed, then oftentimes reopened).

Regarding "machine performance and video settings", I just tried this while monitoring the CPU. It never exceeded 25% load. Minecraft used to burn CPU like crazy - now not at all.

I'm using a a recent high end macbook, but it's still a laptop, so I wouldn't expect great "performance"... but this doesn't seem tied to CPU load or memory at all... it's as though minecraft isn't even trying to use the CPU to update the screen. I thought it might be a JVM problem, so I gave it 4G and loads of per thread stack, but it didn't make a difference.

EDIT: "... isn't even trying to use the CPU to update destroyed blocks..." The "screen" is updating fine.

This still affects 14w31a. The updates may take tens of seconds on my Intel GM965 (everything on low). TNT craters seems to be re-rendered relatively quickly (often less than 7 seconds).

So I did more investigation, btw. the issues I mentoined above occured after generating new world right after installing the new snapshot. However; the problem did not disappear, after more testing I found out that it is happening more severely in plains biome, probably because of all the grass and other 2D stuff. When I turned rain on, all the blocks suddendly stopped moving ( I made a clock with 16 repeaters and 1tick piston clock).
In the desert the rendering was in sync. I couldn't observe rain impact though, because rain in the desert simply doesn't happen.

Best to reproduce on a single-core CPU with weak GPU.

Edit: I've tried it once more in an rainy non-grassy biome and I hit the same issue when it was raining - all the pistons and repeaters stopped, I could trace the redstone signal only thanks to particles ( also rain dropped my fps by 45%).

something I feel like is worth mentioning is that this bug is always going to exist in some form. It should just be fixed and optimized to the point that it doesn't affect gameplay.

@Jacob. This bug didn't exist until very recently. And it does completely affect gameplay.

@qmagnet I know, I was one of the first to experience this bug when the snapshot came out. What I'm saying is this bug is the result of poor synchronization times with the render engine, so to fix this bug those times have to be improved, but it still takes time to make the synchronization happen, so this bug will always exist, it just needs to be optimized to the point that it doesn't affect gameplay.

I can't reproduce it in 14w31a. Even if I set up a test world with render distance 32 and put a fast clock in it, when I reload it starts pulsing within a split second. But then this quad-core i7 initially produces 500+ chunk updates per second.

Render distance 32 does have a profoundly negative effect on the server, however. I had to disable random ticks to maintain decent performance. Until chunk generation is finished you can't expect much of anything to work. The performance impact seems way out of proportion. 4 times as many chunks, orders of magnitude slower?

I don't get it at all as much as in the linked youtube clip, but I do get it occassionaly when placing/removing blocks.
On a faster computer besides me, the issues doesn't show at all.

So I guess it's all depending on available computer power?

I'm getting 100+ FPS on an i7-2600K beast, and still getting both placement and breaking delays from my local server on 14w31a. Placement delay at least shows a wirefarm 'selection grid' of the block (like selecting an invisible block). Arguably less frequent.

I also have a very fast computer and I get delays of both block placement and door changes or they do not occur at all until another block is placed. The occurrences have reduced since 14w30 I believe but they are still happening.

@Jacob - Whee... if you accepts that this bug "will always exist" then you'd would need to be qualify which variations on this bug have a "significant" effect on gameplay... but you may be right. If I'm reading between the lines of your post correctly, then you're saying that this new separation between the world "model" and the world "view" really needs to exist, even though it didn't exist (to this extent) until now.

I'm getting this even at Render Distance 8, though it's not nearly as bad as it was in 14w30b. The delay happens for me just as Adam says, including the doors.

This issue is still present. Opening doors they appear still closed. or Closed doors appear still open. Blocks won't show up as well as torches. 14w31a

IT happens to Etho a bunch in this video: https://www.youtube.com/watch?v=dho3KHcerYs

Lane-Etho is in 14w29b which is one of the versions this is known to happen in. you can see the version around 1:15 into the video. but around 6 min in it is a good demonstration of what this bug is all about

Half the comments here are the exact same; "Still apparent, just not as much."
Also, this bug report is huge. Over 100 comments. Over 100 duplicates. Almost 100 votes. Almost 100 watches.

yup just tested it. i onley see break animation and break sound but it doest go away onley if i remove the block below it

The block updates correctly on either:

• a block update next to it
  or

• going out of the view cone and re-entering it.

While a broken block is erroneously present, player can move through it.

@Stephen wrote:
> The block updates correctly ... going out of the view cone and re-entering it.

I am definitely having a different experience from yours. As mentioned in my comment on 7/30, I dug a big square trench and none of the dirt I'd dug disappeared until after I'd stopped digging and looked around (and then waited a couple of seconds).

Mojang, I am not a programmer but I think I found your problem. Pay attention past 15:49 of my video on the memory. Just keep an eye on that. At one point in time, I get memory at 67% so what I think is going on is your need to either expand the memory or change it to where it is not taking up as much memory. I went into a rooftop Biome and this is the worst that I got so this is looking like a memory issue to me. I am not expert and do not claim to be but if I am reading this then this is the problem that everyone is experiencing.

https://www.youtube.com/watch?v=UN_i4DPrrmg

That is the link to the video. Please pay attention and watch.

@Kenneth, likely not a RAM related bug. Your recording shows a poor framerate - either by your computer performance or capture program. You can already add more RAM to Minecraft through the launcher. Regardless, I myself have no issues with memory and still experience this bug. I would bet the majority of people here would agree.

@Magnet I am not talking about a RAM bug but a VMU Bug issue. (Virtual Memory Usage). From what I read Minecraft uses Virtual memory that the processes uses. If they were using RAM then may God has mercy on our souls. ;0). Something is drawing the VMU to 72% in some Biomes if you watched the video.

I am not an expert but it should not be doing that..

Bug Code 62166
Or break the block, place, time used to take the bug disappears when change appears
There is still not being modified.
I think that you want to modify.

confirmed in 14w32a

Here's a clip showing it in 14w32b with pistons and slimeblocks:
https://www.youtube.com/watch?v=DAALPKTeuR4
Notice the blocks disappearing when interacting with player and appearing on update (even when the cloud goes through it at the end).

Did some more testing in 14w32d to reproduce the bug with just block placement:
https://www.youtube.com/watch?v=nD4Z0JLWjzY

Seems a bit better in 14w32d, but still getting the x-ray effect and short delay, at a minimum, on breaking. Touch wood, I haven't had a long delay like before. For me, it is mainly affecting block removal, not placement.

Try running quickly to a door and opening it. For me, at least 50% of the time, the door doesn't update, it still shows closed even though it is not. And it does not update until I place or remove another block. This is my big test of this bug and in 14w32d, I see no improvement.

it happens to more than just block placement/breaking.

while i see this on those as well, i also get the same problem when interacting with stuff like doors or gates. the visual will still show closed door/gate, but i can now walk through it.

That's why the bug title mentions "changing blocks"

This is torture for adventure maps. I can't add in the best new features to my map since the map has to be made in 14w21b because for me the afterimages started in 14w26 and stepping into the 14w25 snapshots is basically putting your creation on a server with xsunnybrox, xsunnysisx, xsunnyboyx, elieljason2, SethXB, and KidCreateLMS as the only players. (all griefers)

Having this issue as well, It is specifically visible if you place a lot of blocks at once, not letting go of the mouse button.
Not a slow PC either, Radeon 7990, hex core 4.7 gig I7. 16 gig ram.
My first thought was that it was at a chunk boundary but further testing eliminated that.

Confirmed: 14w32d

Also beacons sometimes do this where when I break them the beacon light stays there and when I add colored glass on top the old beacon color glitches with the new appearing color.

Not to mention, this seems to be happening in a way with some entities, like armor stands and item frames, but they go invisible when you unload the chunk...may or may not be a similar issue: MC-66683

This might be the secret bug fix that Searge is talking about. Or the spider issue.

Nah, that's too obvious.

I've seen that happen with signs in 14w32d.

Confirmed still in 14w33a. Lol, I broke 2 blocks to find out.

Confirmed that it still exists in 14w33a. Here is a video with trap doors as bug trigger that shows it only triggers when player is moving in the same block that's being updated: https://www.youtube.com/watch?v=SeuqVy8_FD8

I tested a bit more without capturing and can reproduce the bug without standing in the block as long as i move whatever way while opening and closing the trap door. That is strafing, jumping, walking towards, away, etc. But I have to move, if I just move the mouse looking around while clicking it doesn't trigger.

I have to agree with the guy here but people does need to confirm if it is in the snapshot. Just say if it is in latest snapshot so the people from Mojang can confirm yes, or no and try to fix it. MOJANG KNOWS ABOUT IT! They will fix the bug as soon as they know the cause of the bug. I am not saying to update anything that is new. However, Read the copied bugs to know if you are repeating what others is saying already.

That way the bug can be fixed properly.

Confirmed in 14w33a

Still present in 14w33c

present in 33c with birch doors. when I click to open i can walk through but they render as closed

Its back in 14w34d.

Cannot Reproduce

Place some wooden slabs in empty space, and just start to add to them. Sooner or later it starts, you place a block, its the exact same bug back again.

If you cant repro, i can record/screen shot it.

Still unable to reproduce: http://i.imgur.com/Kl3eGAS.jpg
We'll wait for more reports.

Ok, will recreate this world and see what happens.

I reproduced it.

Colin Smith are you sure you didn't accidentaly used 32d?
I can not reproduce

I cannot reproduce either.

Using the absolute latest dev. Its not as easy to reproduce as originally, but its still occasionally there. Will try to catch a screen shot.
It appears to be some corner case, much harder to reproduce but it seems to be related to the lag fix. That lag fix totally fixed the missing blocks.. somehow linked?

I can confirm that this was fixed in 14w34c and regressed in 14w34d, so now the issue is back 😞

I have reproduced the issue but it is very slight. I have gotten it in less that a second or two seconds max on delays.

It is also caught on video, I am trying to upload but internet is shitty.

14w34d, a creeper blew up and none of the blocks updated until I started jumping around for about 30 seconds in the X-ray crater (I intentionally didn't mine any blocks to see how long it would take).

Confirmed still present in 14w34d. I most frequently see it when digging straight down or building straight up (as shown in one of Simen Graaten's videos). Specifically, when moving (jumping, falling, etc.) while a block is placed or removed, it will sometimes not be updated until another block is placed nearby or after some amount of time looking around elsewhere.

kind of reproduced it, I removed one block and all the side textures of the blocks it was touching were loaded exept for 1 block
just like in 2014-08-20_15.40.22.png

I am letting you know that 62166 is still going on in pre-release.

https://www.youtube.com/watch?v=BA04vvZmJgk

As you seen as I started to build the towncenters on my servers (Yes, Plural). I got the issues that was reported by Several players in this report. It is not as bad as before but there is a lot of lag as well.

Just letting you know that it is in the pre-release..

yes, me too for pre-release. Albeit at reduced frequencies.

Oh my gosh, this is an insistent bug. THREE fixed versions and still happening?

FYI - This bug makes MC 1.8-pre1 unplayable. I had to give up testing 1.8-pre1 åfter just 10 minutes when I fell into an "invisible" hole exposed while mining.

It happens occasionally for me, but it definitely doesn't make the game "unplayable" – might depend on computer specs.

Yeah... sorry. Instead of saying "unplayable" I should have said this bug makes single player survival games too frustrating to play. You just can't play those games without immediate visual feedback when you've uncovered a "hole" or you're gonna fall in it.

Since we offload all the conversion of 'worlddata' to 'renderable data' onto another thread it wasn't quite reliable in updating a block you just broke for the next rendered frame.

We changed this in 14w34c – so the nearby chunks (to the camera) would get updated for the current frame (so synchronous on the same thread instead of offloaded). This could cause quite some jitter and people reported this.

As a test in 14w34d I changed it so only 50% of the chunks would be updated on the same thread thus halving the 'jitter' people experienced at the cost of having a possible hole shown for 1 frame.

On a given system that can obtain ~60 fps, a hole would be visible for upto 'just under two frames', which would be around 16.7 * 2 = 35ms
Now, if you have a system that averages at 10fps, this hole is visible for upto 200ms 😞

So we have to pick between two evils, make the framerate more jerky by doing the updates 'right there and then' (on the same thread) or try and smooth the pain at the cost of visual glitches at certain positions.

I'm ok with either but wanted to have people try both versions. I'll change it back to guarantee to not show holes mondays unless I can think of another solution.

Is the entire cause of this because chunk loading was made extremely fast?

It has to be something else as well though Grum. I have a machine that can pull over 500 fps, and its always over 100 outside on 16 view distance, yet when i get this issue, its usually permanent, not just a few frames. Just now i was playing and i opened a door. I heard the sound, and i can walk through the door, but the door didnt change state. I had to open and close it multiple times for it to work. When the glitch happens it often sticks around for a lot longer then a frame or two. It also shows that in the screenshots, there is no way you could get a screenshot of it the issue if it only existed for 2-3 frames.
This particular issue has now only been in the last four snapshots ( i think, correct me if im wrong). Something changed 4 snapshots ago that made this happen. I have a hex core intel I7 machine, 4.7 gig, 7900 series video card, 32gig ram at 2.4gig itself.. and i get this issue probably at least every 2-3 minutes of play.
Perhaps it was that "Viewable" code that was ported from the portable edition?

What do you mean with jitter? I had no complains about 14w34c regarding performamce. My machine hits about 100 fps average with "average settings', so it should be a good refference for the average player.

I had massive issues with 34c, even to the point where it felt like the game was missing mouse events, and the view didnt follow the movement of the mouse.

Another update. Just had the door bug out again. I have multiple screenshots of it, actually standing in the door, and the selection box showing it as open. It stayed like that no matter what i did (as long as i didnt click it) i could walk through the door, and so could mobs, and i heard the sound, but the door "looked" closed. Exiting the game and then reloading the save fixed it though.

If it helps, there are also selection issues with other things too, for example flowers show up with the selection box in a different spot. There seems to be some occasional disconnect between the render engine and the actual state of the game. The game said the door was open and the engine treated it like that, but the actual rendering still thought the door was closed.

I am able to reproduce the bug nearly 100 percent reliably.
While moving back or forth, keep opening/closing a door. It looks like it happens when the viewpoint changes and another block is selected WHILE its updating, or the "visible" area changes when doing a block update. It doesnt ever seem to happen when you are still.
It will get to the point where the door will look closed but actually BE open, or vice versa.

This issues fixes itself if you destroy a block next to the door, so it looks like a block update fixes the glitch. Even a block being destroyed with the door just out of view fixes it. If you do anything with the door behind you or way way out of view, it doesn't get fixed.
If you place a block or destroy the block more then around 3 meters away, it stays glitched.

So.. perhaps there is a flag saying "update the engine" not being passed occasionally to the render thread?
It seems to be a lot easier to reproduce when you are moving. This is pretty important. I can reproduce this bug with anything when you are moving. When you are still, its seems to be impossible to reproduce the bug. So it has to be something that changes when you coordinates are changing. Just looking around doesnt trigger it. Its only when you are actually moving. The F3 view when looking at the selection box says the door is the opposite of what it actually looks like.

@unknown: I saw delays of 10 to 20 frames when I just tested 1.8-pre1. I maxed everything out and disabled random ticks to get those chunk updates to zero and to make sure the server can take it, but to strain the client. Eventually I was looking at a huge jungle with render distance 32 which dropped me to 7 fps. Depending on where I placed a door opening or closing it produced 1 to 4 chunk updates (I suppose up to 8 if you pick the right spot). The integrated server was fine because the hitbox changed and the sound played instantly. But the visual update would often take one or several seconds. I didn't move and kept my mouse perfectly still. I saw only the occasional spurious chunk update (sheep eating grass or something), so I don't think the chunk update limited mattered.

Oddly, reloading the game got me up to 13 fps. Even when I looked all around me to display every single chunk at least once and turned back to the jungle it remained at 13 fps (if you fly around it does become slower over time but I guess one 65x65 area isn't enough). Well, during the previous run I noticed a sudden frame rate drop which would probably explain the difference if you could figure out why it happened (no RAM pressure; maybe VBOs overloading VRAM?). Updates could still take a second or so, but in slightly offset locations were pretty much instant as you describe, even with 4 chunk updates per click. At least it beats updates being deferred indefinitely. I can't rule it out based on such limited testing under deliberately limited conditions, however.

Why do chunk updates slow to a trickle when the frame rate drops, anyway? Especially at low frame rates they tend not to be the bottleneck; you could probably process at least tens per frame unnoticed. The current limit is a good way to test the limits of the engine, but it's not so good that the world takes unnecessarily long to load if you just want a nice view regardless of frame rate.

Just for completeness:
Graphics: Fancy
Render Distance: 32 chunks
Smooth Lighting: Maximum
Max Framerate: tested both 60 fps and Unlimited; doesn't make much of a difference when you can't hit either
3D Anaglyph: OFF
View Bobbing: OFF
GUI Scale: Auto
Brightness: Moody
Clouds: OFF
Particles: All
Fullscreen: OFF (but I used OS X's rightmost title bar button, which makes a kind of fullscreen window)
Mipmap Levels: OFF
Alternate Blocks: ON
Use VBOs: ON

@unknown: Jitter as in the moment the world changes near you, the game halts for a short amount of time. The effect probably depends on your current bottleneck.

If you minimize your view to 4 blocks then it minimizes the bug.

It seems to impact Obsidian and Redstone Ore mining for me more than other blocks, even when all other graphics run smoothly. I've had the problem on and off through different snapshots(based on the comments, it's been fixed a few times for everyone). Using F3+A used to take longer to load, now it refreshes so quickly I can barely tell it happened. Also, the Midmap Level slider lags while all other options don't. Not sure if those last two are related, but I thought it worth mentioning anything that seems off.

Laggy mip map settings is MC-69127.

@unknown
I personally strongly believe the '32 chunks renderdistance' shouldn't be in the game. The server has big problems trying to provide load or generate enough chunks and send them to the client causing delays on everything.

This would mean the server takes excessive time processing the 'opening of the door' and thus reply very late with the correct data to open it. This in itself might cause a delay in rendering it properly, or it might even flip back and forth as the client does do some prediction.

My recommendation, unless you are running on a supercomputer, do not use 32 chunks render distance.

@unknown: Yeah, 32 chunks isn't very workable. Your hypothesis about the cause of the delay is utterly wrong, though. The server was running at full speed after all chunks had been loaded (only one "can't keep up" message skipping three seconds, showing up three seconds after joining). Things like block placement made a noise immediately (these sounds are server-controlled, if you didn't know).

Regardless, this bug is about the disparity between the internal model of the client (which you can probe by bumping into it and aiming at hitboxes) and what it renders. That is what I tested; it wasn't the server causing the textured door to update 20 frames after the hitbox did. It can potentially rubber-band you if you walk into an obstacle only it knows about so far, but that wasn't what happened. Many reports here are detailed enough to say that wasn't what happened there, either.

Also, assertions like "it should be delayed by at most one frame" (I assume there have been no further changes in 1.8-pre1 since you didn't mention any) should be true regardless of whether or not you like the render distance. If you can't explain it, it's plain wrong and you'd better figure it out. If, on the other hand, immediate updates were disabled and we'd have to rely on ordinary chunk updates which are kept artificially low (for example), it may work as expected but still be a design flaw.

One more thing: Of course I don't normally overload the system like this. But should overloading be an invitation for anything other than proportional slowdowns or growth of memory usage? If it is, the system should be more robust. Remember exceptional cases occur all the time; deliberately looking for them only makes them easier to identify so you can reduce their (arguably smaller) impact on 'normal' use, with the added bonus that you can explore the limits if desired.

Actually, not all sounds are server controlled. Either placing or breaking is client side, can't remember which

The sound of breaking blocks is client-controlled, while placing blocks is server-controlled.

Hi Grum,

I just found that (for me) changing the "Max Framerate" has a dramatic INVERSE effect on this bug.
My previous observation about the game being unplayable was based on "Max Framerate" = "20".
"Max Framerate" = "unlimitted" : this bug does not show up at all (albeit with very limitted testing).
"Max Framerate" = "10" : this bug is worse than ever.

I'm not going to suggest WHY changing the "max framerate" has such a dramatic effect, but it does... at least for me (single player survival mode).

Grum wrote:
> On a given system that can obtain ~60 fps, a hole would be visible for upto 'just under two frames', which would be around 16.7 * 2 = 35ms
> Now, if you have a system that averages at 10fps, this hole is visible for upto 200ms

FYI, when "Max Framerate" is unlimitted, my system gets around 100-300 FPS with VSYNC turned off. I like the framerate turned down to minimize CPU load, thus heat, and thus fan noise 😉

This is starting to sound like two different bugs. There is the one where a block doesnt update for a period related to frame rate, then there is the one where only a block update fixes it.

Confirmed in 1.8-pre2(didn't see it listed among the bug fixes, but I broke some obsidian just to be sure).

MC-68080 is back now in pre2, I guess because of the changes grum mentioned here. pre1 was super smooth, pre2 has the choppy lag.

I'm seeing this as well. Also it seems the world generator and chunk renderer can get bogged down, even at a 16 chunk render distance, causing other things to be delayed. once every chunk that is going to load has loaded it seems to clear up a little bit. If you fly in a straight line you can effectively fly off the world as the chunk renderer can't keep up with running/flying in a direction for too long. Also I noticed a very long delay when I issue a command like /kill or /gamemode. Several seconds in some cases... again when the world generator goes fairly idle it clears up. Maybe they are all related?

Why was this bug shipped in 1.8? The game is unplayable, especially on anything less than the fastest computers.

@Jordan well my computer is not fast at all (I get arround 20-30 fps without mods) and I don't have it anymore. I sometimes have it for like 1 milisecond, but I don't have problems with this anymore. In 31a it was ways and ways worse.

This is not acceptable for hardcore.

I'd agree that it's not acceptable for hardcore, but as for myself (1.8 release, single player, 12 block render distance), it now seems "acceptable" after the latest updates. In other words, I am now only seeing block update delays in situations that don't affect gameplay, eg., I saw it while chopping down a tree three blocks away.

There are probably variations on this story that still present a serious problem, but unless they refine or split up this bug report into a couple more specific bug reports, be specific about which variation on this bug you're seeing.

"be specific about which variation on this bug you're seeing."

I have already done this, and it was closed and deferred to this long-standing one which they have still not fixed despite shipping 1.8. It is unacceptable for single player, as I get it all the time unless I turn down the render distance well below what my computer is capable of at 35+ FPS. I have run a VERY heavily modded 1.7.10 server on this computer before, while playing on it with several other people. Besides the humongous RAM requirement, it ran fine. THAT is what is an unacceptable regression for it to be shipping.

Just got it in 1.8 door looked closed but was opened. It's rare.

Cannot reproduce in 1.8

This is happening to me in 1.8. New world, using the customized world preset of Caver's Delight.

i7, Windows 8.
Nvidia GTX 560Ti (latest driver as of 9.24.14)
16gb ram

In creative or in survival?

Still cannot reproduce in 1.8.1-pre3.

I'm assuming that this is fixed, IMO.

I see it occasionally in pre3 still. It's nowhere near as bad as it originally was, but it does happen.

When I break a block it turns black at that spot.

It's still occurring a lot in my games, so much so I just can't play the game it annoys me so much. This is in Survival, any world I play, any coordinates.

Any help to rid/reduce this? Cheers.

@@unknown: Fixed links of MC-65070, right base ticket is MC-3329.

Just limiting the framerate to 10 FPS slows the game down a lot. It seems like Chink Loading depends of framerate. They load instantley with 700-800 FPS. But they are quite slower with 60 FPS what surprices me.

Computer specs: (if you are wondering about the framerate)

• Intel core i7 - 447 - @3.4 GHz - 4 cores

• Nvidea GEforce GTX 760 - 192-bit

• 11,92 GB RAM

Obviously, There is 2 ways this could happen.

1. The event loop has an exception while loading chunks, so it skips the process, and the blocks that are supposed to load as you see them (That's why this didn't turn up in 1.7) don't load.

2. The event loop is lagging, which, sometimes, doesn't affect KeyPress or Mouse-1/Mouse-2 bindings, (which means that the game would still be playable) but the event loop still has to load blocks, which would be stuck/not running very fast

If no sound is played when you place blocks, it is 2

Unable to reproduce "breaking/changing blocks" have a delay.
I've been unable to reproduce this in non-snapshots for a loooong time already 😞

Yes, if you limit your fps to 10 you will obviously not have the screen updated for a tenth of a second (and if it happens off-thread for some reason (shouldn't) it can take two frames to appear.

Loading speed or any other things have nothing to do with "What you see after breaking/placing" and are logically tied to the framerate. Only so much can be done between frames and if your system can only spit out 10fps loading is going to be seriously slow downed because of the lack of spare cpu cycles. If you feel that is an issue, another ticket should be opened 🙂