8

While playing SMP, the issue of redstone repeaters "locking up" (getting stuck in the on state) was brought up. Another user showed me their issue, a redstone clock using two repeaters and redstone wiring that was no longer "ticking". Breaking and replacing the offending repeater fixed the problem. They claimed that this issue was caused by unloading the chunks the repeater was in, while it was powered. Curious, I set about my own tests: a lever next to a repeater failed, multiple times, to create a "stuck" repeater; creating my own, identical, clock, also failed. Thus leading me to my question:

Under what circumstances will redstone repeaters become "stuck" in the on position (and if it only sometime occurs, what seems to be the probability)? (It may help to consider that this does not (to the best of my knowledge) occur in single player.) Information on fixes is also appreciated.

Improve this question
4
  • 2
    One 'fix' is to abandon the old "two repeater" clock in favour of two hoppers pointed at each other with a single item in them. Use a comparator to generate power from it, and if you need to stop the clock, simply power one of the hoppers (as soon as that power is turned off, the clock resumes). Commented Jan 7, 2014 at 5:28
  • 1
    I have a redstone clock in my world that uses two repeaters next to each other that lock up quite frequently. I noticed that half the clock was in one chunk and the other half in another chunk. I believe that was the reason why they would lock up so frequently. Commented Jan 7, 2014 at 6:16
  • Interesting, I wont be able to test until next weekend, but I shall see if this is the cause. Commented Jan 7, 2014 at 15:37
  • Well, it looks like the problem clock has both repeaters in the same chunk. Any other theories besides the typical random glitching we expect from MC? Commented Jan 11, 2014 at 5:58

2 Answers 2

Reset to default
2

I've had this happen to me once - my clock crossed a chunk boundary. When I left too far away from the clock, this causes one of the chunks to unload before the other. When only half the clock is in loaded chunks, the clock freezes.

To resolve this, you can put the clock in a single chunk:

  1. Walk to your repeater clock and press F3.
  2. In the upper left you'll see your coordinates, with a number in parenthesis next to X and Z. The numbers in parenthesis are the chunk coordinates.
  3. Walk the perimeter of your clock. If the numbers in parenthesis change, you've crossed a chunk border. Move the clock over several blocks so the entire circuit is in a single chunk.
Improve this answer
1
  • So does this issue only affect redstone clocks? Also, does causing a block update next to the "stuck" repeater resolve the issue? Commented Jan 9, 2014 at 0:38
1

The actual reason this is happening is indeed chunk unloading.

The server "loads" chunks in a defined radius from each player. (see server.properties)
As long as players are around, the server keeps the chunk loaded and spawns mobs, updates redstone, grows grass, ...

However, if no player is near enough your clock to keep the chunk loaded, it will "unload" after some time to free some RAM and thus will stop updating redstone.

Note: When a repeater changes from off to on, the game actually changes the type of block (from 93 to 94)

As soon as a player comes near to the clock and loads the chunk, the server will just see the block 94 and won't update it. This is probably a bug, however there are some methods that will keep running after a chunk has re-loaded.

I'm not sure about singleplayer. The singleplayer is actually just a locally hosted server, but it does act a bit different, it should be simple to figure out though.

Keep in mind that (in the default server) the chunk-radius around spawn will never unload as long as a player is in the world.

Improve this answer
1
  • But why wouldn't another redstone signal update it? Commented Apr 19, 2014 at 16:54

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.