DicoTheRedstoner

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

@Connor Steppie

I can reproduce this in 18w47b.

I don't believe that this report is necessarily duplicating MC-11193.
The reason for this is that MC-11193 addresses the order in which connected pieces of redstone dust change state, whereas this report (indirectly) addresses the order in which a single piece of redstone dust updates adjacent blocks. This is a fundamental difference which must be made clear.

Why was this bug reopened? I thought we determined that there's some sense behind it.

I'm pretty sure this doesn't happen anymore.

Why did you change the title? I think "Arrays of repeaters" best describes the cases where this bug occurs. Repeaters separated by blocks or nothing at all, as long as no redstone is in between 2 repeaters this bug occurs. "some repeater setups" does not actually say anything about when this bug occurs.

It is still an issue but it should not be fixed at this point anymore. It would break too many redstone creations. Thus, please close it with the resolution "Won't fix".

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.

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.

Big thanks to Fenhl for consistently testing this bug and updating the issue!

I added an edit to the description, at the bottom.

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

Sorry, yes this is still a concern in the current version, however it has become slightly more stable.
I'm quite certain that it works reliably if the monostable is powered from 2 of 4 directions now, but it's definitely still in the game.

The preferred solution for me would be to make it not power any pistons, but still power repeaters.
Let me argue why:

Nearly every redstone contraption is made to not rely on unreliable bugs in the game, to ensure that it is not coordinate dependant, random, or direction dependant.
So nearly every redstone contraption is made to not use this monostable to power pistons directly, but this monostable is the most often used monostable in the game, so it is important that it will power repeaters. Fixing it this way will break next to no contraptions. Remember that most redstone creations take hours to complete, and some even months. Having to go back and fix them, which might sometimes be impossible, will take another large amount of time.

I know that this way of fixing it doesn't make much sense, but now you know why I prefer it, and I'm sure you can see my point.

To quickly clarify why this bug occurs:
When the piston pushes the block, it does not update directly after. The first update comes from finishing the extension, after 1.5 ticks. Thus, the piston starts its retraction 1.5 ticks after extending, making it not leave the block behind, because for that it needs to extend for less than 1.5 ticks (most often referred to as receiving a 1-tick pulse).

To confirm this, you can have a repeater coming from the redstone dust that powers the piston, which updates the piston (without powering it).

This is not necessarily a bug, we might eventually see what Mojang thinks of it. If it were fixed, many buds would definitely break, such as the sticky piston with a slimeblock and a redstone block bud, or the one with glass and sand on top. Thus I would prefer to see this report's solution also become 'works as intended'. Generally, redstone changes are bad, because they often break many contraptions that rely on current redstone mechanics. This one certainly would break quite a few if it were Fixed.

Why should it be resolved? No offense intended.

Yes Pixie, but as I said, the redstone dust on top of the slab *is not powering the redstone next to the slab*. Redstone dust does not connect to pistons, they are not a power source. They do connect to redstone torches, as they are a power source. An exception to this rule is powering redstone through blocks.
Since redstone dust is a power source for redstone dust around it, redstone dust connects to eachother visually. But since a slab creates a 1-way connection (diode), only the dust on top of the slab redirects.

If you read my earlier comments, you would know why this is. Redstone connects to sources of power, not to power destinations.
The redstone on the slab doesn't power the redstone next to the slab, thus the redstone next to the slab shouldn't connect. As a dot, it powers to all sides, so why would it make sense for it to be a line?

The redstone dust next to the slabs in that pic should be a dot, as it powers to the side as well. For the rest though, thats new behaviour, where it connects through unsolid blocks.

As a very long-time redstoner, I think that's a really nice new feature which I as well as Sidney600MC would love to see in 1.9. So I sure hope it will be 🙂
it doesn't break anything made in the past, but it makes for some cool new ways of doing things. I see no reason myself to remove that feature.
I'll quote sidney - "cause it's just awesome, no more words needed"

So yea - If it's not intended - make it intended!

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