mojira.dev
MCPE-15793

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

What I expected to happen was...

On flicking the power switch in each example, the blue example shown would fire like the red example shown (end repeater lights up).

What actually happened was...

In the blue example, the output repeater doesn't fire. If you rapidly flick the switch back and forth, the blue repeater fires intermittently.

Steps to reproduce:

  1. Drive redstone current into a block on top of a piston to generate a 1-tick pulse (red example). Position a repeater to pick up the current from the piston block, but the redstone should flow directly from power source to the block.

  1. Turn on the power source; the piston will fire and the output repeater will light up for its pulse duration.

  1. Insert a repeater anywhere along the input line and toggle the power source. the output repeater will not fire.

  1. Rapidly toggle the power source (switch works best). The repeater will occasionally fire.

  1. replacing the relay with redstone torch inverters shows the same issue (the mechanism will fire when the torch is placed, but not when the mechanism is toggled).

  1. Using an observer block as the power source showed the same issue.

Minecraft pocket edition 0.15.0 (iOS - replicated on iPhone 6 and iPad air 2)

Update by @unknown
This bug has been reported to our internal bug tracker for further testing and a fix. It is scheduled to be fixed in one of the future updates (no specific date can be provided).
Please avoid duplicate comments. Post only NEW information regarding this bug.

Update by @unknown, explaining the cause of the bug
Repeaters don't apply the delay properly in all cases. If the repeater was activated by another pure redstone component being ticked, then the delay will be correct. However, if it was activated by a world change (lever, piston modifying a circuit, pressure plates, buttons, etc) then the repeater will output a signal 1 tick too fast. A 1-delay repeater will act as a 0-delay repeater (that is, completely ignored). A 3-delay repeater will act as a 2-delay repeater.

Related issues

MCPE-17208 Repeaters set to 1-redstone-tick & comparators have no delay compared to redstone dust MCPE-17274 Repeaters add random delay to pistons (but not to other components) MCPE-20762 Piston Retraction MCPE-20859 Repeaters are broken MCPE-20904 Repeater delay bug MCPE-21087 The repater delay changed in mcpe 1.1 MCPE-21281 Repeaters don't make signals longer MCPE-24278 inconsistent Redstone/pistons MCPE-25859 Piston timings are glitched MCPE-27516 Incorrect Repeater Timings MCPE-28387 Piston Feedtape Bug MCPE-28623 repeater updates 1 tic early and releases a signal 1 tic late. MCPE-28657 Observers triggered by redstone has inconsistent timing MCPE-28690 Monostable cuircuit only works when powered directly MCPE-29171 Pistons need to have consistant timing MCPE-30678 Piston bug MCPE-30888 T Flip-Flop redstone mechanism MCPE-31399 Monostable circuits aren't working MCPE-31470 Double piston extender not working MCPE-31790 Piston monostable pulse generator not generating pulse when powered by a redstone torch activated by un-powering block its attached to MCPE-33011 Repeater's tick doesn't work correctly. MCPE-33825 Falling edge mono-stable circuit doesn't work MCPE-35543 Redstone not always working properly MCPE-36786 Failure in back-to-back piston monostable circuits MCPE-37625 Sticky Piston is not passing Redstone Ticks to Redstone Repeaters MCPE-41017 Bug with pistons and repeaters MCPE-42968 Piston systems and repeater clock MCPE-60278 Repeaters activate 2 gameticks too early MCPE-75293 Redstone Timing Inaccuracies: Observer and Repeater MCPE-84280 Moving blocks take 1-2 redstone ticks to become movable MCPE-98587 Repeaters changing the way redstone dust interacts with other redstone component MCPE-103691 Repeaters are not applying correct delay and appear as though they do MCPE-103999 Redstone components do not react based on the game tick power is provided MCPE-136762 If a repeater runs into a monostable it won't work MCPE-161802 Circuit breaker pulse limiter does not function properly when receiving input from repeaters, redstone torches, observers, or comparators MCPE-167483 Disappearing signal delay / repeater affects downstream timings MCPE-173858 Left redstone repeater responds differently MCPE-182268 The redstone-mechanism does not work in Bedrock.

Attachments

Comments

migrated
[media][media][media][media][media][media][media][media][media][media][media][media][media][media][media]
migrated

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

migrated

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.

migrated

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.

migrated

Still a problem in 0.15.2

migrated

Still broken in 15.4.

SuperGeniusZeb

Affects 0.15.10 & 0.15.90.8 (0.16.0 beta build 5).

SuperGeniusZeb

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.

SuperGeniusZeb

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

SuperGeniusZeb

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

SuperGeniusZeb

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

SuperGeniusZeb

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

pneuma

I can't confirmed on 1.2.1.1.
Probably fixed.

migrated

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

pneuma

MaladjustedPlatypus

[media]

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

Auldrick

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

pneuma

Still affects in 1.2.5.13

SuperGeniusZeb

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

migrated

Still affects in 1.2.6.2.

migrated

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

[media]

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

[media]

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.

[media]

migrated

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

migrated

Still affects in 1.2.10.2.

migrated

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.

[media]


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.

migrated

Affects 1.4.0.5

migrated

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

Dr.Awesome4333

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

migrated

Okay, sorry about that then🙂

migrated

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:

[media]
migrated

Still affects 1.6.0.6

migrated

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. 

Auldrick

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

migrated

Source? ^

migrated

There is still a problem with the monostable circuits

migrated

Affects 1.11.0.1 beta version

migrated

Affects 1.11.0.3 beta version

Auldrick

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

silentwisperer

Affects 1.11.4

migrated

Affects 1.12.1

migrated

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.

 

migrated

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.

migrated

Affects version 1.14.60.

migrated

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

migrated

Affects 1.16.0.63

migrated

(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"?

migrated

Affects 1.16.40 Hotfix.

Affects 1.16.100.55 Beta.

migrated

Affects 1.16.100.56 Beta.

migrated

Affects 1.16.100

Affects 1.16.200.56 Beta

GoldenHelmet

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)

[media]

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)

[media]


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.

NBG-bootmgr

Still in 1.19.2and 1.19.20.20

migrated

1.19.20 too

migrated

Still affects 1.19.63 

migrated

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.

Former user

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.

migrated

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

migrated

(Unassigned)

32788, 36225, 176093

Confirmed

Multiple

iOS 9.3.2

piston, redstone, redstone-pulse, redstone_comparator, redstone_repeater, redstone_torch

1.20.20.23 Preview, 1.20.20.22 Preview, 1.17.10, 1.16.200.57 Beta, 1.16.100.58 Beta, ..., 1.19.21 Hotfix, 1.19.62, 1.20.12 Hotfix, 1.20.81 Hotfix, 1.21.51 Hotfix

Retrieved