When you are making your redstone suggestions, please note that Java and Bedrock will not have the exact same the same redstone systems - this would require redoing redstone system completely on one platform or the other. The two systems are functionally different and are going to stay that way. Please be sure to tag your suggestions with (Java) or (Bedrock).

416

Pistons should finish moving blocks before other pistons start [bedrock]

26 Comments

Please sign in to leave a comment.

Sorted by oldest
  • 14
    Registered User commented
    Comment actions Permalink

    Let's gooooo!

  • 16
    Registered User commented
    Comment actions Permalink

    This would be great for bedrock redstone. Please consider this over redstone parity.

  • 5
    Registered User commented
    Comment actions Permalink

    This would make redstone easier to do..  i have been fuzzled with this problem alot back in the past.

  • 8
    Registered User commented
    Comment actions Permalink

    We need this on bedrock

  • 9
    Registered User commented
    Comment actions Permalink

    I'd love this feature!

  • 0
    Registered User commented
    Comment actions Permalink

    I hope this would fix duping with pistons although unlikely, great suggestion!

  • 2
    Registered User commented
    Comment actions Permalink

    Absolutely agree tigers, would really make redstone on bedrock a lot easier and more reliable in stuff like flying machines etc.

  • 5
    Registered User commented
    Comment actions Permalink

    It is quite a useful change.

  • 2
    Registered User commented
    Comment actions Permalink

    There are basically zero downsides to this feature. I doubt it will break existing contraptions. Add this. WE NEED IT.

  • 0
    Registered User commented
    Comment actions Permalink

    Bro this is genious

  • 2
    Registered User commented
    Comment actions Permalink

    This change is literally just a slight tweak to piston update order, so it won't break anything.

  • 10
    Registered User commented
    Comment actions Permalink

    The challenge of piston randomness would still exist if this change was implemented, along with the extra challenge of making your contraptions as fast as possible. This would make the game more interesting for technical players and make bedrock edition redstone more accessible, along with attracting players from java (maybe).

    Unreliable redstone scares off new players and makes them view bedrock as buggy and unplayable. They don't get a chance to experience bedrock exclusives and they miss out on all sorts of cool features. This change would help fix that.

    Pistons themselves would not move blocks faster with this change, so you would have to chain multiple pistons to move the blocks faster, leading to an interesting challenge and more interesting gameplay.

    Of course this is entirely optional, so if the player is not paritcularly interested in this, they will still be able to enjoy faster farms and will find it easier to learn redstone. I can't seem to find any negatives to this change, so I see no reason not too implement it.

  • 0
    Registered User commented
    Comment actions Permalink

    Justo tengo este problema con las máquinas voladoras que tienen 2 pistones pegajosos funcionan al azar

    Que terminen su ciclo en el mismo TIC sería fantástico

  • 2
    Registered User commented
    Comment actions Permalink

    The reason pistons are inconsistent on the bedrock edition is because the piston head is a tile entity, and is thus updated in a separate part of the update order than the rest of the piston, which receives block events. Making pistons wait for other pistons to finish would serve only to BREAK a number of existing contraptions.

  • 2
    Registered User commented
    Comment actions Permalink

    My suggestion is just to change tile entity update order. I'm not suggesting massive changes. Nothing will break.

    The great thing about pistons being unreliable is that you can make them more reliable without affecting anything.

    This behaviour can occur randomly already as well.

     

  • 0
    Registered User commented
    Comment actions Permalink

    This this would be a great change, as this has been a problem that has plagued me whenever I make tree farms, piston doors, fast flying machines, and pretty much any fast contraption that uses pistons.

  • 0
    Registered User commented
    Comment actions Permalink

    I think that the redstone mechanics should be the same on all platforms.

  • 0
    Registered User commented
    Comment actions Permalink

    YEEEAAAASSS PLEEEEEAAASE

  • 1
    Registered User commented
    Comment actions Permalink

    But what if you made 2 pistons at a time activate? Would one go before the other?

  • 0
    Registered User commented
    Comment actions Permalink

    I have encountered this because when I make my flying machine the game shows both pistons moving at the same when they are really moving at different times time plus a ton of lag.

  • 0
    Registered User commented
    Comment actions Permalink

    i wwant to happen but it didnt

  • 0
    Registered User commented
    Comment actions Permalink

    This could fix observer flying machines

    Also what happened to redstone between Wii U an switch

  • 0
    Registered User commented
    Comment actions Permalink

    Will this make it easier to make flying machines in bedrock?

  • 1
    Registered User commented
    Comment actions Permalink

    Nothing’s more annoying than testing something 5 times and it not breaking once. Then when you show someone else, and it breaks.

  • 1
    Registered User commented
    Comment actions Permalink

    That suggestion is good in my opinion,it doesn't completely take the challenging part of redstone out and opens new possibilities that allows for more complex and fast systems
    It doesn't make already max speed contraptions faster and that's it,it just give us a way to improve things and in some cases it won't be easy to improve it,ofcourse it will make some contraptions faster without adding anything to it but things getting easier/faster is a by product of every good addition to the game.
    I like the randomness of pistons because it challenges you to think of something to make it reliable but at some point it just limits you in some cases and lets be honest i doubt it that there will be ever a more awesome redstone component than the piston,don't understand me wrong things like the target block and the sculk sensor are awesome but they ain't as awesome as the piston,my point is if there's a way to improve one of the most usefull and awesome redstone component without completely taking the challenging part of it why don't add to the game?

  • 0
    Registered User commented
    Comment actions Permalink

    I had a suggestion that included this change, as well as some other changes to fix several problems with Bedrock Redstone, but the text is 7,937 characters long, which is way over the 1500 character limit, and I don't think I could shrink the text all the way down to that size without omitting some changes and the reasons behind all the changes. This I have thought of a while back, and I definitely want it as it fixes probably 90% of the issues with piston randomness while leaving in the one good bit about it, easy randomizers. There is a situation where the randomness is still a problem, namely if a piston is going to extend, and it is also going to be pushed or pulled in the same tick. The piston extending first is the more useful option I think. This can speed up the max speed of Redstone contraptions, as currently you need to make sure that piston starting movement and finishing movement stages are separated to prevent unpredictable behavior, this change will allow you to often combine those stages, allowing for the max speed to increase by up to a factor of two, although there are situations where this change doesn't make things faster, due to pistons that have just been pushed into a space where they are powered only extending the next tick. This can be fixed by updating the finishing of movement before power sources and circuits update, while updating the starting of movement after circuits update, likely in the updating components phase. I have now hit the 1500 limit.