Powered mechanisms react when receiving a 0 tick redstone signal (existence of micro-pulses in general / inconsistent block update 'algorithm')

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).

Awesome, so it will just be a texture bug?

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.

Yes. Please DO NOT FIX THIS for droppers or dispensers. That behavior is vital to a number of important contraptions.

They fixed it.

Doors, trapdoors, fence gates and note blocks still emit their respective sounds in 13w10b.

"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.

@hfog
As for the setup I use, dispensers and droppers still react to 0-tick on low edge (when switch is pulled off) as they did snapshots ago. So it seems like the recent dispenser mechanic change had really nothing to do with this particular bug.

Nevertheless, these devices still fire properly off 1-tick clocks and I feel like 640 KB of RAM is enough 1-tick is still pretty rapid for a dispenser.

@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.

Indeed piston is fixed, but any other mechanism still reacts.

@Tails: not any other; powered dispensers and droppers no longer react 😞

They sure do. Just build the setup I provided in the screenshot, but put a Dispenser/Dropper instead of the piston.

Steve, you are complaining about MC-846, not this bug.

@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 MC-846 and would have been fixed with MC-846's fix if this bug had not also been fixed for dispensers.

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

Jonathan is right, MC-846 caused the Dispenser to fire rapidly when near a clock.

Kinda still not completely fixed as of 14w27b. Don't know if really deserves fixing though.

14w33a - still... uh-oh, probably deserves to be taken care of, probably...

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.

Yes it is. Dispensers dispense, droppers drop, other devices commit visual/audial actions.

Reopened, thanks.

Affects 15w47c & 1.8.8

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 :/

Cannot confirm for 15w51b. Is it fixed, or am I using a bad setup? https://youtu.be/3DiUGuDSTkI

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.

Confirmed for 16w02a. Happens with a door.

Confirmed for 1.9.1-pre3.

Confirmed for 1.9.3-pre3.

– 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.

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 know that there are some other instant repeater designs out there that somehow use microticks but they are unnecessarily complex and obviously even more unreliable.

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.
Therefore, Minecraft should also be able to handle simultaneity, it cannot do that at the moment.
If you want to actively bypass these design principles and you need micro-intervals to get something to work, it should not make other ("legit") contraptions impossible/unreliable, especially when these contraptions will lead to much more advanced technologies than piston doors (just imagine what you could do with a 5Hz CPU!).

...My suggestion would be a gamerule that can turn micropulses on or off so that everybody is happy.

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.

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).
I had some different ones in mind when you mentioned microticks but I cannot remember where I saw them.

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.
In other words, you will have a moment where you will see the piston retracting although the redstone line was always ON!!

"As I also mentioned, it is very possible to make instant logic work right now."
Nope, not reliably. Build an instant adder and test all possible input transitions, even better, do it at operation speed (5Hz).
Of course, I'm happy to be proved wrong.

"You have to synchronize the incoming signals to solve that"
They are synced to the shortest consistent time unit of Minecraft (1 game tick).

"Apply logical thinking instead of requesting a change that makes it easier."
I'm ignoring this since you could say the same thing about builds that rely on micropulses if the situation was the other way around.

"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."
"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?"
Once again, you are not losing anything if Mojang introduces a (server) command that can switch between the unintended and intended behaviour. There does not have to be a trade-off.

"That's not a nice trade-off."
That's your opinion.
...Maybe think about what could be done with CPUs that are more than 50 times faster than anything that has been created in Minecraft.

Confirmed for 1.9.4.

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?
For example the following contraption:
http://imgur.com/KPDVUL4
In the current version if you flick the lever after the repeater delay, the piston on the right will get a 0 tick pulse, and within a single gametick he will extend and then retract.
I would not know what should happen in this situation if we do not allow pistons to react to 0 tick pulses.
Do you want, that the piston on the right doesn´t react, because it´s a 0 tick pulse? That solution doesn´t work here, because if the piston on the right doesn´t extend, then the piston on the left never retracts, and then the pulse never gets turned off, which means that the pulse wouldn´t be a 0 tick pulse, which means the piston on the right should extend.
Do you want the piston to extend and wait one gametick before retracting? Well in this situation we will see the piston extending for 1 gametick, even though the redstone line is off. Now since you´ve previously said, that it is illogical if there is "a moment where you will see the piston retracting although the redstone line is ON." then you will also consider it illogical if a piston extends even though the redstone line is off. So that solution doesn´t work here either.
So what is the intended behavior in this situation? I find a 0 tick pulse in this situation quite logical.
Another note about the " you will see the piston retracting although the redstone line is ON.": This is normal piston behavior and can be recreated even without 0 tick pulses. When you retract a piston it will ignore any other pulses until it finishes its retraction. You can recreate this situation even without 0 tick pulses, by retracting a piston and powering the piston again in the next gametick. Even though the piston will be powered 1 gametick after it started to retract, it will continue to retract. You will see the piston retracting although the redstone line is on. Now you might consider this to be illogical, but this illogical part is not related to 0 tick pulses. If we "fix" 0 tick pulses (whatever that means), then this illogical part will still be in the game.

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.
The only thing I imagine would be possible as a fix, is to make a piston always finish its extension, taking 3 gameticks, so it works the same way as its retraction. Thus: when the piston is powered, it extends, and will ignore anything powering it for the next 3 gameticks. This would mean sticky pistons don't leave blocks behind ever, which is a big reason why redstone is so fun to play with, as I think you can understand.

