Tile ticks of connected redstone components might be executed in the wrong order when unloading/reloading chunks

Can confirm this.
Here's my force-crash report.
Will hopefully be fixed soon!

(Crash report attached, see above.)

I have also reproduced this bug: https://mojang.atlassian.net/browse/MC-5019

In 13w02b, I have this problem, except when the chunks load for the first time when loading up the world, my redstone clocks would all stop, either on when it is a short clock, or off when it is a long clock (I use purely repeater and comparator clocks)...
I think this has to do with how the game freezes redstone when the chunk unloads, and it doesn't update when it reloads...
A temporary fix until then would probably be attaching a comparator from the newest snapshot to the area where it happens, since they give constant redstone updates to the block it's pointing at.

Duped it again at MC-7708. For me, it "freezes" all button in the on position. A chunk update doesn't seem to help. Only thing I can do is remove the button and replace it. However, in some testcases it doesn't freeze, making this bug pretty random.

I fixed this by using a comparator next to one of the redstone repeaters

Confirmed in 13w04a

Also confirmed the glitch/bug still exists in 13w04a. Issue occurs once in every ten uses of the command block with /tp command. Stone buttons in the chunk with the "stuck" stone button still operated normally. Crash report located above-

I feel sad now 😞
@sam I tried that too but it didn't work. Probably because the comparator freezes too.

Ok I'm no pro at programming, and I do not know how minecraft works. But can't you just store where a redstone update should be when a chunk unloads. Just like what happens when you save and quit.
It's the TAG_List 'TileTicks' I believe.

@Jesper I think the problem is that the redstone isn't sending the information to update in time before it unloads, because you can walk out of render distance and it will still run fine when you come back, but just jumping out of render distance is the problem. A long-term solution for Mojang could be having redstone, repeaters, comparators, torchs, etc update whenever it's chunk is loaded, though it would cause lag when rendering redstone-heavy chunks, it would fix this problem.
Or cause a delay before unloading a chunk to, like Jesper said, store where the update should be, but, again, lag is an issue here with chunks with a lot of redstone, and having a lot of chunks loaded at one time.
I am not sure about any other bugs that would come because of these aforementioned possible fixes, because I know nothing about Java and the Minecraft coding, but who knows?

Here's some more information:
-It doesn't only happen when you teleport. Fly away from the redstone really far, then just quit to title, come back and then it is also broken.
-Apparently it does or doesn't occur depending on the position of the redstone, for example when I move a clock one block to the right, fly away, quit to title and come back it isn't broken, where it is broken if it is one block to the left.

Issue still persists in Snapshot 13w05a. Reproduced the glitch/bug this time by quitting the game while standing next to a normally functioning stone button beneath command block. Then restarted the game and the same stone button was stuck in the depressed position.

confirmed for 13w05b

Jesper the End,
you're saying that was fixed in 13w05b?
I saw nothing about this bug be fixed in the Mojang site.
And if it was fixed, I have a question, for example: I have a digital clock constructed into my server, it marks 18:27, I walk away 10 chunks him and stay there for 3 minutes, when back toward him, he will still be on 18:27 continuing operating normally, or scoring 18:30 already?

João: Jasper means that this issue is confirmed to still exist in 13w05b.

Oh yeah, thanks.

