Quick pulses get lost in some repeater/comparator setups

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:

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

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

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