Repeaters add random delay to pistons (but not to other components)

I've seen similar issues in 0.15.9. Pistons and repeaters now interact very weirdly with regard to the ticking order, I mean, pistons that are supposed to be ticked have a chance of being skipped or prematurely extended/retracted when they are powered by a repeater. I guess they changed the ticking system to fix MCPE-15607 but the result is unfortunately even more buggy than before... ;(

The randomness isn't a bug in itself. If two pistons are activated during the same tick, then it is completely random which one will actually be activated first. You need to make sure one of them are activated a whole tick before the others for it to be non-random.

On the other hand, the repeaters seem to be buggy.

This bug has been in the game since pistons were added, probably sooner. Yes the randomness is not a bug, but the fact that the dpe in images 3-4 work at all is. 🙂

@tomas: Yeah I knew that ticking order was intentionally randomized. What I found was, however, inserting repeaters to create a delay sometimes didn't do the trick. Even a repeater set to 4 ticks had a random chance to add no delay to pistons as you said. Repeaters behave completely normally to any other mechanical components.

And in some cases repeaters can add too long delay to pistons, e.g. a repeater set to 2 ticks sometimes add 3 or 4 ticks to pistons.

@unknown: Are you saying that DPE should work as long as there are 2 ticks and 0 ticks delays respectively but currently doesn't? If so that's MCPE-15607, not this one.
This very bug has been introduced very recently to 0.15.9 and 0.15.90.7. Contraptions that were working flawlessly in 0.15.8 now occasionally malfunction.

I meant that this dpe should never work

The screenshot shown below is a circuit to move an extended piston back and forth. It was perfectly working until I updated the game to 0.15.9. Its expected behavior when you turn the lever off is as follows:

• At t=0, you turn the lever off. Ideally the piston A should start retracting but in reality nothing happens due to MCPE-15607.

• At t=1, piston A starts retracting.

• At t=2, piston A finishes retracting. At the same time piston B starts retracting because the redstone block is no longer adjacent to it.

• At t=3, piston B finishes retracting.

• At t=4, the repeater deactivates. Ideally the piston C should start retracting but it doesn't for the same reason as t=0.

• At t=5, piston C starts retracting with pulling piston B because B has already been retracted at t=3.

However in 0.15.9, there is a small chance that the piston C leaves B behind, which is completely unexplainable. It is as if the repeater were only making 3 ticks delay even though it is set to 4 ticks. Adding one more repeater to piston C works around the problem but it shouldn't be needed at all.

May be the fact that pistons unpowering other pistons is not instant in PE, maybe this was improved/worsened in 0.15.9

I think this may be related to, or even the same bug as, MCPE-17208.

redstone dust has 1 tick delay. tested this side by side with a repeater and a comparator and they activate piston at the same time. tested it on 0.15.10

To explain what's going on:

If you activate a repeater with an in-world change (pulling a lever, pushing a button, placing a redstone block, a piston pushed/pulls something which causes the redstone system to change) then the repeater will activate with 1 tick less delay than it should. A 1 tick delay repeater would activate immediately just as if it was redstone dust.

Resolving as duplicate of MCPE-15793.