Note that while the report describes an example where multiple execute commands are nested, this also affects single execute commands where one wants to store success and result at the same time, or either of them into multiple targets.
When stacking /execute multiple commands of which more than one has a store subcommand, only one (the last) store actually takes effect. Reproduction steps:
1. Set up a flatworld with no entities except for the player
2. Set up a scoreboard objective and spawn some test entities:
/summon minecraft:armor_stand
/summon minecraft:armor_stand ~ ~ ~ {CustomName:"\"Named\""}
/scoreboard objectives add counter dummy
/scoreboard objectives setdisplay sidebar counter
/scoreboard players set @e counter 10Run the following stacked /execute command which should affect the counter objective for both armor stands and observer that it only updates it for one of the armor stands:
/execute as @e[name=Named] at @s store success score @s counter run execute as @e[distance=..3,name=!Named] store success score @s counter run say hiTo verify that both store}}s work individually, you can take out one of them and run the command this way (after again setting the {{counter objective for all entities to a value not attainable from the command):
/scoreboard players set @e counter 10
/execute as @e[name=Named] at @s store success score @s counter run execute as @e[distance=..3,name=!Named] run say hiand for the other armor stand:
/scoreboard players set @e counter 10
/execute as @e[name=Named] at @s run execute as @e[distance=..3,name=!Named] store success score @s counter run say hiNote that this may also be an issue when leaving out the run execute in the middle, however it is unclear whether repeated subcommands of /execute are intended to not overwrite each other.
Linked issues
is duplicated by 1
Comments 4
Brian McNamara There is a variant of this which is definitely useful and which also doesn't work: you can't chain two `store` subcommands together. For instance, if you try to use `execute store result score @s Result store success score @s Success...`, only the last one will work and the others will be ignored. There's a perfectly legitimate use case for this, too: if you're getting data from a list (array) in an entity or block's NBT tags, there's no way to know how long the list will be. But you can know whether the `data get` command succeeded or not. So storing the success in one score and the result in another can tell you whether the results score was appropriately updated or not.
For instance, inventories have an Items array, but they only store entries for the stacks that exist. There's no way to know in advance how many stacks an inventory will have, so the only way to count the number of items in an inventory is to check every possible list index and add the Count of the ones that exist while ignoring the ones that don't. Without being able to chain `store` subcommands like this, it requires twice as many commands, half of which are just running the same commands an extra time to see if they can be run before actually getting the values. There's no way that's considered invalid.
From a 'user scenario' point of view, I don't think there is a compelling scenario to write two `store`s in a single line of code. So either WontFix or "add a check to make multiple `store`s be a syntax error" are both valid resolutions, in my opinion.