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

Unexpected behavior when using "execute store success score" with a function

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved
    • Resolution: Fixed
    • Affects Version/s: Minecraft 17w50a
    • Fix Version/s: Minecraft 18w06a
    • Labels:
      None
    • Confirmation Status:
      Plausible

      Description

      Not sure if this is intended or not, but I did not expect this:
      With temp1.mcfunction,

      scoreboard players set @s 0x_D 0
      execute store success score @s 0x_D run function library:temp2
      tellraw @a {"score":{"name":"@s","objective":"0x_D"}}
      tellraw @a {"text":""}

      and temp2.mcfunction,

      execute if entity @s[type=!player] run say .
      tellraw @a {"score":{"name":"@s","objective":"0x_D"}}
      tellraw @a {"score":{"name":"@s","objective":"0x_D"}}
      execute if entity @s[type=player] run say .
      tellraw @a {"score":{"name":"@s","objective":"0x_D"}}
      execute if entity @s[scores={0x_D=1}] run say .
      tellraw @a {"score":{"name":"@s","objective":"0x_D"}}

      in namespace "library," with a dummy objective 0x_D, calling temp1 manually as a player produces the following output:

      0
      1
      [player] .
      1
      0
      1

      It seems execute store success score is storing the score for each internal command while the function is still running, which is an isolation problem. The command on line 6 of temp2 should never run—and, if the store part of execute ran after temp2 completed, it wouldn't. If temp2 is called by a player with score 0x_D=0 directly, the output is what would be naïvely expected:

      0
      0
      [player] .
      0
      0

      While the continuous storing may be intended behavior, it's not logical to think that a theoretical function should change its operation depending on how it is called.

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              Ozonified Ozone Smith
            • Votes:
              3 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                CHK: