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):
Updating with other torches (see
torches-#.png: only 1 repeater will be unpowered)Updating with redstone (see
redstone-#.pngandold-fixed.png: repeater/torch to the right won't unpower)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 (seeinverted.png)
Linked issues
is duplicated by 17
MC-2202
Inconsistent pulse length/delay with torch and repeater combination
Resolved
MC-2341
Redstone torches behave unpredictably
Resolved
MC-8934
Redstonetorch does not activate when given a 2 tick pulse
Resolved
MC-9246
Direction dependent redstone torch timing
Resolved
MC-9854
Comparator behavior buggy with 1 tick pulses
Resolved
MC-9882
Redstone Torch sometimes doesn't react at 1 tick pulse
Resolved
MC-9936
Redstonetorches still unreliable in certain directions
Resolved
MC-10020
Redstone powering torches on the same block at different times.
Resolved
MC-29370
Comperators, and one tick signals
Resolved
MC-32296
Redstone timing issues
Resolved
MC-40366
Very simple contraption using redstone torch is inconsistent
Resolved
MC-79057
Redstone torch behaving weirdly
Resolved
MC-91615
Must terrible bug: One torch is blocking other WITHOUT physical contact
Resolved
MC-99734
Redstone repeaters and torches pulses
Resolved
MC-114199
A 2 tick pulse sent to a redstone torch sometimes results in the torch turning off for only 1 tick
Resolved
MC-124788
Inconsistent Redstone Behaviour with Short Pulse
Resolved
MC-132430
Torch making pulse shorter without interact!
Resolved
relates to 3
Attachments
Comments 34
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.
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 🙂
This bug is back in snapshot 13w06a. Can a mod or someone reopen maybe?
Reopened.
Please redownload the Snapshot and try again.
Redownloaded it, bug is still there.
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..
the redstone torch part is still not fixed in 1.5 (thats the test setup from MC-9246)
the torch looking west is still on, while the others are already off
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 :/
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.
I'm having trouble getting torches to respond to one-tick pulse.
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
Only the second video actually contains this bug. Repeater problems are because of something else.
And i quickly updated the post 🙂
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.
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.
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 😛
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.
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...
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.
Reopened, thanks.
Going to keep it to this one, they are going to do things with Redstone in the next update (1.9) anyway.
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.
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.
No response for a number of months.
It looks like it works fine in 16w20a
(Added a screen shot.) This is 1.11.2 and the torches dont unpower in the same tick even tho they should.
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
@unknown 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 😉
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.
Can confirm for 17w43a/b
And once more.
Looks like this is fixed in the lastest 18w1 snapshot, thanks to Gnembon and Grum!
Erik Broes
A annoying, and reproducable issue, luckily, couple lines of code, and It's le fix!