"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).
There is no why any game or simulation could handle this situation correctly. In this case, you cannot avoid pulses (I mean you could just make it so that nothing is happening at all but I agree with you that this is probably not the best solution).

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.

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".
Now I think there are even more examples where 0 tick pulses are unavoidable:
Let´s look at this:
http://imgur.com/b1RqoCx
This is just like my previous example, except I added another piston on top. If I flick the lever on, the piston on top will recieve a 0 tick pulse. Now since we already established that the piston on the bottom right will react to the 0 tick pulse, I think the piston on the top should also react to the 0 tick pulse. There´s no relevant difference between the piston on the top and the piston on the bottom right, and they both get powered and depowered at the exact same moments in the update order, by the exact same piece of redstone dust, so I think they should behave in exactly the same way.
Do you agree?
If yes then we have something called a 0 tick pulse monostable.
And there are even some 0 tick monostables which actually get used which kind of work like this. For example this 0 tick monostable relies on the same principle: http://imgur.com/PnEZabk
So if you think it´s ok to keep this, then you might want to add another edit to your bug report, because the bug report makes it look like you want to remove such monostables.

Confirmed for 16w20a.

Yes, I am criticizing the random block updates and their consequences, which are 0-tick pulses because Minecaft does not update blocks in sync.
The problem is not necessarily the update order but the lack of a "buffer", meaning that Minecraft should wait until the next gametick to put all affected blocks into the next state at the same time instead of reacting successively in microintervals (whether it be to user inputs or circuit outputs). The update ordering/processing should all be done "internally" instead of directly influencing in-game behaviour.

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".
Thank you for taking this a step further by comparing the piston inside the loop to an "external piston" and showing how there would be inconsistencies if you used micropulses in some situations as solutions to impossible tasks and got rid of them in other situations.
Because letting nothing happen even though the switch changed state doesn't make sense and because not allowing a switch to be toggled would be strange (and because inconsistencies are to be avoided), my conclusion on instant feedback loops is: The internal piston(s) should turn into derp piston(s) (lock in the current state) and the external one(s) should therefore do nothing. All this does not require micropulses.

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.

Well, there´s nothing I can say against adding a gamerule.
The only thing I might want to add is, that if "the piston should pulse" is just as legit as "the piston should turn into a derp piston", then I think it would be better if the piston pulses, because if the piston turns into a derp piston then absolutely nobody is happy, while if the piston pulses, then at least some people are happy. So I would say the piston in the loop should pulse, not because of logical consistency reasons, but because of utilitarian and game design reasons.
But again, if it´s just an optional gamerule, then it´s just an optional gamerule.

Confirmed for 16w21a.

Confirmed for 16w21b.

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.

Confirmed for 1.10-pre1.

Confirmed for 1.10-pre2.

Confirmed for 1.10.

Also affects Minecraft Pocket/Win10 Edition v0.15.0 (MCPE-15391).

@@unknown: Please use the preview feature when editing something - you're flooding 20 people with every edit attempt.

oops, sorry.
didn't know you get a notification for every edit.

Confirmed for 1.10.1.

Is this still a problem in Minecraft 1.11?

"Is this still in Minecraft 1.11?"
Yes.
Minecraft 1.11 should be added to the affected versions of this report.

"Is this a problem?"
No.
(at least if you ask me)

Did you read the last part of the description?

Confirmed for 1.13.2 and 19w02a.

All those pics show 0tick 0ff pulses
This has nothing to do with redstone dust or pistons
Its to do with the fact that repeaters are faster than torches

And its possible to make 6.7Hz CPU's in minecraft

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.

Vincent Wiltschek
I have a proof of concept for a 6.67hz CPU 😉 didn't put in the time to finish it though

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.