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.  -- Unsigned message

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?

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

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

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)

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:

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)