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

← Redstone
44
Follow

QC and Observers

I was having a look at understanding why redstone was different in bedrock to java and noticed a couple of issues.
Quasi-connectivity is needed for redstone to function.
Observers don't detect some block updates in bedrock but do in java.
Given the main demographic of the game is a younger audience that is most likely playing on bedrock for ease of access. If wanting to use redstone they look up tutorials or maybe buy the Official Guides. A main argument to this - the 3x3 piston door. The Official "Updated" guide has this and don't work on bedrock versions because it uses QC. And if the alternative solution to QC was observers. Shouldn't they work the same way universally? Don't remove QC and this from java. That would torture too many people. But fix redstone in bedrock please.

Avatar
Registered User shared this idea

8 Comments

Please sign in to leave a comment.

Date Votes
Sorted by oldest
  • 3
    Registered User commented
    Comment actions Permalink

    Quasi-connectivity is NOT needed.  It's as much a curse as a blessing.  What's funny is I've been watching old Etho videos and when QC is introduced he calls it a piston bug and hopes it will be fixed soon.  It's only when it wasn't fixed that people started treating it as a feature and finding ways to make use of it.  And I think the fact that so many Java redstoners rely on it now is the only reason they haven't removed it from Java.  But it's something that shouldn't be in the game, and that's why they decided to not have it in Bedrock.

    I would agree that observers should not have a difference in what they detect between the two versions.  Although the issue might be due to the fact that the two versions are coded very differently, so something that produces a block update in one might not in the other.

    In the end, what we need is more people making tutorials for things in Bedrock, not to "fix" Bedrock redstone by making it the same as Java redstone.

  • 2
    Registered User commented
    Comment actions Permalink

    Observers now detect more stuff in Bedrock as of 1.6

    • Observers will now detect changes with Droppers, Dispensers, Brewing Stands, Farmland, Saplings, Sugar Cane, Fire, and Grass blocks

     

    Also there's no need for QC to do redstone. There have been 1 wide 3x3 piston door designs that work in bedrock. Example: https://www.youtube.com/watch?v=LUWwX6GtWrU

  • 3
    Registered User commented
    Comment actions Permalink

    I understand that QC isnt necessary for redstone, but it is certainly unique in how it functions. While the observer was born from this (pistons that are broken are fixed by adjacent block updates) there is no reason to not adopt this for a new piston specifically.

    Also the Observer is still broken, albeit intentionally this time, it cannot detect when the stem attaches to or detaches from a pumpkin or melon. However, it can detect growth stages before they can produce melons or pumpkins.

  • 2
    Registered User commented
    Comment actions Permalink

    How about this: https://feedback.minecraft.net/hc/en-us/community/posts/360010962752-Quasi-connectivity-on-bedrock-solution-

  • 0
    Registered User commented
    Comment actions Permalink

    Observers expose details of the internal implementation of redstone on the two platforms. Normally, Mojang avoids doing that because it greatly increases the chances that people will build machines that depend on those implementation details. When that happens, Mojang can't make improvements in the code without breaking all those machines, and that makes players annoyed. By adding observers, they violated that principle. They only did it because they hoped it would be used to replace QC, at least on Bedrock (and I believe in Java, too). And it has done that, at least to a degree, because observer circuits can be easier to design, build, and debug than those that depend on QC.

    But there's still the issue of observers exposing internal implementations. That's why there are a few differences in what they can detect between Java and Bedrock. In Java, they can detect changes to block states, not just block updates. But Bedrock doesn't have block states (yet?), so Bedrock observers can't detect some of those.

    If you limit yourself to things that observers can detect on both platforms. it's possible to build machines that work pretty much the same on both platforms. There are still some differences, particularly in timing, but logically they can be the same.

    Unfortunately, there are still a lot of old tutorials that use QC, and those will never port to Bedrock. But something you may not realize is that many of them don't port to newer versions of Java, either. With every major update, Java users find themselves having to redesign old machines to work differently. Just like Java users, Bedrock users need to look for recent tutorials first, because many old ones just won't work any more.

     

  • 0
    Registered User commented
    Comment actions Permalink

    I'm not going to lie I don't know what QC connectivity is, however i would like to know if this change would allow an observer to detect when a pumpkin grows through it's stem? I was trying to bring my pumpkin farm to bedrock edition and it didn't function properly.

  • 2
    Registered User commented
    Comment actions Permalink

    But what about making flying machines without QC I can not find a working flying machine on bedrock and they help make heaps of farms that make life easy. 

  • 0
    Registered User commented
    Comment actions Permalink

    Honestly they need to rework pistons to be better then just quasi-connectivity. Keep the pistons the way they are in the game. But add two new pistons. Quasi-less Piston/Sticky Piston that basically is just a piston/sticky piston without quasi-connectivity. And the next piston could be Empowered Piston or Improved Quasi Piston. Where it utilises my pseudo code to that I shared with the redstone enthusiast to make a better quasi-connectivity connection then what we have using if/when/do statements & conditions. Could call it Super_Quasi Piston. Why new pistons instead of overwriting old one in each game? Keep redstone contraptions made working. Plus now combining super_quasi piston/sticky with regular/sticky piston with no quasi piston/sticky could result in a lot of new interesting contraptions & fun. 

    But that was my idea awhile back that never got popular