[MC-3703] Redstone changing orientation doesn't update previously powered blocks correctly

The bug

When a line of redstone dust updates and does not / points at a block, the block is not updated under certain circumstances. (redstone redirection)

Affected situations

Block connecting to redstone dust is placed. This includes all blocks that connect to redstone dust (like repeaters, levers...) without creating a redstone signal, see

[media]

Redstone dust which was blocked before connects, see

[media]

Redstone dust connecting downwards from glowstone (see

[media]

), slabs, hoppers, redstone blocks (see also MC-123850)

Linked issues

is duplicated by 28

MC-11113 Deviation redstone Resolved

MC-13045 Redstone Torch BUD Resolved

MC-17241 Placing a comparator doesnt update the torch. Resolved

MC-27238 Redstone Lamp Not Powered Correctly Resolved

MC-41318 Redstone torch is on, even though it's receiving power Resolved

23 more links

relates to 2

MC-2255 Redstone wire uses different criteria for connecting visually and logically Resolved

MC-8645 Redstone wire receiving level 1 power from a block, pointing at another block with wire on it will not power that block Resolved

Attachments

Comments 23

Tails 2013-01-04T19:02:33Z

Still in 13w01b.

kbk 2013-03-01T00:10:40Z

Could not reproduce in 13w09b.

Tails 2013-03-01T00:25:05Z

Reproduced in 13w09b: A little "random BUD-Flop" as seen in the screenshot. Observe how the torch is off eventhough no wire is connected. (the randomness comes from the fact that the torch receives updates randomly)

kbk 2013-03-01T01:04:57Z

Hmmm. This looks too stable and consistent to be a BUD... at first glance.
I toggle the switch - torch goes off - piston retracts - redstone orientation changes - torch magically stays depowered. Then I toggle the switch again - torch magically regains power - piston extends - redstone reorientates to correct state. I get this 100% of the time, but when left alone for some time in this magic state, torch updates itself and piston performs a cycle. Such a funny device...

The pistonless setup on the first screenshot works as expected to me though.

João Mambelli 2013-03-06T03:41:20Z

With "detector rails" also works, alias, you can move the rails with pistons without breaking, that is also a bug?

13 more comments

Mustard Sheep 2014-01-10T21:45:55Z

Still here in snapshot 14w02c ...

marcono1234 2014-05-31T15:46:39Z

*Confirmed for 14w21b

kbk 2014-05-31T17:37:54Z

No, Tails' device still exploits this bug like it ever did.

kbk 2014-08-13T19:07:04Z

14w33a - not fixed

kbk 2014-10-25T14:22:10Z

Yes. Tails' device behaves just as in description.

galaxy_2alex 2014-10-25T14:27:48Z

Reopened, Thanks.

Aaron Rhodes 2015-02-24T05:24:20Z

Still happens in 1.8.3

marcono1234 2015-09-29T21:44:37Z

Confirmed for

15w39c

[Mod] redstonehelper 2015-09-29T22:23:15Z

Gave the ticket to Marcono1234.

Levi Claypan 2017-07-22T07:32:12Z

Still happens in Minecraft 1.12, i think

Timothy Miller 2018-01-04T17:24:17Z

It seems that technical users find this behavior to be extremely useful, while pretty much nobody finds it to be harmful. BUDs weren't initially intended, but it's one of those "emergent behaviors" that even Mojang developers have acknowledged it as being generally productive and desirable, even if some less experienced uses may initially find it to be unintuitive. Intuitive behavior is always a good objective, but we can see how trying to make redstone more intuitive has basically made it broken and useless in Bedrock edition, while at the same time introducing even uglier bugs and even more nondeterminism.

If you want to see an example of productive use of this feature, check out this video: https://www.youtube.com/watch?v=vMYygzMYUs4&feature=youtu.be

I suggest marking this but as "works as intended" or "won't fix," because of all the frustration "fixing" it would cause.

Any further discussion, we can move to /r/mojira or the EigenCraft discord.

Thanks.