Are you sure you want to report this?

What is parity? This category is designed just for features that exist but work one way on one platform, and another way on a different platform. Bugs are not parity! Please read the intro post before you post!


(Java Parity) Return Quasi-Connectivity! | BUD | Etho Switch

under review


Post a new comment:

Please sign in to leave a comment.

  • Official comment

    Clarified subject to help search results.

    Thanks for your contribution.

  • Avatar

    Please no...  It's a neat feature, but it can be equally annoying in other situations.

  • Avatar
    Kyrinon commented

    I'm a huge redstone nut in Java edition and while there are other redstone related reasons I have not made a permanent switch to Bedrock this one has enough work arounds to make the new version a challenge but still doable.

  • Avatar

    honestly I love the bedrock edition, but when I figured out that quasi-connectivity was gone, just about everything I made before bedrock was entirely broken or had a big workaround.  I was finnaly understanding how it worked and how great of a bug it was, then one day it was all gone.  Please Mojang add this helpfull bug back into the game again.

  • Avatar
    vasile9999 commented

    Yeah,my creations are BUD-based, but it is good fun remaking them on bedrock.Quasi-Connectivity is useful but Confusing.It is more likely that the BUDs will get removed on java rather than added in Bedrock.

  • Avatar
    Pneen commented

    Redstone is why I got Minecraft. It's for the educational aspect. 

  • Avatar
    Pneen commented

    Restone was why I got Minecraft. It's the educational aspect. 

  • Avatar
    LateLag commented

    Why aren't you asking for Java Edition redstone to be like Bedrock instead of literally  asking for a bug to be added to Bedrock?


  • Avatar
    Netwin commented

    @LateLag, did you know that creepers were born out of a coding bug? Sometimes bugs are fun and become features. I play Minecraft: Xbox One Edtion, but it isn't updated anymore and can't be bought anymore so I can't play it with friends who are new to the game unless they buy it used on disc. Minecraft: Xbox One Edition was as similar to the Java Edition as they could get it. When I play it I get a prompt regularly to switch to the bedrock edition and get reminded each time that it is not updated anymore. So because of allmost being forced to switch to the bedrock edition I want it to be like Minecraft: Xbox One Edition, so more or less like the Java Edition but optimized for a console. If on the Xbox there was a real choice like on pc where you can play both the Windows 10 and Java Edition which both get updates I wouldn't want it. It is awesome to have two flavours of your favorite game, but not if they stop serving one of them. Then you want what remains to be your favorite flavour, and for that it needs some of the weird ingredients that make it special.

  • Avatar

    Please stay on topic, thanks.

  • Avatar
    Rinni Parker commented

    I have a thought about this. Perhaps add a redstone object called a COIL. The Coil would be made from redstone around a piece of iron. Functionally the Coil would conduct redstone into or out of it just like a piece of redstone - conducting through but not up or down in the way blocks do. Redstone on NSEW would automatically connect to it on any side. BUT

    The Coil when active would then bud-power any other blocks within the bud powering range-mechanic as per standard bud powering mechanics. This meaning you could use the coil as an alternative to bud powering and remove the glitch from the game (replacing it with a mechanic)

  • Avatar

    What I suggest is you right click pistons to choose if they can be bud powered

  • Avatar

    I just cant figure out why they can't just find out what bug made this feature possible. Fix it up, spruce it up and make it work on the regular and sticky pistons. Than have a new piston that is anti-quasi for people who don't want it. It would make more logic that way then any other reason in my opinion. 

  • Avatar
    Emeraled345 commented

    I get how it can be a great feature but as a Java Redstone builder it can be super annoying and a real mess in a lot of other situations.

  • Avatar
    Reuven Cooper commented

    Please don't

  • Avatar
    Borbarad13 MC commented

    Well, I would rather have the quasi-connectivity removed from Java. It's rarely beneficial for me but most often annoying.

    Also new players may spend a long frustrating time debugging their contraption just to learn about this unintuitive Java bug. It seems for me that some older players completely ignore this fact just to prevent some modifications on their contraptions.

  • Avatar

    Without quasi connectivity, most of my redstone builds break, and it takes some of the fun out of redstone

  • Avatar

    I read that the observer was added into Bedrock instead of quasi-connectivity, but it isn’t the same because BUDs in Java are sort of like a t flip-flop (The piston will stay extended until updated)while observers give off a pulse when there is any update. The obvious solution would be to connect the observer to a t flip-flop, but now you have another problem because t flip-flops are incredibly bulky without 1-tick piston spitouts. If you found that confusing, basically what I want is, if quasi-connectivity is not added piston spitouts should be.

  • Avatar
    RomaqRosher commented

    I think a "block-spitter-outer" piston should be included in BOTH versions, so "normal" sticky piston behavior behaves as expected ALWAYS with push/ pull mechanics, but a "grabber" block will ALWAYS push (spit out) and pull (pull an adjacent block) for use in T-Flip-Flops and other situations where you want to remember a "state". THEN we don't have to sweat 1-tick pulses, the length of the pulse won't matter. We drop the bug, we get expected behavior, and we have this on BOTH platforms.

    That's a separate (though obviously related) issue with a "QC" block. I don't understand QC even though I've watched the videos... OVER and OVER and OVER trying to learn how to make predictive sense out of it. What I would love to see is the design of a "QC Block". Block spitting is stable behavior I can understand and predict, so long as I use a 1-tick pulse. QC is more "WTH?" I'd love to see a Redstone block design proposal where the block behaves in a predictable way, same as a the "grabber" piston above or the Observer Block.

    If someone could cook up a "QC" block, make a YT video of how this block works, what it does and doesn't do, I would so totally support that. I obviously can't do it since I can't wrap my mind around a set of specific rules to explain it. But someone does, and someone *can*. Let's replace QC with a block the way observers have, and a "grabber piston" *could*.

  • Avatar
    TheLudGamr commented

    Also, for those complaining about quasi connectivity, I’d like to see you create a non messy hidden piston door (in a completely flat wall, no cheaty covered up pistons)

  • Avatar

    I think more "bug-features" from java should be in bedrock. Take terraria which is finally getting 1.3 on mobile (coded way differently) and they are making sure to ADD a bug called a "hoik" (triangular blocks move you fast) into the mobile coded version of the game because people use it a lot, and they also make sure to never patch hoiks in the PC edition of the game for similar reasons. I think Mojang should take this approach with a few redstone "bug-features". And even if we don't get quasi connectivity i at least want them to add pistons being able to spit out blocks


    [Removed. Stay on topic. ~ admin]


  • Avatar
    SpecialisToL commented

    Quasi connectivity does not make any sense in the function of the red stone, and causes completely unexpected results, unless you are specifically designing with this bug in mind. It makes certain contraptions impossible due to the unexpected interactions (like a tower of waterlogged sticky pistons pushing a red stone block down to power the next piston. This is a very simple mob farm design). This should not be added to Bedrock: as the section title says "Bugs are not parity!".

    What should be done instead is to first add a well defined feature to add what quasi-connectivity enables into the game, for both editions. Then to remove quasi connectivity from Java. At that point, you have two editions working same. There are many suggestions on how this can be done, from pushable redstone connectors to a new piston type pistons that explicitly allows getting powered with quasi-connectivity.

  • Avatar
    CoderTommy commented

    That's what observers are for!

    This feature just doomed one of my big Redstone projects!

  • Avatar
    Tacodude17 commented

    it should be a toggleable feature

  • Avatar
    Greeeem commented

    100% with you on this. So many circuits break on Bedrock when they work fine on Java. Not to mention, that restone tutorials from YouTubers (i.e. Mumbo Jumbo) would work on both editions, reducing headaches.

    I seriously miss this bug. Maybe have a gamerule (something like budSwitch or quassiConnectivity) that enables it? Not sure, I just want it back badly.

  • Avatar

    This would also be sure to help people from Java switch to Bedrock and let the most people be happy. If needed, Mojang could also add a toggle button, so existing ideas aren’t broken

  • Avatar
    BlazingBeam commented

    Bedrock redstone should be in parity with java's so that the community doesn't have to learn two separate systems. Quasi connectivity also adds for much smaller redstone contraptions and will be pretty benificial. Also that redstone in Bedrock is messed up and unpredictable. Even MumboJumbo said that while in java edition a 2+2 will be always a 4 , and in bedrock occasionally a 5. 

  • Avatar
    Light1Knight1 commented

    I like working with Redstone in my Minecraft world on the ps4 edition of the game. I have recently started to play around in the bedrock version because it will eventually replace the last console edition. Just recently I've started to play around with the Redstone mechanics and I am very displeased with it so far. The first think I noticed was that Jeb doors don't exist, and that sticky pistons can never let go of a block in front of them  no mater how short the pulse is. these to differences alone will break all of my designs, and if I was to fix them they would have to be much more bigger and complex.

  • Avatar

    I would love to see either a toggle on the piston to turn on/off quasi-connectivity or a separate piston that behaves similar to a Java piston.  You could then add 'Bedrock Piston' to Java and 'Java Piston' to Bedrock and then you have parity.  Either way, I think the best implementation is to have both functionalities in the game and not one or the other.

    This feature is really important.  Since there is no universal "how to" manual for Minecraft, your only real resource for how to do certain things in the game is via wiki articles and youtube videos that are seemingly 90% Java.  I can deal with a missing feature, but when fundamental behavior is different then it becomes really difficult to trust what you see online, extremely difficult to determine what you are doing wrong, and nearly impossible to find a resource on how to "fix" the problem.

  • Avatar
    Joethar commented

    Respectfully, I disagree.

    I would rather not have a behavior like this intentionally added to Bedrock edition.  There are some cool Java creations that take advantage of quasi-connectivity but not cool enough to warrant confusing my kids (or myself, for that matter) with difficult-to-predict behaviors.

    To me, it seems like energy might be better spent ironing out some of the existing idiosyncrasies in the redstone implementation.  Reliable bi-directional flying machines, reliable 2-4-0 double piston timings, and sand/gravel not occasionally breaking when moved by a piston are all things I would rather see long before this is considered.

    Sorry to be a wet blanket on this one.