[MC-2340] Redstone torches schedule updates when they should not, causing unreliable timings. Created: 05/Nov/12  Updated: 30/Jun/18  Resolved: 12/Dec/17

Status: Resolved
Project: Minecraft: Java Edition
Component/s: None
Affects Version/s: Minecraft 1.4.2, Minecraft 1.4.3, Minecraft 1.4.7, Snapshot 13w01b, Snapshot 13w02b, Snapshot 13w03a, Snapshot 13w04a, Snapshot 13w05a, Snapshot 13w06a, Snapshot 13w07a, Snapshot 13w10b, Minecraft 1.5, Minecraft 1.6.4, Minecraft 13w38c, Minecraft 1.7.4, Minecraft 14w03b, Minecraft 14w08a, Minecraft 1.10.2, Minecraft 16w43a, Minecraft 1.11 Pre-Release 1, Minecraft 1.11, Minecraft 16w50a, Minecraft 1.11.1, Minecraft 1.11.2, Minecraft 17w06a, Minecraft 17w13b, Minecraft 17w15a, Minecraft 17w16b, Minecraft 17w17b, Minecraft 17w18b, Minecraft 1.12 Pre-Release 2, Minecraft 1.12.1, Minecraft 1.12.2, Minecraft 17w43a, Minecraft 17w43b, Minecraft 17w50a
Fix Version/s: Snapshot 13w05b, Minecraft 18w01a

Type: Bug
Reporter: Henrik Lindström Assignee: [Mojang] Grum (Erik Broes)
Resolution: Fixed Votes: 138
Labels: redstone, redstone-timing, redstone_torch
Environment:

Windows 7


Attachments: PNG File 2013-01-07_15.12.45.png     PNG File 2013-03-07_18.42.34.png     PNG File 2013-03-07_18.49.49.png     PNG File 2016-12-25_19.42.44.png     PNG File inverted.png     PNG File old-fixed.png     PNG File redstone-1.png     PNG File redstone-2.png     PNG File torch-repeater.png     PNG File torches-0.png     PNG File torches-1.png     PNG File torches-2.png     PNG File torches-3.png    
Issue Links:
Duplicate
is duplicated by MC-8934 Redstonetorch does not activate when ... Resolved
is duplicated by MC-9246 Direction dependent redstone torch ti... Resolved
is duplicated by MC-9854 Comparator behavior buggy with 1 tick... Resolved
is duplicated by MC-9882 Redstone Torch sometimes doesn't reac... Resolved
is duplicated by MC-9936 Redstonetorches still unreliable in c... Resolved
is duplicated by MC-10020 Redstone powering torches on the same... Resolved
is duplicated by MC-29370 Comperators, and one tick signals Resolved
is duplicated by MC-32296 Redstone timing issues Resolved
is duplicated by MC-40366 Very simple contraption using redston... Resolved
is duplicated by MC-79057 Redstone torch behaving weirdly Resolved
is duplicated by MC-91615 Must terrible bug: One torch is block... Resolved
is duplicated by MC-99734 Redstone repeaters and torches pulses Resolved
is duplicated by MC-114199 A 2 tick pulse sent to a redstone tor... Resolved
is duplicated by MC-124788 Inconsistent Redstone Behaviour with ... Resolved
is duplicated by MC-132430 Torch making pulse shorter without in... Resolved
is duplicated by MC-2202 Inconsistent pulse length/delay with ... Resolved
is duplicated by MC-2341 Redstone torches behave unpredictably Resolved
Relates
relates to MC-109574 Redstone torches can't get unlit by o... Resolved
relates to MC-6047 Comparator strings fail to transmit 1... Resolved
relates to MC-109737 Some redstone components can't receiv... Resolved
CHK:
Confirmation Status: Confirmed

 Description   

