Observer activating on every other input

Discussion in 'Empire Help & Support' started by CoolNotCold, Jan 26, 2024.

  1. I have a redstone contraption that works just fine, except it only does so the first time, third time, fifth time, etc..
    I can actually place a block on the observer face and it does nothing. When I break the block it will activate.

    I place 11 blocks, at the 11th one the first observer, the one that is acting weird, activates a rsnor latch.
    That rsnor latch activates a line of pistons that move the blocks. A second observer activates more pistons, moving the blocks again.
    A third observer resets the rsnor latch.

    That's it, real simple. For some reason the first observer is only firing every other time.

    Are there some server related redstone changes that are making this happen?
    607 likes this.
  2. I still don't know what the problem was, but I got it working by adding 1 tick of delay to the last observer. It makes no sense, but it fixed it.

    All the last observer does is to reset the rsnor latch. It was already doing that, just 1 tick faster.
    607 likes this.
  3. 607 likes this.
  4. I do have a piston set up like that to get a pulse out of the rsnor latch. Maybe the problem is there. It currently is working, but I will try a different method of producing a pulse and see what results I get.
    607 likes this.
  5. There's no real reason my video fails.
    And my video is from 7 years ago, so isn't an evidence to anything except that weird stuff has always happened in Minecraft.
  6. Sounds like you're describing quasi connectivity, especially with the every other activation pattern. When you update the piston by placing or breaking the block, it'll return to it's proper state.

    As for the weird repeater behavior, that is an very old bug. https://bugs.mojang.com/browse/MC-54711
    607, CoolNotCold and Tuqueque like this.
  7. like yix dit say quesi conectivety
    basicly in the early days of minecraft noch if im correct used a cople lines of code from a door
    for powering the pistons the only problem with that is the door is 2 high and a piston is 1 high this means if u can power a door u can power a piston i tink this also works on dropers and dispensers
    the only problem is if its powered from a weart spot
    u stil need to update the block can be any thing another piston note block
  8. if you come from bedrock, the quasi-connectivity "bug" was patched there when they first released, so always make sure if you are using a redstone tutorial for bedrock vs. java, otherwise it might not work.
  9. we dont call it a bug we call it a feature here lol
    607 likes this.
  10. mm i heart of this like 3 years orso but i never dit tink it wass stil possible
    rails are so fun xd
    we can probely start a discusion on waht are fetures and bugs
    i have a comprimise lets just all call it intended fetures that mojang aded for ther vision of the ideal game not bug
    607 likes this.
  11. That's not an issue, that's how it's supposed to work. :p

    There are several contraptions on my residences that use that feature to filter pulses, usually to filter out pulses of less than 4 gameticks to make sure sticky pistons never lose their block. It's a pretty common circuit to deal with unpredictably timed inputs.

    In short: the reason it works is the torch for the inversion: you might know that a torch (or comparator) doesn't respond to any pulse where the falling edge is before the block event stage of the second tick because of update order. Something similar is going on here: there is a special case in the game code for repeaters and comparators that are pointing into other repeaters of comparators for optimisation reasons. This special case moves the update order to the front, and then again it's this special case that causes the "back on" signal of the repeater powering the last repeater to be too early for it to turn off. I remember Myren Eario talking about this in a video (Probably on Illmago's or PallaPalla's channel), but I cannot find it.

    A basic overview of the underlying mechanics here would probably best be Illmango's redstone basics video on extending pulses without making them take more game ticks (you can see a brief mention of it in this video when he talks about the fact that extended 2-tick pulses are lost when you have two comparitors directly after each other): https://www.youtube.com/watch?v=VjzuJqWAPFQ

    I also remember Illmango using it in this (old) double speed item filter (again to filter out extended 2-tick pulses): https://www.youtube.com/watch?v=XIJX_no8vog

    If you show me the redstone, I'll take a look. If it's quasi, it's an easy fix. But, I like to think I know the redstone mechanics of vanilla well enough for me to know if something is different from it, and how to fix it. :p
    607 likes this.
  12. I don't know redstone. Saying that it was supposed to work that way originally seems bold though. haha. I am in the camp that all redstone quirks are happy little accidents that are just labeled a feature. Not saying anything needs fixed.

    Edit: and again, that the video is from 2016. Before some of those quirks became main staples of Redstone contraptions.
    607 likes this.
  13. "supposed to work" definitely was an overstatement, indeed. :P What I meant to say, is that this is how people who know redstone expect it to work, and, once you get into the world of update order and block event delay and update suppression, this is the only way it makes sense for it would work. I don't think any of that world was intentional, in fact, I believe even sticky pistons dropping their blocks was unintentional, but it's the logical way for these systems to interact once you fully get to know them.

    I'm also pretty sure this behaviour is supported by now. Like, I remember the links of Myren Eario and SpacewalkerRS being in dicord calls with some people from Mojang every time a snapshot broke some redstone fundamentals (usually piston update order), which were usually fixed before the actual update. :p

    Also, I'm pretty sure stuff like this was known in 2016. The Redstone Basics video I linked explaing it is from 16 October 2016. A lot of this has been known since minecraft 1.5, so 2013. I think I know of a door that used it in 1.8 for pulse filtering (a staple record in 4x4 doord It's 10x12x3 in size, that I copied over to my old redstone testing world for studying it), which was 2014. :p
    607 and chickeneer like this.
  14. Yeah, I don't think they are looking to break anything with redstone anytime soon. As long as MC is in 1.XX - it will work the way it does currently, generally. A hypothetical future where a 2.0 Minecraft were to be created and released (say 30 years from now) - then maybe they would look to rewrite redstone to be more "consistent" not riddled by random features that occurred by accident. Such a 2.0 minecraft is impossible for us to conceptualize in my opinion. I think it would be a huge deviation from what we see in Minecraft currently.
    607 and Egeau like this.
  15. to be fair minecraft redstone is not perfect
    but that is waht makes it so cool becouse
    u have normal redstone but pipel also make redstone thats so fast or detectors that use update order of repeters pistons
    and the current problems with the redstone sistem
    is in perfect but its so good becouse its not perfect becouse pipel find ways to use redstone and blocks like that for crazy things and its consistant
    and thats what maters i tink if they would rewrite redstone they would make so many pipel mad and just qeut since milions of piston doors and macines use these weart festures
    607 likes this.