This was discovered while testing the bug MC-277661. That issue appears to have been fixed in 25w32a (although it's not mentioned in the changelog), and this behavior is occurring instead.
Huh… this is too weird to be WAI.
A possible explanation for this issue is that the both the first creation of the execution context and the as
subcommand did a shallow copy when copying player’s position, which was affected by the subsequent teleportation, but is this really the official opinion of Mojang? It's very strange that the developers would expect the user to understand this distinction between shallow and deep copies that occur internally in each subcommand.
I was a bit confused after reading that report, but I think I understand the difference between these bugs, so let me clarify.
It seems like MC-270134 is describing that set_count function does not allow overstacked items, and my report (MC-277803) is describing that set_components function does not allow overstacked items. The commands in MC-270134 are actually working fine in current release (1.21.3), so the set_count issue is fixed now, but the same issue is still present in set_components function.
I see that changing the order of the functions fixes this as well, but there are cases where you can't change the order, like this command.
/loot give @s loot {pools:[{rolls:1,entries:[{type:loot_table,value:"blocks/redstone_ore",functions:[{function:set_components,components:{max_stack_size:1}}]}]}]}
So I think this could be considered a valid bug.
You can reproduce it with just the commands in the description, the loot tables are defined inline.
Open a singleplayer world with cheats allowed and run the commands in chat. When you run the latter command, you'll see the set_components function fail to apply (expected to get 2 stacks of 32 snowballs, but instead got 4 stacks of 16 snowballs) and the error in the log.
/rotate
command also seems to have this issue. If you run /rotate @s ~30 ~
while riding something, the horizontal rotation is interpolated.
I think this issue should be considered more important than before, especially since the main reason /rotate
was added to the game was to rotate while riding.
Does not occur in 1.21.1. It seems it was fixed somewhere between 1.20.4 and 1.21.1
Also here are the commands for recent versions.
/give @s shield[custom_data={Cap:1b}]
/execute if predicate {condition:entity_properties,entity:this,predicate:{equipment:{mainhand:{predicates:{custom_data:{Cap:1b}}}}}}
Changed the command from 400 armor stands to 1000 item displays, to make the lag more visible.
Also attached a video of reproducing the bug.
Scores still get lost on zombie-drowned conversion. Still not fixed in 24w36a
This issue is different from MCPE-165278. I know that depth-first/breadth-first order can change the logic of a command, but that doesn't explain how the forked branches are changing their execution position even though there is no position-related subcommands. You can see that the commands in my report don't have `at @p`, which means that there is no means to re-capture the player's position.
Additionally, I would like to mention that this does not happen when running from a command block.
It seems that this bug has been fixed. I can't reproduce it in 1.20.5
Uh wait... I apologize, it appears that only the AttributeModifier tag is lost, not the entire item. I wrote them incorrectly at first.
Still happens in 1.19.4. Player now teleports to the correct dimension, but still does not "/spectate" the specified entity. (Also F3+N doesn't work after this teleport. I had to run the /gamemode command myself.)
(Workaround)
This does not occur in predicate's distance detection. Use that instead.
You also interpreted the command after omitting "run execute". I already know why such results come out. What I want to say is that "run execute" should mean something.
The execute-execute command must behave the same as the execute-function-execute command.
Just like the execute-something command works the same as execute-function-something.
It's simmilar.
When I press [Enter] in this moment, "empty text field" is saved.
and it becomes default command block.
[media]
Fixed in 25w32a update.