mojira.dev
MC-123628

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

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.

Comments 2

Seems to have been fixed as of 18w01a; "result" may still be odd, but "success" seems properly isolated.

I totally missed your comment; I resolved this ticket with fix version 18w06a now, because 18w01a has been archived.

Ozone Smith

(Unassigned)

Plausible

Minecraft 17w50a

Minecraft 18w06a

Retrieved