Seems to be a random occurrence for me, and unrelated to how much my computer is doing. Strange thing for me is that I have several clocks in various places on a test map, yet it's only one specific clock that freezes, no matter how many times I replace the components. As I'm sure is happening with others, if it occurs it completely breaks my adventure map, so hopefully a fix is in the works.
@GrygrFlzr, unfortunately I am unable to replicate. Although my previous clock did border a chunk, I then moved it completely inside a chunk and teleported to and from, and the new clock still froze, yet the one I had problems with previously did not...
Just in case it happens to help Jens, here's how I'm seeing it: http://i.cubeupload.com/HzZHSv.png (ignore the background, this is the only place I can reproduce). I think being able to reproduce it is relative to positioning or area, I just have no idea what the conditions are. The reason I think that is because I have several more clocks a couple of hundred blocks or so away (-30, 64, -7 should that matter), that have never ever broken. I've been able to place a clock within around a 50 block radius from the position shown on the screen, a few levels higher or lower too, and I've been able to break it everytime. In order to break I just teleport to and from unloaded chunks a few times and it eventually breaks. For example I'll teleport to -500 64 -500, then 500 64 500 then teleport back to the clocks. If they're not broken I then teleport to -600 64 -600 then 600 64 600, then return and repeat this process as necessary. Though I am able to break clocks in the general area of the screenshot every single time by doing this eventually, as I said before the clocks in the other position have never broken at all, despite the fact they're rather close.
I'm still able to reproduce it in the same way I described earlier under the latest snapshot. Though the result of the bug is the same, as I'm doing other things to produce it I suppose it may be a separate issue from the bug originally reported here.
Seems to be a random occurrence for me, and unrelated to how much my computer is doing. Strange thing for me is that I have several clocks in various places on a test map, yet it's only one specific clock that freezes, no matter how many times I replace the components. As I'm sure is happening with others, if it occurs it completely breaks my adventure map, so hopefully a fix is in the works.
@GrygrFlzr, unfortunately I am unable to replicate. Although my previous clock did border a chunk, I then moved it completely inside a chunk and teleported to and from, and the new clock still froze, yet the one I had problems with previously did not...
Still occurring for me with 13w09c unfortunately
Just in case it happens to help Jens, here's how I'm seeing it: http://i.cubeupload.com/HzZHSv.png (ignore the background, this is the only place I can reproduce). I think being able to reproduce it is relative to positioning or area, I just have no idea what the conditions are. The reason I think that is because I have several more clocks a couple of hundred blocks or so away (-30, 64, -7 should that matter), that have never ever broken. I've been able to place a clock within around a 50 block radius from the position shown on the screen, a few levels higher or lower too, and I've been able to break it everytime. In order to break I just teleport to and from unloaded chunks a few times and it eventually breaks. For example I'll teleport to -500 64 -500, then 500 64 500 then teleport back to the clocks. If they're not broken I then teleport to -600 64 -600 then 600 64 600, then return and repeat this process as necessary. Though I am able to break clocks in the general area of the screenshot every single time by doing this eventually, as I said before the clocks in the other position have never broken at all, despite the fact they're rather close.
No longer able to replicate the bug under 13w10b. My hero <3
I'm still able to reproduce it in the same way I described earlier under the latest snapshot. Though the result of the bug is the same, as I'm doing other things to produce it I suppose it may be a separate issue from the bug originally reported here.
@Justin Lawen @Tails : Thanks, the ticket is
MC-15019.Still present in 14w26b.