Piston timings are slow and VERY inconsistent!

I have working piston double- and even triple-extenders. It's just a matter of getting the timing right for Bedrock. When they work inconsistently, you need to add 1 more tick. I doubt Mojang is going to try to make pistons work with the same timings as Java.

However, you'll find there are some old redstone bugs around repeaters and comparators, mainly, and some non-determinism that we've been waiting a long time for Mojang to fix. Keep in mind that technical Minecrafters have been a small minority in Bedrock codebase, so redstone bugs haven't gotten a lot of votes. Hopefully more Java redstoners will tackle the challenge of replicating designs in Bedrock and help upvote them, so we can get a more reliable base for redstone behavior.

That would be great because as of now, redstone is very annoying on this "Bedrock" version. I messed around with it more and could produce consistent 2 and 3 piston extenders, but they are stupid slow and large. It works as if the pistons themselves have been slowed 2 or 3 times what they should be. They probably did this to bring redstone to the very under-powered mobile devices, but now that this is playing on PC (Windows 10), and new beefy consoles, and the new high-powered mobile, they really should fix this.

Also, I do not see many high-end Youtubers moving from Java to Bedrock. Mainly because, most of them have been playing Java for years and years (some even since Alpha), and they do not want to learn a completely new game, which is basically what Bedrock is of now. Also, Java has a significant amount of more freedom than any other version. I mean, on "Bedrock" version, everything extra is tacked behind a paywall, and it is basically impossible to download custom resource packs, custom maps, and others. As well as mods... but I really do not care much at all about mods (except enhancing mods like Optifine, because who doesn't use that?)

I like the idea that Microsoft is making one Universal Minecraft to be played on many devices, but if they want to draw over most of their Java Minecraft community, they will need to be making some serious changes..... or fixes..... yeah.

And also, I can live with slow pistons if they do not want that to change. But please at least make these things consistent. If I make a piston extender that should work, I want it to work 100% of the times I flick the lever on/off. Not only about 45% of the time at complete random. If we make large piston doors (4x4 or 5x5), I do not want it to work sometimes, or completely break itself another time. Redstone is too unreliable right now to make it useful...

In my original comment I meant to say I have working piston double- and even triple-extenders that work 100% of the time. For example, I've copied cubfan's Hermitcraft V triple-extender elevator he uses to enter his base (modified to have a 2x2 floor and work on a push button). I would be willing to give you a copy of it, But we shouldn't be discussing this on Jira.

I mean, yes I have been able to make extenders that work flawlessly, but the problem is that they are extremely slow and bulky...

Duplicate of MCPE-15793?

MCPE-15793 can be a complicating factor in piston circuits, but it isn't the whole problem being described here. This problem is that a piston requires 3 ticks after it retracts before it can be reliably retracted by a second (sticky) piston. If you only give it 2 ticks to cool down, it succeeds or fails unpredictably. MCPE-15793 happens when an activating pulse arrives during a game tick that isn't a redstone tick. You can fix it by putting an extra repeater in the circuit, because a repeater's output is always synchronized with a redstone tick (even when it outputs prematurely in such cases). But that fix doesn't help with the circuit shown in the first screenshot.

The issue I am talking about is specifically the piston timings. Since the beginning of Minecraft (now Java Edition), Pistons have taken 1.5 redstone ticks to extend, and 0.5 to retract. In this bedrock version, both take 2.0 redstone ticks. And the retracting is inconsistent when giving it 2 ticks.

Also as a side note: I just experimented on Xbox 360 edition and it functions literally the exact same as Java edition. Same timings, and even BUDS and Quasi connectivity. But Xbox One edition has to downgrade to this mess of redstone bugs..... Honestly I could care less about Quasi and Buds, I just want correct piston timings and consistency.

In that case, I'm afraid this report duplicates MCPE-15607, which was closed by the developers with the following comment (emphasis mine):
"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."

As a tool for building automation, Java's redstone is a complete mess, but Bedrock's is worse, and despite what they say about Bedrock being the chance to fix the mistakes made in Java, M&M don't really want to fix it. It's too bad, because a redstone system founded on real world math, engineering, and CompSci would be a tremendous tool for teaching kids future career skills. Heck, make that life skills in the information age.

So you are saying that it is "Intended Behavior" for piston outputs to be randomized based on a CONSTANT input? That is really stupid.... like seriously..... A consistent input should give a consistent output. It should either work, or not work. I should not have to just add more delay to go around this problem..

Also, about Java redstone being a mess, sure BUDS and Quasi make it a mess, but it is easy to go around those, or use them in designs, like activating two sideways pistons stacked vertically at once.

All I want to know is, why is it too difficult for them to keep piston timings consistent between versions? The Bedrock version is obviously a horrible downgrade from Java.

I imagine the problem is that for performance reasons, Bedrock uses a lot of multitasking, so each component runs as a separate, unsynchronized process and their order of execution is unpredictable. It could be solved by synchronizing them, but whatever method you use to do that will slow down the game so low end devices won't be able to run it any more.

Bedrock is only an "obvious" downgrade if you come from Java. If all you've ever known is Bedrock, it's the other way around.

I guess so. Still, PC's, Xbox One, PS4, and Switch should have no problem running the game with the synchronized process system you explained. It is just the mobile devices that are bogging the game down.