The screenshot shown below is a falling-edge detector which should emit 2 ticks pulse on a falling-edge and shouldn't emit a pulse on a rising edge.
[media]The repeater is set to 2 ticks delay. On a rising edge the piston should take 1.5 redstone ticks to extend so there should be no pulse emitted from the output. On a falling edge the piston should retract instantly (0 redstone ticks) so there should be 2 ticks pulse from the output.
However in 0.15.0, pistons take 2.5 or 3 redstone ticks to extend and 1 or 1.5 redstone ticks to retract, so the said circuit instead acts as a 1 tick dual-edge detector.
According to a developer, it might be a result of the redstone circuit ticking separately from the block entities (piston). During the 2 tick: Redstone ticks first, which will propagate the repeater. The piston ticks afterwards placing the moving block as full block.
Related issues
is duplicated by
MCPE-14687
Behind the piston due piston is retracted speed is slow is not pulled in front of the piston
MCPE-15071
Pistons are working too slowly
MCPE-15219
Sticky pistons not working properly
MCPE-15601
Takes to long until you can close/open a piston after you opened/closed it
MCPE-17406
Very slow pistons.
MCPE-20961
Pistions and Sticky pistons are slower
MCPE-21271
Piston timing bug
MCPE-21789
Pistons don't extend other pistons.
MCPE-26165
Piston timings are slow and VERY inconsistent!
MCPE-190440
A high-frequency device with an excessively high frequency can cause the piston to malfunction.
relates to
Attachments
Comments
migrated
migrated
I suspect that this one and MCPE-12848 stems from the same root cause.
SuperGeniusZeb
Revised title to be more accurate to what the intended piston timings are for Bedrock Codebase.
HelenAngel
This was closed by the design team as works as intended.
Explanation below:
"It takes exactly 2 rTicks to retract, but because the pulling piston starts retracting (toggleMechanismTiming example) at that same tick, the ticking order is scrambled (as designed) therefore the result is undefined."
migrated
Thank you Helen but I don't think that is correctly explaining the behavior because the circuit always emits pulses of the same length and not randomized. However, I just found the following modification perfectly fixes the problem so this turned out to be in fact another instance of MCPE-15793.
[media]So yes, the ticket can be safely closed either way.