Talk: Redstone Repeater

Third ID

The Repeater has a third ID: 356. I guess this should be in the article too, but i dont know how to implement a third ID. --Marvin 19:28, 22 February 2011 (UTC)

I've added the third ID as "Repeater item;" feel free to change as necessary. --Simian 02:23, 23 February 2011 (UTC)

not gate/invertor

after a bit of trying i can confirm that a repeater directly next to a door will work as a NOT gate/invertor, and it won't delay regardless of the selected mode

next to a dispenser it fuctions as nothing on the 2 shortest modes (1,2), the dispenser won't get activated in any way. on the 2 longer modes (3,4) it does act as a NOT gate/invertor. again no delays. –Preceding unsigned comment was added by Triodes ^{(Talk|Contribs)} 20:34, 22 February 2011 (UTC). Please sign your posts with ~~~~

There is something subtle about the Repeater being a compact NOT. At first I thought it had something to do with the south west rule, but it seems that there is something subtle I don't get. When I tried to record a video of my tests, in order to make the video "cooler" I re-arranged the redstone pieces, and it did not act as a NOT anymore.--Ha3 21:10, 22 February 2011 (UTC)

Ok, It's not a compact NOT gate. The behaviour of this block is really weird. You don't deal with Inputs and Outputs there, you're dealing with wire updates, but not only wire updates.

Say you have Input A, and Input B. Then you do "(A or B)--(Repeater)(Note Block)".

If you activate A, it will be a NOT gate when you release A.

If you activate B, it will be a NOT gate when you release B.

This sounds weird, but that's the way it is, accotding to my tests.

If you activate A, then B, then release A, it will trigger the Note Block. Even if the Repeater input does not change state. When you release B it doesn't do anything.

If you activate A, then B, then release B, then release A, it will trigger the Note Block.

Of course, there may be something more subtle than that.

Video of my tests here : http://www.youtube.com/watch?v=6orTZPButAM --Ha3 21:41, 22 February 2011 (UTC)

So, just to clarify: A repeater placed directly next to a redstone capable bloack will turn into a NOT gate after one input is turned on and off.

Picture: http://oi52.tinypic.com/rm69o4.jpg

Feel free to add it to the page, because I don't know how to... Frubban 21:51, 22 February 2011 (UTC)

To shed some light on this issue, the repeater is not acting as a NOT gate. It seems repeaters just do not update redstone capable blocks directly however they do power them. The reason the repeater seems to act as a NOT gate is becuase on update of the repeater's input when using wire or a torch, the redstone capable block will be updated to the output of the repeater at the time the repeater's input changes state. Becuase repeaters have delay, the redstone capable block acts according to the previous state of the repeater.

i.e. Here's is this outlined step by step.

1. WireOFF->RepeaterOFF->DoorSHUT
2. WireON->RepeaterOFF->DoorSHUT - turn input ON, update from Wire at this time,, Repeater is OFF, Door remains SHUT
3. WireON->RepeaterON->DoorSHUT - update was in previous tick, Door remains SHUT

5. WireOFF->RepeaterON->DoorOPEN - turn input OFF, update from Wire at this time, Repeater is still ON, Door OPENS
6. WireOFF->RepeaterOFF->DoorOPEN - update was in previous tick, Door remains OPEN

7. WireON->->RepeaterOFF->DoorSHUT - turn input ON, update from Wire at this time, Repeater is still OFF, Door SHUT
8. WireON->RepeaterON->DoorSHUT - update was in previous tick, Door remains SHUT

9. GOTO 5. Repeat ad infinitum.

As you can see the observable effect is that the Door is in the opposite state of the Wire at all times: making the repeater appear as a NOT gate. With noteblocks and dispensers which activate on the rising edge, a similar analysis can be made.

If one were to power the repeater using a block e.g wire->block->repeater->door, this effect would not be seen as the wire is too far away to update the door and blocks only update immediate neighbours. In this case, the changing of the input has no effect on the door. Should one force an update on the Door in any other way with this setup, the Door will OPEN or SHUT according to the repeater as 'normal'. Icks 20:45, 16 April 2011 (UTC)

"so that using two not-gates every 15 blocks will no longer be necessary".

