The Bug
When you send pulses into arrays of repeaters in quick succession, they will be lost.
How To Reproduce
Build setup as seen on picture
[media]
Push the button
→ ❌ Notice how the signal travel through all the repeaters but the last one.
(Note: this description uses “redstone ticks”, which are actually 2 game ticks long.)
Note: It does not matter how long the array of repeaters is, you could have 500 and the last one would fail to turn off. This might have to do with updates, but when working with complicated or fast timing circuits, this bug is very annoying.
On the right setup, a 1 tick pulse is generated when you place a redstone torch on the redstone block. It should give a 1 tick pulse to the piston, then turn off for 1 tick, and then give another 1 tick pulse. Instead, it gives a single 3 tick pulse.
This is the most annoying of all when you have a large (downward) piston extender which can only be powered from one side, because you have to use redstone lines and to BUD a piston below another one, you have to send 2 pulses with 1 tick of delay inbetween.
Code analysis
Based on 1.11 decompiled using MCP 9.35 rc1
The reason why the last repeater or comparator stays powered seems to be that the methods net.minecraft.block.BlockRedstoneDiode.updateState(World, BlockPos, IBlockState) and net.minecraft.block.BlockRedstoneComparator.updateState(World, BlockPos, IBlockState) set a different priority for the update based on whether or not a repeater or comparator is after them.
—
Newer code analysis by @unknown foundin this comment.
Linked issues
is duplicated by 26
MC-51543
Repeater stuck "on"
Resolved
MC-69483
Serially connected repeaters fail when immediately adjacent
Resolved
MC-69648
Repeater Locking acts differently depending on whether it outputs to redstone dust vs. to another repeater
Resolved
MC-81002
Repeaters don't pulse when they normally should.
Resolved
MC-82092
multiple 1 tick redstone pulses down repeater track creates a single pulse or less pulses than expected
Resolved
MC-84014
Redstone Repeater Glitch
Resolved
MC-91614
Wrong work of repeaters
Resolved
MC-97220
Repeater Glitch
Resolved
MC-109836
fast-clock with 1 tick repeater-chain causes the last repeater to stay on
Resolved
MC-111756
Comparator Chains and 1 Tick Pulses
Resolved
MC-112124
Observers occasionally locks repeaters
Resolved
MC-112428
Signal gaps in redstone repeater chains are not preserved
Resolved
MC-114685
Redstone falling-edge signal not travelling through last repeater in a chain.
Resolved
MC-124031
Redstone repeater staying on.
Resolved
MC-129564
Comparator not transferring exact pulse from another comparator
Resolved
MC-135327
Redstone: 'Negative' pulse attenuation on repeaters
Resolved
MC-140784
2 Redstone Repeaters next to each other on delay 4 causes the receiving repeater to stay powered
Resolved
MC-153202
Repeaters stuck powered
Resolved
MC-174627
Last Repeater in chain stuck powered
Resolved
MC-200545
Redstone pulse sequnece changes on 2 repeaters
Resolved
MC-204737
Redstone repeaters in sequence do not repeat fast alternating signals correctly
Resolved
MC-204823
Repeaters "on" state last longer than the "off" state
Resolved
MC-207096
comparator doesn't work consistently.
Resolved
MC-207433
Comparator gets powered when it shouldn't, if it outputs into repeater
Resolved
MC-260634
1 rs tick repeater merging 1 rs tick pulses
Resolved
MC-279638
Comparator doesnt fire when it should fire
Resolved
relates to 1
Attachments
Comments 83
Just try out one of the setups 🙂
How very odd. Hit the button on Pulsetest 1, and each of the repeaters will go out for a moment, except for the last one. It doesn't matter how many repeaters there are, as long as there's more than one. The last one in the chain will stay solid.
However, if you put a redstone torch on top of the redstone block in Pulsetest 2, each of the repeaters will light up for a moment, including the final one in the chain.
left setup confirmed, right setup piston needs a redstone tick or 2 to extend, 50% confirmed 50% intended
Yeah this one got in the way of me too in the past. For reference here's Dico's video on it:
https://www.youtube.com/watch?v=aeroMoWIN34#t=159
I've made a video on it myself a while ago, basically saying the same but adding that adding wires to the same circuit will fix this behavior.
Steven Verberne, the repeater pointing into the piston is giving a 3 tick pulse, its not the piston staying extended, thats not a piston behavior. I have a lot of experience with pistons.
This shows how the same signal is processed differently because of the wire. The bottom signal is the correct one if the bug would not be present.
I beleive I've encountered a similar bug. this works perfectly fine in 1.7 but then in the snapshots... http://puu.sh/8CjWt.png
DicoTheRedstoner if you read my comment before that, you know I didn't know exactly what was wrong with it
but now that you said it, I noticed this as well
It doesn't seem to always do the same thing. Sometimes it doesn't deactivate the two last repeaters in the line of repeaters. In addition to that, it sometimes skips deactivating repeaters after the first in the line. This may be because I'm on my private server running 14w19a, but I can't be certain. I'm using the two torches monostable design in 2014-05-06_18.12.12.png
Still an issue for 14w28b.
I've made a short video demonstrating various combinations where one-tick pulses are problematic:
https://www.youtube.com/watch?v=Ubq6DLk0wsA
Still happening with 1.8 pre2
Still happening in 1.8-pre3. For another example of this behavior, see my (duplicate) bug report MC-69648
Still happening with 1.8 😞
Still happening in 1.8.1-pre3
Still happening in 1.8.1-pre4
Still not fixed in released 1.8.1
Affects 1.8.2-pre4. Possibly related to the fix of MC-14671.
Also affects arrays of comparators.
Still not fixed in 1.8.2-pre4. This has the same behaviour with 2 and 3-clocks with the last repeater in the chain set to 2 and 3 respectively.
If by 2-clocks and 3-clocks you mean clocks with 2 repeaters and clocks with 3 repeaters, that behavior makes total sense.
a clock made of a repeater on 2 and on 1 will after 1 or 2 pulses stop pulsing and stay locked in powered position, because the 2 tick repeater powers itself through the 1 tick repeater before it turns off itself. The same goes for the 3-clock with a 3 tick repeater.
No I am talking about powering the demo circuits shown above with a signal that is 2 or 3 pulses long and setting the last repeater in the chain to the respective setting.
Yeah, thats true. Thanks for adding that 🙂
Affects 15w45a.
Affects 15w46a.
Affects 15w47c.
Affects 15w49a.
Affects 15w50a.
Affects 15w51b.
Affects 16w02a.
Affects 16w03a.
Affects 16w04a.
Affects 16w05b.
Affects 16w06a.
Affects 16w07a.
Affects 16w07b.
Affects 1.9-pre1.
Affects 1.9-pre3.
Affects 1.9-pre4.
Confirmed for 1.9 (official release).
Affects 1.9.1-pre3.
Affects 1.9.2.
Big thanks to Fenhl for consistently testing this bug and updating the issue!
Affects 16w20a.
@@unknown: No big deal, it's literally just a single button press in my Creative world. The only reason I haven't been as consistent lately is that I switched to a new computer.
Was already marked as affected...
Confirmed for 16w33a.
May be related to MC-108066, in which repeaters lengthen one-tick pulses. For example, a repeater set to 2 ticks will turn a 1-tick pulse into a 2-tick pulse, and a repeater set to 4 ticks will turn a 1-tick pulse into a 4-tick pulse.
Affects 16w39c, but I'm unsure about 16w40a.
confirmed for 1.11-pre1
Still present in 1.11.2 for off pulses. Something's not right when some repeaters in a chain will let through the off pulse and others in the chain do not despite having the same delay setting.
Was already marked as affected...
Why did you change the title? I think "Arrays of repeaters" best describes the cases where this bug occurs. Repeaters separated by blocks or nothing at all, as long as no redstone is in between 2 repeaters this bug occurs. "some repeater setups" does not actually say anything about when this bug occurs.
So it also includes timed pulses (like MC-112124).
86 votes, 13 duplicates, 50 comments and almost three years after the original bug report and still no fix for this issue?
Guys, I know you have a lot to do but this issue affects a lot of people. Can we at least have some confirmation of whether there is any intention to fix this bug?
And in case anyone is actually reading this, the GIF attachments on this duplicate (https://bugs.mojang.com/browse/MC-114685) demonstrate the issue better than the still images on this one.
Attached gifs from MC-114685
There's a fairly comprehensive explanation of the issue here: https://www.reddit.com/r/redstone/comments/6orbz1/odd_quirk_bug_when_unpowering_a_line_of_powered/
Can confirm for 17w43a/b
Can confirm for 17w47b
Can confirm for 1.13-pre3
Can confirm for 1.13-pre5
Can confirm for 1.13-pre8
Can confirm for snapshot 18w30a
Can confirm for 19w03c
Can confirm for 19w13b
still in 1.14.4 Pre-Release 4
still in 1.14.4 Pre-Release 5
The solution to this problem is super simple and has been known for years now. Since then we have talked more technical and come up with an idea how a fix would affect as little other things as possible. Explaination in this comment. The following is that fix:
In the class called net.minecraft.world.level.block.DiodeBlock there is a function called boolean shouldPrioritize(BlockGetter, BlockPos, BlockState) where the issue originates from. In the last line there is an inequality which is incorrect. The last line frontState.get(FACING) != direction should be changed to frontState.get(FACING) != direction.getOpposite().
There is also a usecase where another alteration is needed. To fix this we have to also return true if the diode is of a different type.
Finally in this function we have to check the direction only for repeaters so it only applies to locking repeaters. The following is the code for that using close to official mappings (optimized for fewer calls to getOpposite()).
public boolean shouldPrioritize(BlockGetter blockGetter, BlockPos pos, BlockState state) {
Direction direction = state.get(FACING);
BlockState frontState = blockGetter.getBlockState(pos.offset(direction.getOpposite()));
if (!isDiode(frontState))
return false;
Block frontBlock = frontState.getBlock();
if (frontBlock != this)
return true;
return frontBlock == Blocks.REPEATER && frontState.get(FACING) != direction;
}
For the fix to not break other contraptions we found that it is also needed to change all 4 scheduled update priorities that are used in the DiodeBlock to be 1 higher. This would require to make a new Priority in the enum that is -4. For example -1 would become -2, -2 would become -3 and so on. I know that it is an enum now, but using integers is easier for explaining. Note that the values in the enum should still stay the same, only an introduction of -4 is needed!
Changing this fixes the mentioned bug and affects only the specific case where the chain bug is present. E.g. the repeater lock stable which is intended behavior relies on the correct priority to be set and remains functional from the abovementioned fix, etc.
I know the underlying code, but I don't see why a higher priority is needed. The fix would only change the priority of a repeater when it is facing into the main-input of another diode.
Could you explain why all of this is needed? I am sure it would help the developers as well to know what to be aware of.
Yes, I can explain.
The bug has been around for so long that the change has to be made in such a way that it doesn't break things that are not directly related to this bug. Therefore the priority relations between all these setups should remain the same. This is very important to ensure when fixing this. The main fix for this issue is actually the first three lines of my comment (after "The following is the fix"). As I mentioned the bug is super simple to fix, but that doesn't mean that it wouldn't affect other stuff to use the simple solution. To ensure that no other setups got affected we had to consider the following setups that people are using:
A chain of repeaters or comparators that are pulsing quickly. This is what we are trying to fix as mentioned by the code above doing so is rather simple.
A comparator facing into a repeater should pulse if powered by observer. This is widely used in the tech community in their treefarms and other contraptions. To fix this we do the check "if (frontBlock != this) return true;" to ensure that it stays the same as in the previous versions.
Make sure it is only applied to repeaters and not comparator, comparator. The original intentions for this method is to fix directionality issues when locking a repeater. Hence only check for repeaters when doing the last check for direction.
All af the scenarios are fixed by that code, however..! It's not enough to just theorise about it. We tested a setup and realized that when having 2 repeaters in a row and a similar setup of a comparator followed by a repeater it was inconsistent with previous versions. Namely the 2 repeaters had the exact same priority as the comparator and repeater setup. Previously the priority was higher for the repeaters. This is caused by the comparator priority now overlapping the repeater priority in that setup. To fix this the only way to keep everything in 1-3 working was to increase the priority of the repeater (since priorities are negative this would mean decrementing that value by 1), which can be done without harm since nothing uses the same priorities except for that 1 instance as mentioned before.
All of this was considered when making that comment and stating the fix for the bug. It is important that all of the above considerations are made since they should not be affected by the fix. Thanks for reading 🙂
Affects 1.16-rc1
Affects 1.16
Affects 1.16.1 and 20w27a
confirmed for 20w45a
I am baffled that this over 6-year-old bug, which has a solution in the comments by G4me4u posted almost a year ago, has still not been fixed. This has high priority too and hasn't even assigned to a Mojang employee.
This bug is 7th in the list of java bugs when searching for open+reopened issues that are unassigned and have important+very important priority levels. And only 4 of those bugs, 2nd through 5th on the list, are older than this bug.
Again, this bug has a detailed solution with an explanation the comments, that is almost a year old, by G4me4u, and still hasn't been fixed.
confirmed for the snapshot 20w49a
Still an issue in snapshot 20W51A
The reason we still can't use 1 tick signals reliably
I like G4me4u’s solution, but there are usages for the increased priority of a comparator facing into the side of another comparator too. For example it allows this circuit to have a reliable delay of 2 game ticks, no matter the orientation and redstone update order:
[media]Still an issue in snapshot 21w03a
Can confirm in 21w05b.
Still an issue in 1.17.1
That is a good point, Lukas Fink (this comment). I think the primary concern was that you can get something similar to the chain bug, if you have a comparator chain facing into a single comparator on subtract mode. If you have a quick off-pulse through that chain, you would end up with the chain bug at the last comparator:
[media]The concept of the solution to the chain bug is simple. The priority for any diode turning off must to be lower than or equal (meaning processed first) to the priority of any diode turning on in a chain. Thus, we had to change it to fix the abovementioned issue.
Affects 1.20.1.
I don't really get what you're trying to say