Back to minecraft.net

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! Items in snapshots and betas are subject to change so please be sure to only post about things that are currently released in Minecraft. Please read the intro post before you post!

← Parity
825
Follow

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

under review

Redstone is different in Minecraft: Bedrock Edition. Quasi-connectivity, also known as the BUD switch or the Etho switch, wasn't added into the game when pistons were added. Please upvote to get this weird redstone element back into the game. Yes, many existing creations will break, but making redstone the same as in the Java edition will help the spread of ideas between the two Minecraft communities.

Avatar
Registered User shared this idea

78 Comments

Please sign in to leave a comment.

Date Votes
Sorted by oldest
  • Official comment
    Avatar
    Registered User commented
    Comment actions Permalink

    Clarified subject to help search results.

    Thanks for your contribution.

  • 20
    Registered User commented
    Comment actions Permalink

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

  • 12
    Registered User commented
    Comment actions Permalink

    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.

  • 34
    Registered User commented
    Comment actions Permalink

    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.

  • 5
    Registered User commented
    Comment actions Permalink

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

  • 4
    Registered User commented
    Comment actions Permalink

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

  • 12
    Registered User commented
    Comment actions Permalink

    @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.

  • 2
    Registered User commented
    Comment actions Permalink

    Please stay on topic, thanks.

  • 8
    Registered User commented
    Comment actions Permalink

    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)

  • 5
    Registered User commented
    Comment actions Permalink

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

  • 6
    Registered User commented
    Comment actions Permalink

    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. 

  • 3
    Registered User commented
    Comment actions Permalink

    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.

  • 3
    Registered User commented
    Comment actions Permalink

    Please don't

  • 10
    Registered User commented
    Comment actions Permalink

    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.

  • 10
    Registered User commented
    Comment actions Permalink

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

  • 11
    Registered User commented
    Comment actions Permalink

    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.

  • 8
    Registered User commented
    Comment actions Permalink

    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*.

  • 7
    Registered User commented
    Comment actions Permalink

    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)

  • 5
    Registered User commented
    Comment actions Permalink

    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

    SEPARATE BEDROCK REDSTONE RANT:

    [Removed. Stay on topic. ~ admin]

     

  • 4
    Registered User commented
    Comment actions Permalink

    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.

  • 1
    Registered User commented
    Comment actions Permalink

    That's what observers are for!

    This feature just doomed one of my big Redstone projects!

  • 2
    Registered User commented
    Comment actions Permalink

    it should be a toggleable feature

  • 7
    Registered User commented
    Comment actions Permalink

    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.

  • 4
    Registered User commented
    Comment actions Permalink

    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

  • 8
    Registered User commented
    Comment actions Permalink

    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. 

  • 7
    Registered User commented
    Comment actions Permalink

    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 thinng 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 bigger and complex.

  • 4
    Registered User commented
    Comment actions Permalink

    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.

  • 5
    Registered User commented
    Comment actions Permalink

    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.

  • 1
    Registered User commented
    Comment actions Permalink

    Maybe put this feature into the game behind the experimental toggle

  • 1
    Registered User commented
    Comment actions Permalink

    How about making it an optional feature. You'll be able to chose what type of mechanic you want. It will be like enabling and disabling command block functions.