mojira.dev
MC-54711

Quick pulses get lost in some repeater/comparator setups

The Bug

When you send pulses into arrays of repeaters in quick succession, they will be lost.

How To Reproduce

  1. Build setup as seen on picture

    [media]
  2. 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

MC-51543 Repeater stuck "on" MC-69483 Serially connected repeaters fail when immediately adjacent MC-69648 Repeater Locking acts differently depending on whether it outputs to redstone dust vs. to another repeater MC-81002 Repeaters don't pulse when they normally should. MC-82092 multiple 1 tick redstone pulses down repeater track creates a single pulse or less pulses than expected MC-84014 Redstone Repeater Glitch MC-91614 Wrong work of repeaters MC-97220 Repeater Glitch MC-109836 fast-clock with 1 tick repeater-chain causes the last repeater to stay on MC-111756 Comparator Chains and 1 Tick Pulses MC-112124 Observers occasionally locks repeaters MC-112428 Signal gaps in redstone repeater chains are not preserved MC-114685 Redstone falling-edge signal not travelling through last repeater in a chain. MC-124031 Redstone repeater staying on. MC-129564 Comparator not transferring exact pulse from another comparator MC-135327 Redstone: 'Negative' pulse attenuation on repeaters MC-140784 2 Redstone Repeaters next to each other on delay 4 causes the receiving repeater to stay powered MC-153202 Repeaters stuck powered MC-174627 Last Repeater in chain stuck powered MC-200545 Redstone pulse sequnece changes on 2 repeaters MC-204737 Redstone repeaters in sequence do not repeat fast alternating signals correctly MC-204823 Repeaters "on" state last longer than the "off" state MC-207096 comparator doesn't work consistently. MC-207433 Comparator gets powered when it shouldn't, if it outputs into repeater MC-260634 1 rs tick repeater merging 1 rs tick pulses MC-279638 Comparator doesnt fire when it should fire

Attachments

Comments

user-f2760

I don't really get what you're trying to say

DicoTheRedstoner

Just try out one of the setups 🙂

Torabi

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.

user-f2760

left setup confirmed, right setup piston needs a redstone tick or 2 to extend, 50% confirmed 50% intended

CX gamer

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.

https://www.youtube.com/watch?v=wiQ7ii4hugo

DicoTheRedstoner

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.

CX gamer

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.

Nik

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

user-f2760

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

Wesley Baganz

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

DvdKhl

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

DvdKhl

Still happening with 1.8 pre2

Andrew Huff

Still happening in 1.8-pre3. For another example of this behavior, see my (duplicate) bug report MC-69648

DvdKhl

Still happening with 1.8 😞

DvdKhl

Still happening in 1.8.1-pre3

Mato Seb

Still happening in 1.8.1-pre4

Mato Seb

Still not fixed in released 1.8.1

Fenhl (Max Dominik Weber)

Affects 1.8.2-pre4. Possibly related to the fix of MC-14671.

Fenhl (Max Dominik Weber)

Also affects arrays of comparators.

Finn Wilke

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.

DicoTheRedstoner

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.

Finn Wilke

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.

DicoTheRedstoner

Yeah, thats true. Thanks for adding that 🙂

Fenhl (Max Dominik Weber)

Affects 15w45a.

Fenhl (Max Dominik Weber)

Affects 15w46a.

Fenhl (Max Dominik Weber)

Affects 15w47c.

Fenhl (Max Dominik Weber)

Affects 15w49a.

Fenhl (Max Dominik Weber)

Affects 15w50a.

Fenhl (Max Dominik Weber)

Affects 15w51b.

Fenhl (Max Dominik Weber)

Affects 16w02a.

Fenhl (Max Dominik Weber)

Affects 16w03a.

Fenhl (Max Dominik Weber)

Affects 16w04a.

Fenhl (Max Dominik Weber)

Affects 16w05b.

Fenhl (Max Dominik Weber)

Affects 16w06a.

Fenhl (Max Dominik Weber)

Affects 16w07a.

Fenhl (Max Dominik Weber)

Affects 16w07b.

Fenhl (Max Dominik Weber)

Affects 1.9-pre1.

Fenhl (Max Dominik Weber)

Affects 1.9-pre3.

Fenhl (Max Dominik Weber)

Affects 1.9-pre4.

PgSuper

Confirmed for 1.9 (official release).

Sess

Affects 1.9.1-pre3.

Fenhl (Max Dominik Weber)

Affects 1.9.2.

DicoTheRedstoner

Big thanks to Fenhl for consistently testing this bug and updating the issue!

Fenhl (Max Dominik Weber)

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.

user-f2760

Was already marked as affected...

EchoBlade

Confirmed for 16w33a.

EchoBlade

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.

HalfOfAKebab

Affects 16w39c, but I'm unsure about 16w40a.

Possseidon

confirmed for 1.11-pre1

bdm68

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.

user-f2760

Was already marked as affected...

DicoTheRedstoner

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.

user-f2760

So it also includes timed pulses (like MC-112124).

Jez

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.

marcono1234

Attached gifs from MC-114685

Karuna Boyum
NeunEinser

Can confirm for 17w43a/b

NeunEinser

Can confirm for 17w47b

NeunEinser

Can confirm for 1.13-pre3

Parity

Can confirm for 1.13-pre5

Parity

Can confirm for 1.13-pre8

Parity

Can confirm for snapshot 18w30a

Parity

Can confirm for 19w03c

Parity

Can confirm for 19w13b

Parity

still in 1.14.4 Pre-Release 4

Parity

still in 1.14.4 Pre-Release 5

G4me4u

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.

NeunEinser

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.

G4me4u

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 🙂

numeritos

Affects 1.16-rc1

numeritos

Affects 1.16

numeritos

Affects 1.16.1 and 20w27a

Giovanni Lanzarote

confirmed for 20w45a

Parity

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.

Giovanni Lanzarote

confirmed for the snapshot 20w49a

Giovanni Lanzarote

Still an issue in snapshot 20W51A

jxu

The reason we still can't use 1 tick signals reliably

Lukas Fink

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]
Giovanni Lanzarote

Still an issue in snapshot 21w03a

Avoma

Can confirm in 21w05b.

Giovanni Lanzarote

Still an issue in 1.17.1

G4me4u

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.

Brevort

Affects 1.20.1.

DicoTheRedstoner

(Unassigned)

Confirmed

Platform

Normal

Redstone

block-update, pulse, redstone, repeater

Minecraft 14w17a, Minecraft 14w18b, Minecraft 14w28b, Minecraft 1.8-pre2, Minecraft 1.8-pre3, ..., 1.19.3, 1.20.4, 24w05b, 24w33a, 25w03a

Retrieved