[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: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 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. This can be reproduced in multiple ways (all pistons in the screenshots are sticky):
|
| 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 |
| 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 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. 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! |
| 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. |
| 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. |
| 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 ( 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 |
| 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. |
| Comment by Henrik Lindström [ 18/Jan/14 ] |
|
I added the new versions. Explanation to the leftover of this bug: The actual problem in both cases is how the game updates things one at a time in some order. Examples: RSTick 0: The torch's input changes causing it to schedule an update. 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. 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? |
| Comment by DvdKhl [ 22/Sep/13 ] |
|
Well my issue report was marked as duplicate of this one. |
| Comment by Henrik Lindström [ 22/Sep/13 ] |
|
Only the second video actually contains this bug. Repeater problems are because of something else. |
| 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: |
| 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: |
| 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 |
| Comment by Henrik Lindström [ 26/Feb/13 ] |
|
Seems like the comparator part of this issue is fixed again in Snapshot 13w09a |
| 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. |
| 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! |