Instead of using 1 not-gate every 15 blocks, you use 1 repeater. It costs you 1 more redstone wire, 1 more red torch and 3 more smoothstone per 17 blocks. Why is it better?

IMO this should be removed. DiEvAl 16:04, 23 February 2011 (UTC)

It's more space efficient. Duh. --Zemedelphos 22:35, 23 February 2011 (UTC)

This should NOT be removed but edited so it says its a more expensive but more space efficient and better timeable repeater (also you would just save the smothstone since the not gates (which do the same as the repeater - a single not gate inverts the signal a repeater doesn't)) Djerun 23:19, 23 February 2011 (UTC)

Confusion

Experimenting and came across a behavior that I don't understand the purpose.

For all intents I was using this block as a diode. Had 3 inputs that share a 'T' the south line received a south oriented diode. This would mean both the East and West inputs could effect South and South could effect nothing. BUT, my inputs/outputs were RS torches on blocks and the redstone lines ran to the sides of these blocks. If I place the southern diode 2 or more away from the southern torch the signal would pass though the diode and turn it off.

However if I placed it 1 away from the block, the incoming redstone signal would hit the diode, pass though to the single redstone on the other side but the torch would not go out. Removed the redstone and placed the diode flush against the RS torch block and it works fine.

Two, or more away fine...what is magical about being 1 block away from the side of the RS torch 'stand'?

Also works 1 away if there is another diode as the connection rather that wire.

Dctrjons 09:51, 23 February 2011 (UTC)

Fixed it looks like in patch update.Dctrjons 01:45, 25 February 2011 (UTC)

Thumbnail

the piture of the reapeter in the items box is a ladder do you think you could change it? –Preceding unsigned comment was added by Ak471998 ^{(Talk|Contribs)} 13:46, 23 February 2011 (UTC). Please sign your posts with ~~~~

Clock Restarter

I created a 4/5 clock an hooked 17 inverters to the output of the Repeater and the 17th inverter output to the input of the Repeater. When reloading the world it take some random time until the clock starts running again http://dl.dropbox.com/u/16772102/2011-02-23_17.16.44.png

I don't know if this changes the clock rythm or something like that...

EDIT: seems not always to work one vid shows it working and one shows it not working http://dl.dropbox.com/u/16772102/javaw%202011-02-23%2017-29-35-60.avi http://dl.dropbox.com/u/16772102/javaw%202011-02-23%2017-17-08-64.avi (first vid up second needs some time) --Djerun

UPDATE: I noticed that even when a block next to a repeater was chaned (which had nothing to do with its circuit) it would make the repeater running again so I build a 5-five clock right next to it with no connections. The five clock was also frozen on restart... I modified it a bit http://dl.dropbox.com/u/16772102/2011-02-23_23.49.56.png and it works I also made another vid showing it (needs some time though - both the vid to upload and the time to start the clock again) Djerun 23:20, 23 February 2011 (UTC)

My tests result in the same as Djerun's - a repeater will reactivate if a block next to it which it does not have a connection to is updated. I have a 1-clock which, after a short pause, will be triggered on load by a nearby 5-clock, continuing as it was without need for interference. http://dl.dropbox.com/u/12899858/Screencap/ScreenShot032.png To the right is a pulse generator that was used to initiate the clock in the first place, to the left is the 1-clock and maintaining 5-clock. The main page should be updated with this information to maintain fast clocks. --Airwolve 13:03, 24 February 2011 (UTC)

Nicely done, but this only works if you force an update on the repeater stuck in the "on" state. If the repeater that is off is updated first, the loop becomes saturated (both repeaters get stuck on).

There doesn't seem to be a way to update both simultaneously. I suspect that is not actually possible because of the way redstone has been implemented. I think that the repeaters normally trigger each other's updates as they change state. When you reload the world, the update queue is emptied and the reaction stops.

It might be possible to wire seperate restart circuits to each end of the loop, so that only the correct side is updated. However, I haven't figured out how to build such a circuit. If it's made from torches then they burn out while the clock is running and if it's made from repeaters then they get stuck on reload just like the clock. Last username 04:36, 25 February 2011 (UTC)

For the ultimate case of automatic restarting, I figured out a circuit shown in Minecraft forum thread [1] . For clocks which do not have strict requirements on timing accuracy, already found methods with simple torch clock are enough. Also, some of the peculiarities of redstone, especially the way a change in state of nearby redstone causes an update on another torch or repeater, are explained in my another, older thread [2]. Alas, I haven't "cleaned up" that thread yet, so the details are buried in the replies. --Bugi74 10:00, 5 April 2011 (UTC)

"1 Clock Restarter"

Im not good at editing wiki pages, but i invented a 1 clock starter. I added the image but someone may want to edit the text. I dont know the diagram for the repeater, so i made it up with subscript numbers in the corner to show the setting they're in. It mostly relies on a quick off pulse, that will pass through the inverter torch, and start the clock. image: http://fadeddreamz.com/games/1clockstarter.PNG --pspprogramer –The preceding undated comment was added on 04:24, 25 February 2011. Please sign your posts with ~~~~

Edit: Regarding the automatic restart I have finished testing a circuit that will attempt a restart on it's own, but if it fails it won't try again, and you will have to press a button to override. typically on reason it will fail if there's something wrong with the clock. I'll make and post diagram tomorrow, but for now here is a screenshot of the test version. (not final compact design) http://fadeddreamz.com/games/2011-02-25_00.24.52.png pspprogramer –The preceding undated comment was added on 05:26, 25 February 2011. Please sign your posts with ~~~~

All Redstone Is Broken

I just noticed that the no update on reload bug is not limited to repeaters. Torches have the same problem. Build a plain old 5-clock from torches, reload the world, and it gets stuck until you trigger an update. I've never noticed this before so I assume it's a new bug with beta 1.3, though it's possible that it's been around longer. I'll report it on GetSatisfaction and I won't bother trying to hack around it since that would be practically impossible. It's a bug and it just needs to be fixed. Last username 08:24, 25 February 2011 (UTC)

I have never seen this behaviour, so if it really existed, it was fixed quickly. However, all redstone is indeed "frozen" at reload, but at least since 1.2 (that is when I first looked at the source code) the game does steadily a number of updates per "tick" spread on random blocks, including redstone torches, so normal torch based 5-clock will automatically start sooner or later, when such random update happens to hit the particular torch whose input and output states are in "unstable" state. --Bugi74 10:00, 5 April 2011 (UTC)

No this has always happened It is something to do with how the game is saved I remember this happening a long time ago in the beta 109.125.50.17 10:16, 25 September 2012 (UTC)Kondroid

Permanent powered wire

I found that placing a repeater, giving it power, making sure the output is one block higher than itself, and then destroying it, would leave the higher wire still powered. I made a short clip of this here: [3]

As you can see, it also allows you to make torches that stay off (of course only until a block near it updates) --Tarnasa 20:09, 5 March 2011 (UTC)

Delay

Apparently there's still some controversy on exactly how long a "delay" lasts. I can't understand the code for repeaters, but here it says a delay is 0.1 seconds. I just tested it in 1.4, and a line of 10 delay-1 repeaters is lit after 1 second. A line of 10 delay-4 repeaters takes 4 seconds. This would imply that a delay is indeed 0.1 seconds, and thus 2 ticks. Am I just misunderstanding something? -Alphap^T~C 03:04, 7 April 2011 (UTC)

Delay is based on FPS, and I can confirm that the delay of 2 1-tick repeaters is the same as the delay of 1 2-tick repeater, indicating no delay per unit. Darkid 03:11, 7 April 2011 (UTC)

The last time I checked source code (version 1.3 something), the delay was indeed based on real time (NOT FPS!), and also, the repeater delay of 1-4 corresponds to "torch delays", and each torch delay is 2 "game update ticks" (which are based on real time, as mentioned). However, there are some differences to what is expected from repeater's seemingly simple operation, and these come from the way the update mechanism are made to work on repeaters and how torches, repeaters and redstone wire activites can affect each other even from 2 blocks away. For example, a very short pulse can become lengthened when it travels a repeater with higher setting than 1. These weird changes may be reason for some controversy. If someone really thinks repeater's delay is based on FPS, please bring source code evidence for that - I've studied and shown pieces of source code for version 1.3 (on Minecraft forums) with the evidence for real time based operation, and I have no reason to think it would have been changed since. The piece of text darkid last removed was actually correct, though I would have used more definite terms in the text, referring to "1 torch delay" and "2 game update ticks", while the simplest part of "0.1 seconds" is unambiguous and correct. -- Bugi74 15:37, 8 April 2011 (UTC)

I came here looking for the official word on what delay each setting gives; I can't remember if it's 1-2-3-4 or something else - could someone who knows add that to the main page? --JamesOfJames 06:53, 27 May 2011 (UTC)

Official name

Since the official ingame name of this item is Redstone Repeater, is there a reason for the brackets around "Repeater" in the article title? -Alphap^T~C 06:24, 19 April 2011 (UTC)

Yes, it's to differentiate between Redstone Dust, Redstone Torches, and Redstone Repeaters. They are all Redstone items, so they could easily be confused. --Technoman7 15:25, 21 May 2011 (UTC)

That's not really what Alphap was asking. They want to know why the article is at "Redstone (Repeater)" instead of "Redstone Repeater", since the in-game name is the latter. 「ダイノガイ千？！」^{? · ☎ Dinoguy1000} 20:19, 22 May 2011 (UTC)

I've also been wondering about this. The item is called "Redstone Repeater" in-game, not just "Redstone". As such, the parenthesis is unnecessary and actually causes confusion rather than clarifying anything. -- Techpriest88 00:10, 16 August 2011 (UTC)

Line adaption

Why doesn't Redstone wire automatically bend to accommodate repeaters like it does torches? Is this intentional, or a bug? Right now, I need a line of three unbent blocks to place a repeater, stretching circuits. Weckar 16:40, 29 May 2011 (UTC)

Jeb has stated that this will be changed in the next version so that redstone does bend toward repeaters.Tarnasa 05:51, 19 June 2011 (UTC)

Time per tick

I thought that each tick was 0.05 seconds (1/20 of a second). It says in the article it's 1/10 of a second. Is this a typo or a mistake or am I wrong? –Preceding unsigned comment was added by Kjaisb ^{(Talk|Contribs)} 08:09, 20 June 2011 (UTC). Please sign your posts with ~~~~

Not propogating downward?

I was testing with some redstone and it appears that the repeaters don't propogate downward anymore. Can anyone else confirm this? CertainlyNot 12:53, 20 June 2011 (UTC)

Repeater bug

As shown here, the middle line of redstone, where the diode is one block from the raised torch, the torch is not altered by a charge being given. –Preceding unsigned comment was added by Nklvh ^{(Talk|Contribs)} 19:34, 17 August 2011 (UTC). Please sign your posts with ~~~~

SMP Redstone/Repeater bug

On my 1.8.1 Server Repeaters in simple clock circuits (4 Repeaters + 1 Redstone Inverter) get stuck if you disconnect and connect again! Sleeping doesnt matter. It seems like the server didnt save the state or elapsed delay time of the Repeater rightly. The circuit continues if you change the delay time or destroy and replace the Repeater. The same even happens with a normal 5-Torch-Inverter Clock! Quite annoying and a serious Redstone bug in my oppinion! –Preceding unsigned comment was added by 86.32.239.44 ^(Talk) 17:57, 23 September 2011 (UTC). Please sign your posts with ~~~~

EDIT: The Redstone clock seems to start itself randomly again after some time, the Repeater clock doesnt –Preceding unsigned comment was added by 86.32.239.44 ^(Talk) 09:04, 24 September 2011 (UTC). Please sign your posts with ~~~~

EDIT2: Setting time manually (time set xxxxxx) also stops the Repeater Clock –Preceding unsigned comment was added by 86.32.239.44 ^(Talk) 17:01, 25 September 2011 (UTC). Please sign your posts with ~~~~

Redstone repeater updates still broken in SMP?

The main page says:

"Before 1.0 repeaters would hold what state they are in when the game is quit but when the save was reloaded they would not pass on power. This meant that clocks had to be restarted every time you played the game."

On my SMP 1.0 server, I'm still seeing stuck repeaters. The wiki page says otherwise. Can anyone confirm/deny that this is fixed on SMP? Yoss 17:51, 10 January 2012 (UTC)

I've been having this trouble too in 1.4.6 SMP. My clocks stop sometimes after I've logged out. Screenshot of a stuck repeater: http://imgh.us/2013-01-10_23.14.23.png Alvilda 22:22, 10 January 2013 (UTC)

Redstone Repeater Symbol

Why is there no statement about the triangle symbol commonly used in redstone circuit designs? –Preceding unsigned comment was added by 134.129.22.152 ^(Talk) 00:44, 27 July 2012 (UTC). Please sign your posts with ~~~~

I don't see why there should be one; all the schematic diagram symbols are user-created, not official textures. -- Orthotope 07:59, 30 July 2012 (UTC)

How do you make a circuit where the redstone repeater doesnt make it lit forever after starting the circuit?

Lets say there is a straight 20-block redstone line and there is a redstone repeater thing on the side of the line about midway to keep the current on throughout the line. How do you make the redstone repeater part so that you can turn the redstone line on and off from the first redstone whithout breaking the straight redstone line? –Preceding unsigned comment was added by MuttonChops77 ^{(Talk|Contribs)} 06:06, 31 July 2012 (UTC). Please sign your posts with ~~~~

Connect your switch (or other input signal) directly to the repeater, and use that to power the entire line, rather than trying to apply power from one end. -- Orthotope 06:51, 31 July 2012 (UTC)

Delay

I think that the delay for the default state of a repeater should be 0 ticks, like (as an example) on a random death machine, that would randomly decide when you would die, and the screen is a good 100 blocks away for clarity. At which point you would have to add a crap ton of repeaters and it would create a ton of delay. Not so useful when it is something like the ender dragon coming at you, or another big angry thing. Or lava, possibly incoming water. Trigger hurt 20:29, 3 October 2012 (UTC)

Possibly the quickest way to send a signal downward:

I have not any access to a pc that can run minecraft, so feel free to test it out yourselves:

If you can please correct the ? boxes. It is a loop, and the repeaters should be facing the other way... Trigger hurt 21:02, 3 October 2012 (UTC)

Fixed diagram; the full list of available icons can be seen at {{BlockSprite}}. -- Orthotope 01:31, 4 October 2012 (UTC)

• THANK YOU!!! God I've been trying to just figure out the thumbnails for each one. I have reversed the diagram since redstone repeaters are facing the wrong way. Trigger hurt 13:37, 4 October 2012 (UTC)

Also a note to those who tested this: If you prefer to use stairs or other slabs for aesthetic reasons, they will work just fine. Trigger hurt 14:44, 4 October 2012 (UTC)

I also just figured out another way that is even more efficient (but more space costly) than this one. it is 3x3 total length and width, with infinite stretching parameters. Just make a 3*3*x with a hollow center and make a staircase, putting in repeaters like this:

latch

the latch page should be merged with this page, as the latch is just a function of a redstone repeater.19:38, 22 October 2012 (UTC)

I'll go ahead and do this (merge+redirect), if nobody else is working on it. djr013 (talk) 16:36, 23 October 2012 (UTC)

Repeater extension range nitpicking

Repeater

The primary function of the repeater is to "refresh" the redstone signal passing through, allowing it to travel another 16 blocks. Previously this could only be accomplished by using one/two NOT gates. However it is worth noting that although the delay and size is smaller than using NOT gates, it is impossible to extend a signal more than 16 blocks without at least a one-tick delay.

This is incorrect. If one uses a solid block between the wire and the repeater, it's possible to extend the signal 18 blocks horizontally using a single repeater (one-tick delay).

I.e.

instead of

--95.178.213.51 04:08, 3 January 2013 (UTC)

But that requires you to have a repeater to start with. It says it is impossible without at least a one-tick delay, which you've already introduced due to using a repeater at the start.

Yes, you can extend it further than 16 blocks in a single tick, but the one-tick delay would already be there. –ultradude25 ᐸ Talk
Contribs 06:33, 3 January 2013 (UTC)

Lighting change

After 1.8, apparently repeaters no longer provide light when on, much like comparators. Morenohijazo 21:31, 6 September 2014 (UTC)

Confirmed, fixed. —munin · · 20:45, 6 September 2014 (UTC)