Uploaded image for project: 'Minecraft: Java Edition'
  1. Minecraft: Java Edition
  2. MC-131805

Observers pulsing after being moved instantly after triggering

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved
    • Resolution: Fixed
    • Affects Version/s: Minecraft 1.13-pre3
    • Fix Version/s: Minecraft 1.13-pre4
    • Labels:
      None
    • Confirmation Status:
      Unconfirmed

      Description

      In 1.13-pre3, MC-126038 got fixed which was a bug that caused some advanced observer machines to break. However, the description of the bugreport was not entirely accurate, which caused the fix to be executed wrongly and not restoring 1.12.2 behavior.

      So, let's look at how observers being pushed in "on" state behave across the versions.

      1.12.2 and below: Observer DOES get moved in powered state. When the piston finished moving, block 36 turns into a (powered) observer block again. However, placing a powered observer in 1.12.2 causes it to immediately call the updateTick()-Method (MCP9.30 names), which causes the observer after it has been readded in powered state to be updated instantly and turn off, before any updates have been caused by the observer. The block updates happen after the observer turned off again. Therefore, no redstone contraptions will get triggered.
      Additionally, the onBlockPlaced()- method calls the startSignal()-method afterwards. That is what is causing the observer to blink after it has been placed and when being pushed by a piston in its "off"-state. However, this method does nothing, when the observer is already in its powered state. If we move a powered observer in 1.12.2, it will get placed in its on state and therefore, the startSignal()-method will not schedule a TileTick
      To summarize:

      1. Observer gets moved in on-state
      2. Observer is placed in on-state after movement
      3. Because of that, observer calls updateTick() which causes it to turn off immidiately
      4. Additionally, no TileTick gets scheduled, causing it to not pulse after placement
      5. Updates are caused after that happened and the onBlockAdded()- method did finish

      Recent Snapshots until 1.13-pre2: Observer still gets moved in powered state, however now at least some updates get processed before the observer turns off. Notice that in the contraption from the bugreport, only the piston on the left extends, but not the one ontop of it.
      The startSignal()-method still does nothing, this is the same as 1.12.2

      1. Observer gets moved in on-state
      2. Observer is placed in on-state after movement
      3. Observer causes updates, triggering redstone stuff. This is likely a regular block update, since contraptions do not get powered through a solid block. This did not happen at this place in 1.12.2
      4. After updates have been caused, observer calls the updateTick()-method, causing it to turn off
      5. Additionally, no TileTick gets scheduled, causing it to not pulse after placement and initial powering

      1.13-pre3: Now the observer doesn't get moved in powered state, but is forced into its unpowered state. That means, that the piston now, unlike 1.12.2, already places an unpowered observer.
      However, now the startSignal()-Method does schedule a TileTick, because the observer was placed in its unpowered state.
      That means, after the observer is ticked again, it will now, unlike 1.12, emit a signal, causing it to be moved over again. The observer will appear in its off state the entire time, because it gets moved instantly and thus forced into off state, after it emits a signal.

      1. Observer gets moved in off-state
      2. Observer is placed in off-state after movement
      3. Observer causes updates, triggering redstone stuff. Since it was moved in off state, that now has no effect, similar to 1.12
      4. After updates have been caused, observer does not call the updateTick()-Method, because it is not in powered state.
      5. Since the observer was moved in unpowered state, a TileTick gets scheduled, causing it to pulse after placement. This is completely different from 1.12.2. We now have the same issue as before, just caused by the observer being moved in unpowered state.

      If this change could be reverted to what it was in 1.12.2, that would be pretty cool since it allows observers to be moved without powering anything, which can be quite a useful feature.

      A video that shows the difference by WARBEN: https://youtu.be/60eZJZVniZ8

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                grum [Mojang] Grum (Erik Broes)
                Reporter:
                Schortan [Helper] NeunEinser
              • Votes:
                2 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: