When repeaters recieve a 1-tick pulse, they lengthen the tick depending on the number of ticks they are set to.
Steps to Reproduce
Set up a circuit as seen in the screenshot. This circuit will produce a 1-tick pulse when the block in front of the observer is updated.
1. Place/remove a block in front of the observer. The redstone torch will not blink off, this may be due to a different bug, but let's ignore that.
2. Set the last repeater in the circuit to 2 ticks, then place/remove a block in front of the observer. The repeater will blink off, but you will notice that it is noticeably longer than one tick.
3. Set the last repeater in the circuit to 3 ticks, then place/remove a block in front of the observer. The repeater will blink off, but this time it will blink off for longer than the previous time.
4. Set the last repeater in the circuit to 4 ticks, then place/remove a block in front of the observer. The repeater will blink off, this time even longer than the last time.
This is not intended behavior, repeaters are supposed to delay redstone inputs, not lengthen them.
Linked issues
Attachments
Comments 16
A repeater set to a delay of 2 to 4 redstone ticks will increase the length of any shorter on-pulse to match the length of the repeater's delay, and suppress any shorter off-pulse. For example, a repeater set to a 4-tick delay will change a 1-tick, 2-tick, or 3-tick on-pulse into a 4-tick on-pulse, and will not allow through any off-pulse shorter than 4 ticks.
If you need to delay a signal by 4 ticks without lengthening it, simply use 4 1-tick repeaters in sequence
Btw, I suggest waiting for one of the mods to look at this - this isn't the place to discuss what Minecraft should or should not be (or for any other discussion)
Aw... Well, at least I figured out how to work around the problem shortly after reporting this. Kind of stinks, though. Maybe this is why my castle-gate piston door isn't working.
So far as I know, repeaters are supposed to lengthen short pulses and many redstone contraptions rely on this. If this is changed, this would be a change to fundamental behaviour of repeaters that is unlikely to be popular. This change should not be considered without discussing it with the player base.
this would literally break EVERY single redstone contraption that worked since 1.5.... please do not change this behaviour!
This bug is one of those bugs like quasi connectivity. It is used so much that it would break more than it would fix. I also believe this is a bug in unified edition and I would support it's fix there.
I had a quick look at the code, albeit without all my requisite caffeine. There are two functions I'm pretty sure we need to be concerned with here.
The first is BlockRedtoneDiode.updateState. This is called as a result of a neighboring block changing state.
If the repeater powered state is different from the state computed based on neighbors, an event is scheduled for the repeater delay into the future.
The next method we care about is BlockRedstoneDiode.updateTick, which is called by WorldServer.tickUpdates, which calls updateTick on every scheduled update that comes due.
If the repeater is locked, nothing happens.
Then a flag is computed that's true if the repeater should be powered.
If the repeater is powered but the flag is false, the repeater is depowered immediately.
If the repeater is powered and the flag is true, nothing happens.
If the repeater is not powered and the flag is true, the block state is set to powered immediately.
If the repeater is not powered and the flag is false, the state is immediately set to powered, and then another tick update is scheduled for the repeater delay into the future.
It is important to note that updateTick relies on the fact that it shouldn't be scheduled unless a state change is required. This is why updateTick sets the state to powered unconditionally, even if "should be powered" comes out false by the time updateTick is called. That is, if the current state is depowered, and an event has been scheduled, then obviously, there must have been a reason to schedule an event to power it, even if that reason has since then disappeared. If the logic didn't work this way, zero tick pulses couldn't be detected and transmitted by repeaters.
In any case, this is the reason that a repeater lengthens a pulse. If it's supposed to get powered, it changes state to powered and then scheduled another even for its delay into the future to turn itself off (if conditions warrant that).
Repeaters are meant to add latency, so when a neighbor changes state, it doesn't change its own state immediately. Instead, updateState scheduled a future event. So a repeater doesn't change state until its delay into the future.
When that future point arrives, THEN it changes state, which will update neighbors. This is why observer blocks are tripped at the end of a repeater's delay, not at the start, and this is also when piston extensions are set off, etc.
But once a repeater has turned on, it has to be turned back off again, and we have to ensure that conditions for that are checked in the future. This is why updateTick schedules another tick update another delay into the future. In theory, another update would usually be coming from neighbors later, regarding the condition that would turn the repeater off. But this would not be the case for zero tick pulses. It looks like if a repeater received a zero tick pulse, it would just stay on forever, if we didn't have the call to worldIn.updateBlockTick in updateTick.
If we wanted repeaters to insert ONLY delay without lengthening pulses, a bunch of other code would have to change to turn zero-tick pulses into two block updates that always occur in the right order in the same game tick.
The bottom line for this is that I don't see any obvious mistakes. In fact, it all looks perfectly sensible and intentional.
Erik Broes
This is intended, and has been the case for as long as I can remember