X

THANK YOU!

Post has been reported succesfully.

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!

140

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

under review

26 Comments

Post a new comment:

Please sign in to leave a comment.

  • Official comment
    Avatar

    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

    SEPARATE BEDROCK REDSTONE RANT:

    [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