When you (un)power a torch with a 2-tick pulse (here and from now on I mean redstone ticks), it turns off/on for 2 ticks as expected.
But if in the same tick you update the torch and then (un)power it, it produces only a 1-tick pulse (so they won't unpower 2-tick repeaters or (un)power other redstone torches).

This can be reproduced in multiple ways (all pistons in the screenshots are sticky):

  1. Updating with other torches (see torches-#.png: only 1 repeater will be unpowered)
  2. Updating with redstone (see redstone-#.png and old-fixed.png: repeater/torch to the right won't unpower)
  3. Updating with a repeater (see torch-repeater.png: repeater to the right won't unpower)
  • All setups (beside old-fixed.png) show the issue with powering the torch; for unpowering you can just invert the input signal and use torches to see the bug (see inverted.png)


 Comments   
Comment by Timothy Miller [ 04/Jan/18 ]

Looks like this is fixed in the lastest 18w1 snapshot, thanks to Gnembon and Grum!

Comment by [Mojang] Grum (Erik Broes) [ 12/Dec/17 ]

And once more.

Comment by [Mod] NeunEinser [ 26/Oct/17 ]

Can confirm for 17w43a/b

Comment by Joram Brenz [ 07/Sep/17 ]

I got a bit confused that MC-32296 got marked as a duplicate of this one.
After reading the comments I understood, that they are just different manifestations of the same issue.
Still I would like to suggest changing the description of this issue to contain a short notice about 1-tick unpowering of repeaters being affected too.

Comment by Meri Diana [ 17/May/17 ]

DjSapsan Bugposts must not be ( ab ) used for discussion, but I can tell you really care for Redstone in Minecraft, so I hope the moderators won't scold me too much for replying to you It may also clear similar concerns/worries or anger reasons for whoever may run into this bugpost in the future.

If you follow Panda's channel you hopefully also saw this video here: https://www.youtube.com/watch?v=NnkSSs-I8XM where he explained why it is not so easy to implement a change (if not, watch the video, listen closely).

"It's impossible to fix old problems without also breaking some old behaviour."

For such substantial changes, Mojang needs to overhaul the complete Redstone system, not only a single part.
This would be better to be done in a gigantic future overhaul which might break many, if not most, contraptions, but that's better than having "bit by bit" changes, so the tech community wouldn't have to adapt with every new MC version that comes out and gets upset even more (which we could see happening during the 1.11 snapshots with several changes to Redstone components, as sadly many people treat snapshot versions like release versions, but with the latter the reactions would probably be even worse).

I like to compare it with the Minecraft boats: They never really fixed boats, they implemented new ones.

Let me just assure you that the Java-Devs are not ignoring this problem, you don't know what some of them are working on behind the scenes, unbeknownst to the public, so please don't make such assumptions without knowing it with a 100% certainty from the Java-Devs themselves

It might take a while until we might see a future totally new Redstone system with less lag and more logic, and maybe also new components even, but, given the current state of the code, plus other implementations that have to be done beforehand (e.g. also such a seemingly unrelated thing like "unlimited" block IDs), this is not an easy task.

From the current path Minecraft seems to go generally, I'm just relieved the Java-version seems to still render enough money to be supported and updated at all by Mojang, which they are (technically) not obliged to, and that they didn't change the Redstone system completely to be like the PE/WIN10-version, although Mojang always said they want feature parity.. but we still got e.g. Quasi-Connectivity in Java-MC which does not (and surely never will, as it's considered a bug) exist in PE-/WIN10-MC, but which maybe might not be in Java-MC anymore, once the Redstone system would be completely overhauled.

A loss of QC might make the majority of Java-Redstone community go "berserk", unless Mojang would introduce new shiny elements in the future Redstone system, so the Java-Redstone community could live with that possible loss of QC at that time, and that means they need a bigger amount of time to create a "perfect" overhauled, improved Redstone system that also somewhat got feature parity to other Minecraft platforms, if that's what they're going to do with Java-MC.

We'll see, I'm curious about it myself!
I can only ask you to be patient and hope for the best

Comment by Dj [ 17/May/17 ]

I apologize, that in such a strange way I try to pay attention to one thing, but otherwise it is impossible. The problem is that there is a terrible bug that is not fixed from the very first versions of the game. This bug destroys ALL the power of the redstone. Because of the bug, it is impossible to create sophisticated high-tech devices. Partly a bug is described in this thread. More here - https://bugs.mojang.com/browse/MC-91615, https://bugs.mojang.com/browse/MC-91616, https://bugs.mojang.com/browse/MC-91614 , Full here - https://bugs.mojang.com/browse/MC-90955.
Developers, unclear why, ignoring one of the most SERIOUS BUG in the history of the game. Bug is not new, and not rare. All the redstoners suffered because of him.
I very much ask, if there is such an opportunity, pay attention of the developers to the problem. It is necessary to fix! One option - screw the mod into the game: https://www.youtube.com/watch?v=NEMARMNvDsw&ab_channel=Panda4994

Comment by Alexander H [ 25/Dec/16 ]

(Added a screen shot.) This is 1.11.2 and the torches dont unpower in the same tick even tho they should.

Comment by Sokaren [ 24/May/16 ]

It looks like it works fine in 16w20a

Comment by user-f2760 (Inactive) [ 17/Mar/16 ]

No response for a number of months.

Comment by Kumasasa [ 06/Dec/15 ]

Is this still an issue in the current Minecraft Snapshot 15w49b or later? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.

Comment by Caty Lawren [ 09/Jan/15 ]

The 'comparator bug' from one of the duplicates is actually not a bug. The redstone directly at the output and the redstone next to that one always stay on, as the comparator is in 'subtractive mode' and is subtracting it's output from it's primary input. Because the output is diminished by the distance at which it reaches the secondary input, it subtracts two less than the primary input from the primary input, leaving a value of two. That value diminishes to zero from the distance to the secondary input, which is subtracted from the value at the primary input, making the output equal to the primary input, which was the starting state. This cycle then repeats until it is interrupted.

Comment by Galaxy_2Alex [ 24/Oct/14 ]

Reopened, thanks.
Going to keep it to this one, they are going to do things with Redstone in the next update (1.9) anyway.

Comment by DvdKhl [ 24/Oct/14 ]

Not sure if I can speak for the reporter. But my bug report which was merged into this one still has issues ( MC-32296 ).
All videos except the third (which seems fixed) still behave in the same (buggy) way.

The first and last video is probably the same issues as: MC-54711

Comment by Galaxy_2Alex [ 24/Oct/14 ]

Is this still a concern in the current Minecraft version 1.8.1 Prerelease 3 / Launcher version 1.5.3 or later? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.

Comment by Henrik Lindström [ 18/Jan/14 ]

Well, just edited my whole last comment.. xD
They are both from the same issue as i wrote now that i thought about it so staying merged is probably a good idea. I just have to update the main post...

Comment by DvdKhl [ 18/Jan/14 ]

I did create a ticket which describe these problems ( https://mojang.atlassian.net/browse/MC-32296 ) but it got marked as duplicate and merged into this one.
So I basically share your opinion that this is a separate issue, but I don't want to annoy the mods creating yet another ticket for it.
It would be nice if a mod could clarify if this should stay merged as one ticket or if my reported issues warrant another ticket.

Comment by Henrik Lindström [ 18/Jan/14 ]

I added the new versions.

Explanation to the leftover of this bug:
Also.. i completely edited this comment because i just thought about it, and the repeater bugs are caused by the same problem that causes torches to act weird. the only difference is that with torches it's about them checking if they shoyuld schedule an update for themselves and with repeaters it's about them checking if they are powered or not.

The actual problem in both cases is how the game updates things one at a time in some order.
This causes these weird behaviours.

Examples:
Bug with a torch(One RedStoneTick at a time):

RSTick 0: The torch's input changes causing it to schedule an update.
RSTick 1: In the same tick but before the scheduled update arrives we update the torch causing it to schedule another update. Then it gets updated from the last tick's schedule and changes state.
RSTick 2: The torch's input changes again(scheduling another update). The scheduled update from last tick arrives and the torch changes state.
RSTick 3: The scheduled update the torch is supposed to change state too arrives but the torch is already in the correct state so nothing happens.

This is what happens in the torch monostable picture.

Bug with a repeater:

The fact that repeater's input need to be off for 1 RSTick before it changes state causes problems here.

Shortly, the repeater's input turns off, one RSTick later IF the input is powered tick AND is updated before the repeater, the repeater will never turn off because it made the "1 RSTick off" check just after the input had already turned on again.

Sorry if i suck at explaining..

But the problem lies in that even though two things happen in the same tick, one of them will still happen before the other.

This is just how redstone stuff works so i wouldn't expect this to ever be fixed as that would probably require a big rewrite of the whole redstone code. (As far as i can tell).

Anyway, i feel pretty sure that this is the cause for both bugs though i could be wrong.
I might update the whole post to explain this so it would include your repeater bugs aswell..

But not feeling like it right now

Comment by DvdKhl [ 17/Jan/14 ]

Henrik Lindström: Could you add 1.7.4 and 14w03b for the affected versions?
Not sure if your reported issue is still present, but the issues pointed out in my videos are still there.

Comment by DvdKhl [ 22/Sep/13 ]

Well my issue report was marked as duplicate of this one.
So going by this, it looks like repeaters are affected by this bug mentioned here too.

Comment by Henrik Lindström [ 22/Sep/13 ]

Only the second video actually contains this bug. Repeater problems are because of something else.
And i quickly updated the post

Comment by DvdKhl [ 22/Sep/13 ]

Since this is still the ticket to go to for one tick issues here some videos which show the "one tick physics" issues present in redstone logic:
http://www.youtube.com/watch?v=JNTTuGOqJkg
http://www.youtube.com/watch?v=Z0OsUjZXQVs
http://www.youtube.com/watch?v=CgPIavyc4ig
http://www.youtube.com/watch?v=Ac_IujHfXpw

Comment by Daniel Whitney [ 26/Apr/13 ]

I'm having trouble getting torches to respond to one-tick pulse.

Comment by Kwin van der Veen [ 09/Mar/13 ]

I was doing some tests with 1 tick pulses. And it seems that 1 tick pulses which do trigger comparators, will keep being able to trigger them if this signal is extended by comparators. However once you extend this pulse once by a repeater it won't trigger comparators again. These 1 tick pulses also trigger torches, however 1 tick pulses from torched do not always trigger comparators.

Comment by DvdKhl [ 08/Mar/13 ]

May be related:
Place two two repeaters next to each other (facing in opposite directions) each having a one tick delay.
Connect the repeaters. Creating a clock which produces a 1010101... tick pattern.
If you now attach a "line" of repeaters to it, instead of seeing the 10101... pattern you get 111011101110...
This breaks all my contraptions :/

Comment by Manuel [ 07/Mar/13 ]

the torch looking west is still on, while the others are already off

Comment by Manuel [ 07/Mar/13 ]

the redstone torch part is still not fixed in 1.5 (thats the test setup from MC-9246)

Comment by Henrik Lindström [ 26/Feb/13 ]

Seems like the comparator part of this issue is fixed again in Snapshot 13w09a
Edit:
It still exists in a few cases.. Il update the post when i have time..

Comment by Henrik Lindström [ 07/Feb/13 ]

Redownloaded it, bug is still there.

Comment by Tails [ 07/Feb/13 ]

Please redownload the Snapshot and try again.

Comment by Tails [ 07/Feb/13 ]

Reopened.

Comment by Henrik Lindström [ 07/Feb/13 ]

This bug is back in snapshot 13w06a. Can a mod or someone reopen maybe?

Comment by Henrik Lindström [ 04/Jan/13 ]

Well that doesn't have with this glitch to do.
It's still not completely fixed in the 1.5 snapshot, if you have two output torches one of them will give a 1 tick pulse, the other a 2 tick one.
Updated the description

Comment by B R [ 04/Jan/13 ]

The first 1.5 snapshot seems to have slightly affected this behavior, but still not fixed it. Torches still don't respond to short pulses in an expected way.

Comment by Francis Wharf [ 05/Nov/12 ]

A annoying, and reproducable issue, luckily, couple lines of code, and It's le fix!

Generated at Sun Jan 12 11:57:32 UTC 2025 using Jira 9.12.2#9120002-sha1:301bf498dd45d800842af0b84230f1bb58606c13.