Redstone components don't apply the correct amount of delay when activated by world changes

Interesting. It is possible that this one and MCPE-15607 stem from the same root cause.

I had something similar. I was working on an automated melon farm using the observer block. I had the farm working correctly last night, and when I looked at it today, two of the repeaters in the circuit would not activate. I removed the repeaters and put down two new ones and the circuit began to work again.

I was testing this on a Windows 10 Edition. I can attach a download of the world if you need it.

I can confirm that driving the last stage of your input chain with a redstone block on a piston does work as a fix (with as many relays running into the redstone block piston as you need). This leads me to believe it's a problem with the way piston timing and redstone timings interact.

Still a problem in 0.15.2

Still broken in 15.4.

Affects 0.15.10 & 0.15.90.8 (0.16.0 beta build 5).

Re-opening, as this was incorrectly closed as a dupe of MCPE-13983, which was a separate bug which has now been fixed. I have copied over the information provided by @unknown relating to this bug and added it to the description. Also revised the report title and attached the relevant screenshots from MCPE-17208 & MCPE-17274.

Revised title again, since this is not a bug exclusive to delays from repeaters, but delays from comparators, redstone torches, and other redstone delayers.

Now even worse in 1.1.0.0... previously, repeaters set to 1 rs tick delay seemed to have no delay compared to just redstone dust. Now, a repeater set to a 2 rs tick (4 game tick) delay also seems to have no delay compared to redstone dust. This breaks almost everything that relies on redstone timing. (And most contraptions were already having to use extra delay to ensure things were activated in the right order... now they need even more.)

Revised title yet again to be even more descriptive of the issue.

In 1.1.0.5, the behavior has reverted to what is was like pre-1.1.0.0... still broken, but less broken. 😛

I can't confirmed on 1.2.1.1.
Probably fixed.

^ Still occurring in 1.2.1.1. How did you test this?

MaladjustedPlatypus

I tested this way.
But, Re-affected on 1.2.2.

@r.takahashi Although the pistons are clearly getting pulsed at the same time, if you look closely you can see that the redstone dust next to the repeater is being activated 1 tick after the piston.

Still affects in 1.2.5.13

I can confirm this is still happening as of 1.2.5 build 2 on Windows 10. Pistons appear to be slightly faster than before, but that didn't fix this bug (though it may make working around the bug in contraptions a little easier).

Still affects in 1.2.6.2.

I originally posted this to [MCPE-25360] but I think it belongs here more

I captured this behavior today in slow-mo with the help of a

(Uses AutoHotkey v1.1; run then press ALT+k to activate). The

contains 10 images, 5 covering the rising edge and 5 covering the falling edge, representing 0.005 second intervals beginning with 0.005 seconds after clicking the lever. Due to issues with Windows not saving screenshots, images were captured individually on sequential runs.

Can anyone prove if this happens to moving observer blocks?

Edit: I'm going to try my hand at it Sorry, what I'm thinking of is probably a different issue

Still affects in 1.2.10.2.

I built a monostable circuit and placed a repeater in front of it. It should have given me a short impulse but it didn't give me anything at all.

Steps :
1. Place a block and a redstone dust on it.
2. Place a sticky piston vertically and a block on it.
3. Place a block and a repeater on it.
4. Place a block and a repeater on it before the redstone dust already placed.
5. Active with a lever or a button, it won't work as expected.

Watch the video included if you don't understand.

Affects 1.4.0.5

This has been around since repeaters were added and that was in 0.14.0. We are now in 1.4.2 and approaching 1.5

@unknown, Please do not make comments like that, they are not helpful in getting the issue resolved any faster. Thanks.

Okay, sorry about that then🙂

I did some testing on this using the same design in 9 separate locations to make sure there wasn't any other factor in play. I put a lime concrete block on the ones that were following the intended behavior and red on the others over 2 consecutive runs:

Still affects 1.6.0.6