I have noticed this happen in vanilla servers (the "repeater freezing bug", which was supposedly fixed in 1.4.1, happens to me on vanilla servers occasionally when teleporting, but I have been unable to reproduce it in singleplayer. It seems the "fix" only drastically reduced the rate of this bug for repeaters (I don't know about other redstone components), as this used to happen a lot more frequently in both SMP and SSP before the "fix").

I should also mention that this bug seems to be tied to computer performance: The number of redstone components which freeze seems to vary; when my computer isn't under stress a repeater clock will usually not be effected at all. With a decent amount of stress (and it's hard to get the vanilla server to run without this being the case), there's a slight chance of the leading or trailing repeater in a loop becoming frozen, which can be observed by a repeater clock's pulse being shortened to a single active repeater or lengthened until the pulse is almost the size of the clock itself, respectively. When there's a lot of strain on my computer, a leading freeze becomes more likely, and it's possible to get both edges of the pulse to freeze (thus freezing the clock entirely).

I have a feeling the reason this seems performance-related is because the bug occurs when a tileTicks is not saved as a chunk is unloading. I'm not sure why, but it seems the game misses out on certain tileTicks it was meant to write, as though it's more in a hurry to unload the chunk than it is to make sure everything's written to it first.

And João, if you walk far away enough until the chunks are unloaded, then the clock cannot keep time because its chunks are unloaded and thus the redstone is not being processed. This is true both with and without this bug. With the existence of this bug, your clock is likely to eventually freeze and break down, requiring you to manually look over the redstone and find where the components have frozen (even uglier is the fact that this bug can cause major desynchronization, because it doesn't freeze all components all the time). If this bug is fixed, then yes, your clock would continue from 18:27 operating normally. If you want it to continue from 18:30, you would be forced to build the entire clock within the spawn chunk, which never gets unloaded: only then will it be constantly running and keeping time (incidentally, as it would never be unloaded, this glitch shouldn't ever effect it, unless it also happens during a server restart).

Gerrard Lukacs,
Thanks, but I understand this bug has not been fixed yet, why this is happening to you. And I have an idea to solve the problem: Minecraft could understand that chuncks that has redstone should never stops working, simple as that. What do you think?

That would be a very bad idea, as it would defeat the purpose of chunk loading on large redstone-heavy maps. Chunks are unloaded so your computer doesn't have to handle billions of blocks and thousands of entities at one time. If every chunk with redstone were loaded at all times, a map with a large amount of redstone would lag a lot, and consume excessive amounts of RAM. This also means a larger-than-normal amount of chunks must be loaded when starting up a map.

However, I think it would be nice for map makers and server operators to choose for a chunk to be persistent: that is, force the chunk to be treated like the spawn chunk, and thus be active at all times. There are many neat things you can do by sticking certain redstone mechanics in the spawn chunk as it is, but these do not work in singleplayer (as far as I know). Either way, letting ops and map makers make chunks persistent wouldn't be a fix to this bug, it would be a different feature altogether, and would only be a workaround to this bug.

Making persistence mandatory for redstone chunks, on the other hand, would indeed "fix" this bug, but it would only be a band-aid fix, and with horrible repercussions (also, chunks have to be unloaded when your server or world is stopped, so this bug could still occur when restarting your server or world).

Ah, so the solution would be the creator of the map to choose which chunks would be forced to carry, perhaps by block command, but instead of loading the entire chunk, only the redstone of the chunk would be forced to load. How about that?

I'm not sure "only the redstone of the chunk would be forced to load" makes sense in the context of how Minecraft works. The only way for the game to tell where redstone exists in a chunk is to look at the blocks in the chunk, which would require loading the chunk. The only reason the game can choose what chunks to load is because it knows where to find each chunk - unless you created an "index" of what blocks in a chunk are redstone, there'd be no way to "partially load" the chunk. And even if you did, this wouldn't cover special cases, such as pistons which can push ordinary blocks, which would in turn create their own block updates (consider an automatic cobblestone generator). I don't think it's possible to implement a "load only the redstone", as redstone's very interconnected with the rest of the world - you'd be bound to find dozens of bugs, which would be a major headache to fix.

I think, if they let map makers force certain chunks to be loaded, it should apply to the whole chunk. This would also allow things such as minecarts to run, entities to age, items to despawn, etc. Regardless, letting mapmakers force certain chunks to always be loaded is not a fix to this bug. It is only a workaround, only works for mapmakers and server ops, and it's still possible that this bug would effect such chunks when closing and reopening the world/server (can somebody confirm whether this bug applies to the spawn chunk of your server during a restart?). The only actual purpose of letting mapmakers force chunks to stay loaded is for specific things you might want to build, such as a clock that's always running - such a feature should never be considered a solution to this bug.

As far as actually fixing this bug, I think the proper move is to ensure that redstone devices always save their Tile Ticks when their chunk is unloaded. Tile Ticks tell the game when a block or redstone update is supposed to happen in the future (or should have happened in the past and is overdue) once a chunk has been loaded: they are meant to save activity in a chunk, so things such as flowing water don't freeze just because a chunk got unloaded before the water flowed all the way. This bug appears to be happening because redstone Tile Ticks aren't always saved - particularly during periods of lag. If that can be corrected, this bug should finally be fixed.

Chunk linking tool would be cool too. For instance, a special block: once chunk is loaded that block would ensure that one specific neigbor chunk is loaded as well. This would be useful for machinery that doesn't exactly need to be loaded all of the time, but is bigger than one chunk and needs to be loaded simultaniously in order to properly work.

I don't know too much about Java but, couldn't you just have it so that when a chunk has active redstone in it, it saves the on/off state of the redstone and then when the chunk reloads, it puts the redstone's on/off state back to what it was when it was unloaded?

@Cody:
It already does that. The problem is, it doesnt update the state when the chunks load. Like, it forgot that theres redstone that was working when the chunk unloaded and now it just stays on or off.

@Raphael
Couldn't it be done so that when the chunks reload, they update all the blocks in the chunk.

Yeah Cody! That would work! I think...

That would produce massive lag. Thats what the tileticks are for, when the chunk unloads the tile tick save what blocks need to be updated when the chunk reloads.
The problem is that if the pc/server is under heavy load (which is the case most time you play minecraft), many redstone tile ticks arent saved.
Read Gerrards comment above, he already explained it.

Yeah, forcing updates to all redstone elements in a chunk upon loading would be a bad idea. For one, Tile Ticks can be scheduled: e.g., a repeater with a delay isn't meant to cause a redstone update until after its delay time is up. If you sent redstone updates to everything at once, this would still desynchronize timing-sensitive systems upon chunk loading: even if redstone would no longer freeze, complicated machines would still be damaged.

Lag would also be an issue, as Raphael said: redstone updates actually propagate to about two blocks away from the block that's being updated - I'm not entirely sure, but if everything updated at once, several objects may be updated multiple times in the process, due to an overlap in that 5x5x5 update cube - whether this would have worse consequences than lag, I do not know. At any rate, it would certainly be wasteful; if you have a long line of active repeaters, the ones in the middle do not need any updating - only the ones at the ends do.

I don't think the tile ticks are saved wrongly or something, but I think the problem is that as soon as a chunk gets loaded, the tile ticks are loaded to, but they are not all loaded at the same time, so when you have a simple repeater clock, one repeater gets updated, powering the redstone it is pointing at. And one repeater gets updated too late, so the redstone behind him is already on. In the end all the redstone is powered.
Although this might not be the case, because I've also seen a clock that just was stuck. So a repeater had redstone in the on state behind him, but it didn't get powered.

Yeah, that can't be it, because sometimes components freeze altogether - they never get updated. Also, tile ticks are scheduled events - they have a timer indicating when they should be activated; not every tick is meant to activate the moment a chunk loads (slow things such as max-delay repeaters and flowing lava come to mind).

While your theory seems plausible in some cases, it doesn't match everything I've observed: I have seen a very large repeater loop, with a very large pulse (consuming almost the entire loop) get shortened to a two-repeater pulse, because the leading edge froze and the trailing edge went through the loop until it caused a redstone update to the leading edge. This is not simply a matter of asynchronous loading; the leading edge does not begin to move until it gets a redstone update from the trailing edge.

I think some blocks just won't have a tile tick, because if I move the block one block to the right it doesn't get stuck, so the position of a tile tick has something to do with it. So sometimes one repeater gets updated, but another (since it's on another position) doesn't get updated, causing the clock to be fully powered (or not). And if a clock just completely freezes (one half powered, one half not powered) That's because both tile tick's aren't saved.

Yeah, that's what I think too. I'm not entirely sure it's coordinate-related, but then again, it very well could be (my testing clocks had many different repeaters; I can't be sure whether any one did freeze on one test but didn't on another).

At any rate, it still seems performance related for me - What happens if you lag your computer by running several instances of Minecraft? Does it make the bug more likely for you too? What about the rate on a server compared to the rate in singleplayer?

I do know that lag will affect block updates, as my desktop that my sisters have in their room (don't ask, its mine), when they run minecraft with the dozens of other background programs they have (I seriously regret getting a TV in my room...), their framerate is less than 5-6 fps on low render, regular lighting, etc. (you get the idea) and fluids, gravity blocks and redstone won't update reliably, or not even at all.

(Sorry about the ranting... my sisters seriously messed up my desktop. They even admitted that they get the Blus Screen of Death (windows crash screen) every day)

this needs to be fixed or it will be the end of all adventure maps

I can confirm.

This still needs to be fixed, the problems that redstone is only saved in two ways On/Off so when a chunk is loaded the redstone which was on loads as on and off stays off and they stay that way (like mcediting water and lava nothing happens untill block update) anyway I found this happens for all type of redstone including detector rails and needs to be fixed before 1.5 update.

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.

@jason That's exactly what I'm experiencing.
try moving the clock 1 block, that fixes it sometimes.

From what you're saying it seems like the redstone components are in-between chunk boundaries, which is known to cause problems.
I've just tested it on the latest snapshot and this seems to be it.
Here's a video showing the problem: http://www.youtube.com/watch?v=C5Zi6ErzdZ0

EDIT:
Note that the problem isn't that the repeater is crossing a chunk - the problem is that the left pulsar is sitting right on the boundary of 4 different chunks.

but why do all the repeaters inside the chunk get stuck too then? You'd expect them to all turn on/ all turn off

@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...

Can somebody please update the version information? Mojang probably won't look at this if it's supposedly not in the current snapshots - and this is a very bad bug to have for the 1.5 (pre)release tommorow.

I can confirm this for a server on 13w09b, although it took a few tries. Yes, the server is vanilla.

EDIT: Also, can the title be changed? It's misleading. In 13w09b, I managed to get a repeater clock to fully depower from teleports.

I managed to reproduce it and then I managed to change stuff so I no longer was able to reproduce it... I don't know any other way to properly verify that the bug is gone, or that I haven't added new bugs =( Please re-open this in future snapshots if you're able to find it again.

thx Jeb! 😃

Still occurring for me with 13w09c unfortunately 😞

Unable to reproduce.
Edit: Neither in SSP nor in SMP.

Reopened.

Definitely still happening in 13w09c. Just walking far enough away from a chunk with a redstone clock in it can leave the clock broken.

Still occurring in 13w09c singleplayer survival. To reproduce I need to get far enough to unload my piston clock. After returning to the clock, a repeater is unpowered, although the redstone connected to it is. If you need any other info, comment and I shall provide it.

Confirmed not fixed.

Confirmed not fixed in 13w09c SMP.

This seems to be related to MC-3259 - the underlying problem looks pretty similar: Some redstone components (especially repeaters but also comparators) don't update properly once a chunk gets loaded. A showcase for that problem can be seen in this video: http://www.youtube.com/watch?v=e_MM97ifASw

Still experiencing the same issue as described on my Feb 1 post using Snapshot 13w09c in single player mode. Experienced two stuck stone buttons in 22 uses.

I did some more experiments concerncing this issue. I managed to create a pretty simple showcase where you can get some redstone components to get "stuck" easily:

Create a setup like in "chunk-middle-problem-01-basic-setup-repeaters.png". (Note: Make sure to build everything inside a single chunk - marking the edges helps!) Set the command block on the very right to teleport you very far away (at least 10 chunks). Set all other command blocks to trigger "say" commands as shown on the screenshot. Edit: Make sure that the random chunk where you build this is very far away from the spawn as the chunks around the spawn will constantly stay loaded. The problem won't appear there! Teleporting 10000 blocks away from the spawn should bring you far away enough for this.

Stand inside the chunk and then push the button. You'll notice that even though you were teleported away (which means that the teleportation command block must have got fired), not all command blocks in the chunk got fired. Only the "say" command blocks 1-7 were fired (as you can see on the chat window).

When returning to the chunk, you'll see something like in chunk-middle-problem-02-repeaters-behavior.png. All repeaters "behind the chunk's middle" got stuck - which explains why the command blocks were not fired. (Side note: I had actually discovered this chunk middle problem in a different context before and reported it in MC-8194. The teleportation issue is a new context and therefore another problem type though.)

You can also build other kinds of signal transmission methods as shown in the following screenshots - with similar strange effects. (Only the "wire only" transmission method seems to work. The shuffled command block firing order you encounter there might not be considered a real bug because all redstone wire elements could be expected to get fired at the very same time - which makes the firing order undefined and therefore allows a random order.)

it said this was fixed in 13w09c, but it's not

happens on windows vista also

I can't reproduce this. Tried both SMP and SSP, building those examples with command blocks within a chunk. The order of the say commands is unpredictable, but that's because the order in which repeaters are triggered is undefined if they all get the power at the same tick.

Let's keep this open for the 10a snapshot.

Have you been able to try this on a computer under severe strain, or a fairly low-performance computer? I've noticed I only get the bug when I try to force my computer to its limits (to the point that "Server can't keep up! Did the system time change?" messages are being spammed) - I have yet to witness it when there was no lag. The problem is, it becomes more and more likely the more people are on my server (I'll try hosting Super Craft Brothers again in 1.5, as I've noticed it happen quite a bit there; the repeaters don't fully discharge at the end of a match before everyone dies, and they stay frozen active once we return to that map, breaking it).

My method for reproducing this: create a simple redstone repeater clock. A bunch of repeaters in a circle set to 4 ticks with a simple pulse injector to get them going should do the trick. Now leave the chunk (I usually see it by entering the nether and reentering the world in a different chunk). Go back and every now and then the clock will no longer be operating.

It doesn't always happen. On 13w09c, I'm seeing it only rarely.

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.

Jason, you may want to upload a zip of your world for Jeb to test, in the event that it actually does turn out to be reproducible at specific coordinates.

couldnt triggering physics on chunk load essentially fix this?

@Aikar: Be very careful with that. Triggering physics on chunk load runs the real risk of breaking a lot of devices, since it would mean triggering block updates for no reason other than that the chunk loaded. A better solution would be to defer unloading a chunk until all redstone behavior is in a safe state.

Confirmed not fixed for 13w10a. Here's a (pretty long) video demonstrating the bug: https://youtu.be/95fuuajDQMc (At the moment of posting this, the upload is still in progress. The video should be up at around 00:20 UTC+1.)

After watching the video you can try to reproduce the bug in my test world which I attached to this ticket.

Video upload and (first stage) processing complete; you can watch the video here: https://youtu.be/95fuuajDQMc

I have a map with 100% reproduction rate. I saved next to the clock. Just cut and reconnect the redstone wire to the repeater in question. Then grab the nearby boat and go far enough to unload the entire clock. After returning a repeater is always stuck in unpowered.
https://www.dropbox.com/s/j3wahkk8l0nky1z/Copy%20of%20Jamen.zip?m

The.Modificator, you sir are a gentleman and a scholar. I can reproduce your behavior completely on my computer; I see I was wrong to figure it had anything to do with lag (perhaps the fact that I was using circular repeater/comparator clocks caused the apparently "random" behavior because the repeaters would only freeze at certain locations, and the fact that I was teleporting pretty much continuously back and forth meant the chunks did not always unload). Your world download has a 100% reproduction rate for me - this will almost certainly help Jeb fix the bug, as you've sequestered it and analyzed its mechanics.

I should note, however, that the pure redstone wire test does not trigger all command blocks, as you said it did - the fourteenth never triggered. Fortunately, this is the same for me as it is for you - the bug's consistent.

Thanks for the help. I was able to use The.Modificator's world and stop the random behavior. Problem turned out to be that when ticks are scheduled, they are thrown away if the neighboring chunks haven't been loaded yet. Removing this check fixed the problem, and I couldn't discover any new errors.

I'm marking this as resolved, please reopen it if the bug occurs again in the next snapshot.

No longer able to replicate the bug under 13w10b. My hero <3 😛

Looks great! 🙂 It appears that MC-3259 was fixed as well by fixing this. Thanks, Jeb!

@Gerrard Lukacs: You're right - I didn't notice that in my demonstration world the command block with "say 14" was never triggerd when using the wire-only setup. However, I just realized that the cable is just too long to actually reach it. So another mystery solved. 😉 Also thanks a lot for your great feedback.

(again) thx Jeb! 😃

I'm sorry to bother this thread but I'm using 1.5 and it still seems to be happening to me constantly. Well really what happens is I attached a button to a block of stone. Then I put a redstone wire coming out of the block of stone and 21 repeaters following the wire. If I use a pressure plate button or trip wire the repeaters randomly freeze around the 10-15th repeater it gets a bit annoyting. Just saying and I'll attach a screenshot

The repeaters still freeze in 1.5. for some strange reason. I read that it was fixed but it still doesn't seem to be fixed for me.

@Megan:
Without teleporting?
And what is your system? That screenshot has an unusual resolution.

Well I'm not exactly very good with computer so it took me a while to figure out how to use the clip board. so I went on word and I just pasted it onto word then I just copied it back to my clip board. I was in creative mode (so I forgot to mention that) My system? I have a Windows 7 if that's what you mean. I was just flying around and I wasn't teleporting.

Im unable to recreate that, but this also seems to be not related to this bug, because your repeaters stop while youre still there.
With system i meant, are you using a normal desktop pc with Windows 7?

@megan can you give us with the map?

@Jesper It's just a single player world but the seed is 764906023386979050 and the Coordinates are x:-1538 y:56 z:98 (although the coordinates may not help much. It was on a super flat world and I was messing around wiht redstone so it wasn't redstone lag but after I teleported to a new chunk it didn't occur as often. @Raphael My bad I always forget to put things, it's not a desktop it's a laptop that is Windows 7. Plus I did try to reproduce this bug and the redstone still froze but not very long. The repeater signal kind of just stood still and then went the signal was further away but I've fixed the problem a little.

sounds more like lagg then.

I just found a frozen comparator clock (as shown in screenshot "comparator-stuck.png) in a dedicated server world (version 1.5 for both client and server). I removed all chunks not related to the problem (with MCEdit) and uploaded a zipped version of the world as "comparator-stuck.zip". The frozen comparator is located at 54/58/-31

Unfortunatley I have absolutely no clue how to re-produce this. It used to occur a few times before but always happens seemingly randomly. With the comparator clock cable lying on a chunk border my guess would be that it has to do something with unloading and loading chunks - especially with multiple players moving around in the world.

I also have a feeling that this used to happen only when restarting the server. (And I also have a feeling that the chunks in which the comparator clock is located were not be loaded in the moment the server shut down.)

This problem already used to occur before the change in 13w10b. This version 1.5 occurence proves that the 13w10b change did not help in this case though.

The odd thing is that they never fixed it...

This bug has not been fixed. All of my redstone clocks keep freezing in 1.5.1. It doesn't happen as often. It used to happen every time a chunk was reloaded, but now it seems fairly random.

I've not seen this happen in 1.5.1 but I do get a lot of messages of people who can't play my map anymore because the clocks stopped

I should mention that this bug is not fixed in Bukkit, and many people like to play maps in Bukkit (one of the more appealing features, ahem, is preventing cheating).

Stephen, are you in Bukkit, a vanilla server, or singleplayer? If it's not Bukkit, it may be worth Mojang's (and everyone's) time for you to create a world download containing some of the redstone. You can prune a copy of your world down to the effected chunks in MCedit if you don't want to share your whole world - just be sure there is a sample of frozen redstone in there.

I finally came back to this thread but @Jesper I wasn't lagging at all my frames were better than usual but I stopped messing w/ redstone (because I accidentally deleted the world...). By the way is it possible for me to leave the thread that way I'm not emailed about this because my problem is "resolved" by not using redstone...

@Megan At the top-right, click "Stop watching this issue".

Can someone reopen this? this is still an issue in 1.5.1

@Gerrard Thanks 🙂

Sorry Gerrard for the late response. This has happened to me on single player maps and multiplayer maps, both of which were vanilla. It doesn't happen often, but I will attempt to upload a schematic the next time I encounter the issue.

Confirmed for 1.5.1 Vanilla Singleplayer - this bug is not actually fixed. I'll upload a demonstration world shortly, but I am unable to devise a pattern in the bug's occurrence - it seems more likely at chunk borders, but can occur anywhere within a chunk as well.

It's not as detailed as The.Modificator's test, but it shows the bug. Use the command block to teleport far away, and then back, and you'll find a seemingly random number of clocks have frozen. The clocks which freeze varies each time you try.

This time, all clocks freeze in powered state: there are no clocks which freeze to an unpowered state.

Confirmed with the attached world.

I'm glad that Mojang finally reopened this.

This is also a problem on Mac to.

MCedit indicates that the clocks are frozen once the chunks are unloaded, rather than upon reload: teleporting, and then saving and quitting, and opening the world in MCedit shows a sight identical to what you would see upon teleporting back.

It should be noted that tileticks do not get saved properly for the clocks which freeze. All healthy clocks have at least one tiletick per repeater - some, strangely, can have two tileticks on a single repeater. A clock with only a single repeater bearing tileticks, or none at all, will be frozen, and MCedit will already render all its redstone as active. My record appears to be five tileticks in a single clock (one repeater has two, the other has three), and this clock is healthy and runs a half-tick pulse.

Why so many tileticks are saved for some blocks, and none at all for others, I do not know. Apparently tiletick saving is asynchronous? Perhaps, when a chunk is to be unloaded, all activity in that chunk should stop before attempting to save any tileticks? I.e. does it stop processing ticks in the chunk altogether before attempting to save it to disk?

Someone please add Mac to the environment list.

Here's what happens to me:

When I make a redstone machine that repeats itself over and over it freezes wnhen the chunks are unloaded.It also happens on a mac.

Snapshot 13w10b did not fix this issue.

I'm haven't experienced this bug in the past month (or since 1.5.2). Is anyone else still experiencing this issue?

@John Stewart

I have

Jeb thinks he's fixed it. idk I haven't tested the dev versions.

Confirmed for 1.5.2; haven't tested on the snapshots.

Confirmed for 1.6.2; I'm starting to resort to abusing chunk loading bugs as a workaround to this issue.

Confirmed for 14w03b using "MC-711 Redstone Bug Test.zip"

tp @p ~500000 ~ ~
(wait a few seconds)
tp @p ~-500000 ~ ~

Some of the circuits will stop working.

EDIT: Not sure how/if I'm able to update the affected versions...

Is this still a concern in the latest Minecraft version 14w21b? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.

I've not seen this bug in a long time, but I'm pretty sure it's not fixed. Though I can't confirm that.

Confirmed for 14w21b using "MC-711 Redstone Bug Test.zip"
— tp @p ~500000 ~ ~
— (wait a few seconds)
— tp @p ~-500000 ~ ~
— Some of the circuits will stop working.

*Added screenshot

Ahh yes, I have seen this bug in my 1.7.2 map.

Confirmed of 1.8.2-pre1.

Here's a bunch of stuff that might help the developers out.

1) Reloading the world doens't seem to cause any issues, redstone always continues.

2) Running away from the chunks, the walking back, causes all the 20Hz redstone clocks to stop. It will stop all redstone clocks if you unload at the right tick.

3) Teleporting away from the chunks, then teleporting back, causes a specific position of redstone clocks to stop. Every chunk seems to have some sort of binary yes/no value, that defines whether or not a redstone clock stops if unloaded in the correct tick when you teleport away. http://imgur.com/pqnreZg this is a visualisation of all chunks that stop. Wherever water spilled, clocks in that chunk stopped. The most bottomleft chunk is (-1,-1), going up X to the left and up Z upwards. Notice that wherever chunkPosX = chunkPosZ the clocks do not stop.

How to reproduce: Setup a 20hz fill clock. Put two command blocks on it. One sets a block to flowing water, somewhere up in the air. Surround the flowing water by glass on all corresponding Y positions to prevent it from spilling to the sides. The second command block sets the block below the flowing_water block to air. Whenever the fill clock stops running, the water spills everywhere.

Something else to note, according to the command block output, it seems that redstone updates process one tick after the chunk blocks unload. This causes all redstone activity to give a "can't access stuff outside the world" error, and so the clock stops. If the clock continues, the redstone is saved as a tiletick (like it should), but if it stops, the command blocks show the "can't access stuff outside the world error", and only the water gets saved as a tiletick. I've been digging in the decompiled code for a bit, but my java knowledge isn't good enough to really find out what's causing this behavior.

All of the powered ones stayed powered/
The ones that look off are running
The picture with two, they are both in two different chunks but the bottom one is oriented differently.
Also 2 of the failed clocks are setting on 0,0,0 of their respective chunk. I don't know if that is just a coincidence or if it really does have something to do with it all. I did the second one purpose and it stopped right away (after flying a long distance and tried one with tp far away)

Hope this is of some use.

@Mods I don't know if this has anything to do with it but if the redstone clock is on the edge of a chunk and takes up space in two chunks, this has a higher chance of happening. and in two of my experiments, two of the failed clocks were on chunk coords 0,0,0 of whatever chunk it was in. I was looking at chunks 150 and 149. I took pictures and attached them. I was unable to get this to replicate with hoppers though. Something cause them to either duplicate items randomly or with using unstackable items,, the item goes super fast that the comparator doesn't have time to react.

Why don't you have a main teleport station where you set the world spawnpoint by using /setworldspawn. That means that your teleport station will always be loaded, even if you are in another dimention. All the other teleport stations can use the /setblock command to place a redstone block at the main station, which can teleport the player and reset the station the player used.

I just thought if this still mattered to you, this can be a workaround.

Why doesn't Minecraft just summon an invisible entity for all the redstone components that can keep redstone running, even if the chunk is unloaded. That would be a help to everyone.

@unknown, not really. That would keep all chunks in large redstone maps loaded forever, which would result in massive lag. Chunks are unloaded for a reason.

That wouldn't be my approach. Best way to implement that would be to add a gamerule or a way to enable and disable that feature, if it were added.

Confirmed for 1.10.

Sorry if this was somewhere in the last 100+ comments already, but: Could it be location dependent? I reproduced this more than 50% of the time before, now I can't get it to ever happen, after I moved it.

I found through searching:

• "the fact that I was using circular repeater/comparator clocks caused the apparently 'random' behavior because the repeaters would only freeze at certain locations"

• "I think being able to reproduce it is relative to positioning or area"

• "I'm not entirely sure it's coordinate-related, but then again, it very well could be"

• "in the event that it actually does turn out to be reproducible at specific coordinates"
  Nobody is sure? Is that still the case? I also wasn't able to find a code analysis.

@unknown: ticket is yours now. Please update it accordingly. Thanks!

Oh thank you!
I updated the description with what I found out. 🙂

I'm unable to reproduce, even though I think I've seen it recently. Does someone know a reliable way to reproduce it?

Is this still an issue in 1.14.4 or later?

Can confirm for 1.16.1

Can confirm for 20w51a.

Can confirm in 1.17.1.

can confirm in 1.18.1