| Type: | Bug | ||
| Reporter: | Vincent Wiltschek | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 64 |
| Labels: | redstone | ||
| Attachments: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| CHK: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Confirmation Status: | Confirmed | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Category: |
Block states, Redstone
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Mojang Priority: | Normal | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Area: | Platform | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
When a piston receives a 0 tick redstone signal it pulses instead of staying in the current state. Before 1.3.1 pistons would turn into derp pistons but now they pulse which is equally annoying. It destroys piston based logic (most importantly instant logic). Update 1.5.1: Edit, 16-MAR-2016: It would be really nice if 0-tick/micro pulses (or as Dico has correctly said years ago, non-existing pulses in Minecraft terms) would finally be patched out of the game and if the game was able to handle actual simultaneity. So a proper/intelligent block update algorithm with a consistently synced quantized timeline instead of random Java hashsets and micro time-intervals, which would allow multiple blocks (that interact with eachother) to be updated all in the same gametick into their correct new stages (instead of purely successive block updates which leads to wrong/unintended behaviour). I suggest a server command / gamerule to switch between the current (unintended) behaviour and the fixed/intended behaviour so that contraptions of people using microticks can remain working. |
| Comments |
| Comment by [Mod] ampolive [ 04/Jul/21 ] |
|
Can confirm in 1.17.1 Release Candidate 1. |
| Comment by [Mod] ampolive [ 16/Jun/21 ] |
|
Can confirm in 1.17. |
| Comment by pulpetti [ 07/Aug/20 ] |
|
In 1.16.2 RC-1 |
| Comment by KingSheepMC [ 02/May/20 ] |
|
The 0 tick is a parity for java. It’s a weird mechanic that allows a block to be extended and not get pushed back. Who knows of Mojang will fix this in the future or bring this to bedrock. |
| Comment by Blobs2 [ 06/Nov/19 ] |
|
This should be fixed, for feature parity. Similarly, quasi-connectivity should be removed from Java or added to Bedrock. |
| Comment by Fabian Röling [ 24/Oct/19 ] |
|
Please move all off-topic discussion into other chats. If it's actually about bugs, you can for example go to reddit.com/r/mojira, if it's about building computers… I don't know, you'll find something. |
| Comment by DicoTheRedstoner [ 24/Oct/19 ] |
|
Vincent Wiltschek |
| Comment by Vincent Wiltschek [ 18/Oct/19 ] |
|
Read the last edit. It explains a way to replicate the bug without torches. Just instant NOT gates using pistons and repeaters. The problem ARE 0tick pulses off pulses. Would really like to see a working 6.7Hz CPU but I don't see how that is possible with 0tick pulses going off randomly everwhere. |
| Comment by RedCMD [ 17/Oct/19 ] |
|
All those pics show 0tick 0ff pulses And its possible to make 6.7Hz CPU's in minecraft |
| Comment by Hayden Wong [ 14/Jan/19 ] |
|
Confirmed for 1.13.2 and 19w02a. |
| Comment by Vincent Wiltschek [ 24/Jan/17 ] |
|
Did you read the last part of the description? |
| Comment by Myren Eario [ 10/Dec/16 ] |
|
"Is this still in Minecraft 1.11?" "Is this a problem?" |
| Comment by CDES5 (Inactive) [ 10/Dec/16 ] |
|
Is this still a problem in Minecraft 1.11? |
| Comment by null (Inactive) [ 22/Jun/16 ] |
|
Confirmed for 1.10.1. |
| Comment by Vincent Wiltschek [ 14/Jun/16 ] |
|
oops, sorry. |
| Comment by Kumasasa [ 14/Jun/16 ] |
|
@vin97: Please use the preview feature when editing something - you're flooding 20 people with every edit attempt. |
| Comment by Vincent Wiltschek [ 14/Jun/16 ] |
|
Also affects Minecraft Pocket/Win10 Edition v0.15.0 ( |
| Comment by null (Inactive) [ 08/Jun/16 ] |
|
Confirmed for 1.10. |
| Comment by null (Inactive) [ 07/Jun/16 ] |
|
Confirmed for 1.10-pre2. |
| Comment by null (Inactive) [ 03/Jun/16 ] |
|
Confirmed for 1.10-pre1. |
| Comment by Vincent Wiltschek [ 27/May/16 ] |
|
you could always add another server command lol but no, I agree with you, since these feedback loops can only be used for creating pulses (not logic or any function that could get destroyed), it would be better to let them pulse. |
| Comment by null (Inactive) [ 26/May/16 ] |
|
Confirmed for 16w21b. |
| Comment by null (Inactive) [ 25/May/16 ] |
|
Confirmed for 16w21a. |
| Comment by Myren Eario [ 20/May/16 ] |
|
Well, there´s nothing I can say against adding a gamerule. |
| Comment by Vincent Wiltschek [ 19/May/16 ] |
|
Yes, I am criticizing the random block updates and their consequences, which are 0-tick pulses because Minecaft does not update blocks in sync. To be clear, I am not talking about "making 0-tick pulses reliable/intuitive", so removing the direction/position dependencies and other inconsistencies. I AM talking about completely removing them from the game because a proper update algorithm does not require them... Now, I have to say that I didn't consider instant feedback loops like the ones you posted but realize that in these cases there simply is no logical behaviour because what is supposed to happen is impossible: Due to the instant properties of pistons, the redstone should be simultaneously on and off. Saying "the piston should pulse" is just as legit in this situation as saying "nothing should happen", as is saying "the piston should turn into a derp piston". I will add my suggestion of a server command to my original bug report, consequently the monostables you posted would not work with the "intended behaviour" option (no 0-tick pulses whatsoever), while everything remains as it is with the "unintended behaviour" option (this being the default setting). EDIT: How pistons behave when they are retracting is completely off-topic. We are basically discussing whether or not pistons (or other mechanisms) should start retracting (in these 'special' cases) in the first place. |
| Comment by null (Inactive) [ 18/May/16 ] |
|
Confirmed for 16w20a. |
| Comment by Myren Eario [ 18/May/16 ] |
|
So you don´t want to "patch all 0 tick pulses", but you just want to make the update order more simple, logical, intuitive and remove all hashsets and location dependencies. This is something I completely fully support. But the stuff you´ve written in the bug report is about the "existence of 0 tick pulses in general", and I can´t consider that to be a bug. You can simplify update order and make 0 tick pulses more intuitive, and I support that, but you can´t remove the update order and all 0 tick pulses. So I won´t support "patching 0 tick pulses out of the game". |
| Comment by Vincent Wiltschek [ 18/May/16 ] |
|
"Fixing" 0 tick pulses (meaning removing them where possible) is not illogical, it simply requires an actual algorithm to decide the block update order instead of just relying on random java hashsets! Good example, Myren. The problem with the circuit you posted is not pistons reacting to 0-tick pulses but the fact that you built an instant/infinite feedback loop (basically the grandfather paradox). In every other case (where the order of events can be logically/causally assigned) 0-tick pulses can be removed. The piston flip flops you are talking about, Dico, do not require 0-tick pulses. They work the same way with 1 (redstone) tick pulses. And hopefully for the last time, I suggest a command that lets you decide what type of behaviour you want so that all of your circuits can remain working. |
| Comment by DicoTheRedstoner [ 18/May/16 ] |
|
Nothing I can squeeze between that. I never thought Mojang would be able to fix 0 tick pulses in the first place, and this ^ just proves that. I don't think there's any logical response for the right piston other than to 0-tick. |
| Comment by Myren Eario [ 18/May/16 ] |
|
Just out of curiosity I would like to know how you would imagine the game works without 0 tick pulses. Basically I´m asking: What is the intended behavior? |
| Comment by null (Inactive) [ 11/May/16 ] |
|
Confirmed for 1.9.4. |
| Comment by Vincent Wiltschek [ 07/May/16 ] |
|
Well, we were actually talking about the same repeater designs and I really don't see where they rely on microticks (time intervals below 0.05s). They DO completely destroy basic logic because when a piston stops receiving power and starts receiving power from a different powersource in the same gametick, it pulses. "As I also mentioned, it is very possible to make instant logic work right now." "You have to synchronize the incoming signals to solve that" "Apply logical thinking instead of requesting a change that makes it easier." "Mojang made pistons work this way, they weren't designed to do the things they do entirely, indeed, but right now, as with diagonal powering it is too late to revert this change IMO." "That's not a nice trade-off." |
| Comment by DicoTheRedstoner [ 07/May/16 ] |
|
Firstly, microtick based repeaters are absolutely not more complex or more unreliable. I have never ever seen microticks work differently on one moment than another. This is the design I'm talking about here: http://minecraft.gamepedia.com/Transmission_circuit#Instant_repeater And they do not "completely destroy" basic logic AT. ALL. This only applies when you try to work with instant logic already, at which point you are already working with microtick intervals. So your point here makes no sense. Besides, micro ticks are a valuable aspect of the game right now, as I said they allow for really cool things, that most survival users are much more likely to ever integrate than a CPU. Mojang made pistons work this way, they weren't designed to do the things they do entirely, indeed, but right now, as with diagonal powering it is too late to revert this change IMO. As I also mentioned, it is very possible to make instant logic work right now. You can use microticks as well as not use them, and there is a problem with microticks messing up components, but that this is happening makes total sense: you have to synchronize the incoming signals to solve that (if you're dealing with the problem). Apply logical thinking instead of requesting a change that makes it easier. My last point: Why should we remove an awesome aspect of the game for the bigger player base (timing-centered redstoners) to make some other thing with logic-centered redstone easier? That's not a nice trade-off. |
| Comment by Vincent Wiltschek [ 07/May/16 ] |
|
0-tick pulses are not what makes instant logic possible. It purely has to do with the moved block instantly becoming transparent (which is completely intended behaviour). I understand that there are a lot of applications for 0-tick pulses but unlike quasi connectivity (or other "accepted bugs") they completely destroys basic logic (in other applications). Minecraft time is designed to be quantized and the smallest interval is supposed to be 0.05s. ...My suggestion would be a gamerule that can turn micropulses on or off so that everybody is happy. |
| Comment by DicoTheRedstoner [ 06/May/16 ] |
|
– If you're not interested in a lot of technicalities, skip the first paragraph – Although I understand that you consider this a bug, I find it very intriguing how pistons interact with eachother in the current state of the game, and would very much hate to see their behaviour changed in any way. As far as my understanding of the game goes, pistons schedule block updates to their surroundings a bit later than other redstone components (such that all redstone-updates occur before block-updates from pistons). I am not a code freak but I'm pretty sure the piston will retract if it was unpowered and all redstone-updates have occurred, after which block-updates still have to get started. If you didn't understand any of that, the basic principle is that piston updates are slower and allow for other ways of creating instant logic, such as extremely simple t-flip-flops or instant repeaters, all of which can be found on youtube. Other examples include some doors that open 4x faster than would be possible otherwise, and the mechanic actually continues to make total sense, as if you can count the updates as if they were ticks (I like to call them microticks but this indication is not correct). There are currently quite a few 3x3's, a few 4x4's and some 5x5's that work with this mechanic. An example is this historical video that most certainly got other players to fiddle around with it: https://www.youtube.com/watch?v=xFTna4l2gpM&t=1m28s . So I hope you can consider my point and tell me why you would want this bug fixed. For instant logic you say? Well, I know what you're talking about, but I suggest you consider the other options it provides to make instant logic possible. If these mechanics are in your way in any other means, I can't think of anything right now, so I'd love to hear. Thanks for reading and my apologies for the long comment. EDIT: It appears there are multiple applications/versions of this bug in this thread. I am ONLY talking about current piston behaviours, and no single other devices. That is, the instant NOT-gate example provided in the edit of the description. |
| Comment by null (Inactive) [ 06/May/16 ] |
|
Confirmed for 1.9.3-pre3. |
| Comment by James (inactive) [ 15/Mar/16 ] |
|
Confirmed for 1.9.1-pre3. |
| Comment by James (inactive) [ 13/Jan/16 ] |
|
Confirmed for 16w02a. Happens with a door. |
| Comment by kbk [ 11/Jan/16 ] |
|
Ah, response, yes.. Well, Jim, your setup is doing what it is supposed to do when a door is used instead of a piston. I mean, the door actually performs a noisy twitch in same setup. So, I guess this bug is still there. |
| Comment by James (inactive) [ 20/Dec/15 ] |
|
Cannot confirm for 15w51b. Is it fixed, or am I using a bad setup? https://youtu.be/3DiUGuDSTkI |
| Comment by DicoTheRedstoner [ 23/Nov/15 ] |
|
Before you take too many conclusions, try to power the input block with a repeater. You're bound to get different results actually, because of SYNCED / UNSYNCED behaviour as explained in this video: https://www.youtube.com/watch?v=UtSP6VAcITU At the moment I'm unable to test for you, sorry :/ |
| Comment by Swekob [ 22/Nov/15 ] |
|
Affects 15w47c & 1.8.8 |
| Comment by Galaxy_2Alex [ 25/Oct/14 ] |
|
Reopened, thanks. |
| Comment by kbk [ 25/Oct/14 ] |
|
Yes it is. Dispensers dispense, droppers drop, other devices commit visual/audial actions. |
| Comment by Galaxy_2Alex [ 25/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 kbk [ 13/Aug/14 ] |
|
14w33a - still... uh-oh, probably deserves to be taken care of, probably... |
| Comment by kbk [ 07/Jul/14 ] |
|
Kinda still not completely fixed as of 14w27b. Don't know if really deserves fixing though. |
| Comment by Tails [ 06/Mar/13 ] |
|
Jonathan is right, |
| Comment by Steve Blanding [ 06/Mar/13 ] |
|
@Jonathan Haas: No. I am not. That bug is about powered dispensers/droppers responding to block updates. This bug is about powered items responding to redstone updates. There is a subtle but important difference. The device I linked above was broken by Edit: OK. So I thought you were referring to yet ANOTHER bug. The one about powered dispensers responding to block updates. Now that I actually bothered to READ the bug you linked, turns out I was wrong. You were right. hangs head in shame |
| Comment by Jonathan Haas [ 06/Mar/13 ] |
|
Steve, you are complaining about |
| Comment by Tails [ 06/Mar/13 ] |
|
They sure do. Just build the setup I provided in the screenshot, but put a Dispenser/Dropper instead of the piston. |
| Comment by Steve Blanding [ 06/Mar/13 ] |
|
@Tails: not any other; powered dispensers and droppers no longer react |
| Comment by Tails [ 06/Mar/13 ] |
|
Indeed piston is fixed, but any other mechanism still reacts. |
| Comment by Steve Blanding [ 06/Mar/13 ] |
|
@kbk: I'm glad that they still at least react to a 1 tick clock but the fact is that this still breaks a lot of stuff for very little gain. Of all of the things that this breaks, this one saddens me the most: http://youtu.be/XNaYFhl9Pqc I will find a work-around, of course, but there is no chance of it ever being this compact or this simple. |
| Comment by kbk [ 06/Mar/13 ] |
|
@hfog Nevertheless, these devices still fire properly off 1-tick clocks and I feel like |
| Comment by Steve Blanding [ 06/Mar/13 ] |
|
"Fixing" this behavior for droppers and dispensers was a big mistake, IMHO. A lot of very useful and compact designs are now broken as a result of this "fix". Rapid fire dispensers are now impossible. Dropper towers (for moving items vertically) now require significantly more complicated redstone and operate significantly slower. I am going to have to rebuild a significant amount of things in my world as a result of this change. Does "fixing" this behavior actually help anyone in any significant way? This was a fix that yields no real benefit and causes a significant amount of disruption. Please reconsider this one. |
| Comment by kbk [ 06/Mar/13 ] |
|
Doors, trapdoors, fence gates and note blocks still emit their respective sounds in 13w10b. |
| Comment by mike [ 02/Mar/13 ] |
|
They fixed it. |
| Comment by Steve Blanding [ 01/Mar/13 ] |
|
Yes. Please DO NOT FIX THIS for droppers or dispensers. That behavior is vital to a number of important contraptions. |
| Comment by kbk [ 01/Mar/13 ] |
|
While fixed for piston in 13w09c, this has not been fixed for doors, fence gates and noteblocks (those devices emit sounds), droppers and dispensers (those get triggered, but IMO the community probably won't be happy about these two getting fixed). Also checked that this setup doesn't work for hoppers, dunno if were affected. |
| Comment by Vincent Wiltschek [ 01/Mar/13 ] |
|
Awesome, so it will just be a texture bug? |
| Comment by [Mojang] Jeb (Jens Bergensten) [ 01/Mar/13 ] |
|
Fixed, but client-side the piston will flicker into its closed state for an instant. I don't think I can avoid this. It's more noticeable when you have lag, but at least the piston itself doesn't move (no sound effect either). |
| Comment by kbk [ 01/Mar/13 ] |
|
Affects 13w09b. |
| Comment by Tails [ 28/Jan/13 ] |
|
Confirmed and applies to all powered mechanisms, attached screenshot for reference: flipping the lever up results in the piston "reacting", while flipping the lever down nothing happens. |
| Comment by Vincent Wiltschek [ 26/Jan/13 ] |
|
Yes, I know it's a special case of the old update bug. But since they are currently fixing these bugs (especially those related to pistons) I wanted to make sure that they know about this one. |
| Comment by Henrik Lindström [ 25/Jan/13 ] |
|
Hi dico Very annoying though as it breaks alot of instant piston logic |
| Comment by DicoTheRedstoner [ 25/Jan/13 ] |
|
I've also seen this before, try to put the piston on a different location, its the order minecraft updates. |