This is also affecting the Xbox one Bedrock version as of the Sept. 17 of 2018 in the most recent update. Please fix this or tell us if this is an intentional thing. 

[Redacted: May have been inside information that Mojang does not want shared at this time.]

For the present, the workaround of inserting a dummy repeater on input signal lines pulsed by world events is often enough to ensure the behavior of the circuit is at least predictable.

Source? ^

There is still a problem with the monostable circuits

Affects 1.11.0.1 beta version

Affects 1.11.0.3 beta version

Please remember that the bug tracker is for reporting bugs only. It is not a discussion forum or a feedback site.

Affects 1.11.4

Affects 1.12.1

I think this is related but with observers this time.

I built a flying machine only with sticky pistons and it should work (or at least, I think so). Just look in the attached files to see what happens.

Sorry if this is not related.

My concern is that if I create redstone contraptions now, and design them to work in spite of this bug, they may break when this bug is fixed. Please fix this ASAP so players can make contraptions that will continue to work in the future.

Affects version 1.14.60.

Observers showing up to a 3 tick (often randomized) delay on 1.14.60.

Affects 1.16.0.63

(note: different types of components are powered in alternating gameticks, it may be useful to know to understand why it happens)

This seems hard to fix without major changes to redstone.

The issue isn't with the repeater. The issue is that when a world change happens, the components activated in that tick (often called consumers) aren't instantly powered/depowered.

You can either:

• remove the delay and make chains of pistons instantly power/depower each other

• add extra delay to repeaters from world changes (and other components known as producers)

• fix it only for player interactions

The first two would break most redstone builds. The third wouldn't, but doesn't really fix the bug fully.

May I suggest that this is marked as "Won't fix"?

Affects 1.16.40 Hotfix.

Affects 1.16.100.55 Beta.

Affects 1.16.100.56 Beta.

Affects 1.16.100

Affects 1.16.200.56 Beta

From MCPE-103999:

In the first video, the piston should extend/be powered like the repeater and redstone dust, but doesn't because it is processed in a different tick ("consumer" tick)

In the second video, the piston is powered, but the repeater is not, and the dust is VISUALLY not powered, because they are processed in a different tick ("producer" tick)

In both situations, the wire, repeater and piston should, logically, all be powered.
This behavior is not only inconsistent with java, it is also very unintuitive. It makes no sense to behave this way.

Still in 1.19.2and 1.19.20.20

1.19.20 too

Still affects 1.19.63 

Given that this is still an issue years later, I would really appreciate some official commentary/explanation of the underlying issue.

On the surface, this seems incredibly straightforward to fix without major changes to tick processing order. That is, simply have components remember their previous power state, and always queue an update to invert them during the next tick if they received any update that would have changed their state during the previous tick. I.e. This should just require adding a flag(s) to tile entities and an additional step to the block update logic). Maybe I'm wrong, and this would break other things, or harm performance more significantly than I think. And of course, I can think of other (potentially noncompatible) ways to address it.

In either case, a specific, techically comprehensive, explanation of this years-old and wildly frustrating bug would help set expectations for how this will be managed in the future, and what impact it will have on our clumsy workaround designs when it is eventually fixed.

About redstone timings in Bedrock Edition
Here's an article about techically comprehensive explanation of redstone in Bedrock Edition, which may be helpful to understand why these issues happen.
In Bedrock Edition, redstone circuits rely on the circuit system to work, rather than block updates. The fundamental reason for these issues is that there is something wrong with the original design of the circuit system. To fix the bug, many disruptive changes must be made, and perhaps even needs rewrite the whole circuit system. That's why this frustrating bug can't be fixed for a long time.

This problem often affects mechanisms designed for tick, because of it I face the fact that the mechanisms do not work correctly and constantly break, which makes their use in the game impossible

In the video, the mechanism should go down 1 block, but because of the different delay of the signal given by the observer, it often works incorrectly or breaks https://youtu.be/fOfB7Tgd_gA Unlike Java, in Bedrock the mechanism works differently every time you run it and it's quite annoying