MC-124171Functions not running in single tick
It seems as though functions and other things are happening in a strange order compared to 1.12.
If I had a function that had 2 commands in it:
/execute as @e[type=item,tag=] at @s run setblock ~1 ~ ~ air destroy
/execute as @e[type=item,tag=] at @s run data merge entity @s {Tags:["Tagged"]}
Both the entity that currently is on the ground and the one just broken get a tag, and if this is run again the chain no longer continues.
Expected Behavior:
Only the first entity is given a tag, than the function finished and the item is created, allowing the next item to run the execute command.
Environment
Windows 10
Attachments1
Created Issue:
Functions not running in single tick
It seems as though functions and other things are happening in a strange order compared to 1.12.
If I had a function that had 2 commands in it:
{Tags:["Tagged"]}
/execute as @e[type=item,tag=] at @s run setblock ~1 ~ ~ air destroy
/execute as @e[type=item,tag=] at @s run data merge entity @sBoth the entity that currently is on the ground and the one just broken get a tag, and if this is run again the chain no longer continues.
Expected Behavior:
Only the first entity is given a tag, than the function finished and the item is created, allowing the next item to run the execute command.Environment
Windows 10
![[Mod] Skylinerw](../../../data/assets/gravatar/skylinerw.png){kind=small}
![[Bot] Arisa](../../../data/assets/gravatar/mustek2.png){kind=small}
![[Mod] violine1101](../../../data/avatars/users/92858.png){kind=small}
It seems as though functions and other things are happening in a strange order compared to 1.12.
If I had a function that had 2 commands in it:
{Tags:["Tagged"]}
/execute as @e[type=item,tag=] at @s run setblock ~1 ~ ~ air destroy
/execute as @e[type=item,tag=] at @s run data merge entity @sBoth the entity that currently is on the ground and the one just broken get a tag, and if this is run again the chain no longer continues.
Expected Behavior:
Only the first entity is given a tag, than the function finished and the item is created, allowing the next item to run the execute command.It seems as though functions and other things are happening in a strange order compared to 1.12.
If I had a function that had 2 commands in it:
/execute as @e[type=item,tag=] at @s run setblock ~1 ~ ~ air destroy /execute as @e[type=item,tag=] at @s run data merge entity @s {Tags:["Tagged"]}Both the entity that currently is on the ground and the one just broken get a tag, and if this is run again the chain no longer continues.
Expected Behavior:
Only the first entity is given a tag, than the function finished and the item is created, allowing the next item to run the execute command.
![[Mod] tryashtar](../../../data/avatars/users/41963.png){kind=small}
I don't see the issue here; the item is created instantly after the setblock command is run, then it's tagged by the second command.
That's the problem... That wasn't happening in the previous snapshot/1.12.
If an item is on the ground, than there is a really long line of stone stretching in the X direction, that setblock, tag item, repeat chain stops if the item currently on the ground and the one created by the /setblock are both being tagged. They weren't both previously getting tagged, only the one already on the ground.
Please provide the commands you were using in 1.12.
This is the function I am currently using in 1.13.
execute as @a[scores={treecap7=1..}] at @s at @e[type=item,distance=..40,tag=] if block ~-1 ~ ~-1 #minecraft:logs run setblock ~-1 ~ ~-1 air destroy execute as @a[scores={treecap7=1..}] at @s at @e[type=item,distance=..40,tag=] if block ~ ~ ~-1 #minecraft:logs run setblock ~ ~ ~-1 air destroy execute as @a[scores={treecap7=1..}] at @s at @e[type=item,distance=..40,tag=] if block ~1 ~ ~-1 #minecraft:logs run setblock ~1 ~ ~-1 air destroy execute as @a[scores={treecap7=1..}] at @s at @e[type=item,distance=..40,tag=] if block ~-1 ~ ~ #minecraft:logs run setblock ~-1 ~ ~ air destroy execute as @a[scores={treecap7=1..}] at @s at @e[type=item,distance=..40,tag=] if block ~1 ~ ~ #minecraft:logs run setblock ~1 ~ ~ air destroy execute as @a[scores={treecap7=1..}] at @s at @e[type=item,distance=..40,tag=] if block ~-1 ~ ~1 #minecraft:logs run setblock ~-1 ~ ~1 air destroy execute as @a[scores={treecap7=1..}] at @s at @e[type=item,distance=..40,tag=] if block ~ ~ ~1 #minecraft:logs run setblock ~ ~ ~1 air destroy execute as @a[scores={treecap7=1..}] at @s at @e[type=item,distance=..40,tag=] if block ~1 ~ ~1 #minecraft:logs run setblock ~1 ~ ~1 air destroy execute as @a[scores={treecap7=1..}] at @s at @e[type=item,distance=..40,tag=] if block ~-1 ~1 ~-1 #minecraft:logs run setblock ~-1 ~1 ~-1 air destroy execute as @a[scores={treecap7=1..}] at @s at @e[type=item,distance=..40,tag=] if block ~ ~1 ~-1 #minecraft:logs run setblock ~ ~1 ~-1 air destroy execute as @a[scores={treecap7=1..}] at @s at @e[type=item,distance=..40,tag=] if block ~1 ~1 ~-1 #minecraft:logs run setblock ~1 ~1 ~-1 air destroy execute as @a[scores={treecap7=1..}] at @s at @e[type=item,distance=..40,tag=] if block ~-1 ~1 ~ #minecraft:logs run setblock ~-1 ~1 ~ air destroy execute as @a[scores={treecap7=1..}] at @s at @e[type=item,distance=..40,tag=] if block ~ ~1 ~ #minecraft:logs run setblock ~ ~1 ~ air destroy execute as @a[scores={treecap7=1..}] at @s at @e[type=item,distance=..40,tag=] if block ~1 ~1 ~ #minecraft:logs run setblock ~1 ~1 ~ air destroy execute as @a[scores={treecap7=1..}] at @s at @e[type=item,distance=..40,tag=] if block ~-1 ~1 ~1 #minecraft:logs run setblock ~-1 ~1 ~1 air destroy execute as @a[scores={treecap7=1..}] at @s at @e[type=item,distance=..40,tag=] if block ~ ~1 ~1 #minecraft:logs run setblock ~ ~1 ~1 air destroy execute as @a[scores={treecap7=1..}] at @s at @e[type=item,distance=..40,tag=] if block ~1 ~1 ~1 #minecraft:logs run setblock ~1 ~1 ~1 air destroy execute as @e[type=item,tag=] at @s run tag @s add Treecap7 scoreboard players set @a[scores={treecap7=1..}] treecap7 0Run down as to what this does to a normal oak tree:
Break the bottom of a tree. That turns into an item. That item than executes a setblock command above it to destroy the log above it, then is given a tag so the command isn't run on that entity again. The item that is created from the breaking of the log is also being given a tag however, which I don't believe it was doing previously.
For the example of a normal oak tree (and for simplicity), executing the function with these commands:
execute as @a[scores={treecap7=1..}] at @s at @e[type=item,distance=..40,tag=] if block ~ ~1 ~ #minecraft:logs run setblock ~ ~1 ~ air destroy execute as @e[type=item,tag=] at @s run tag @s add Treecap7 scoreboard players set @a[scores={treecap7=1..}] treecap7 0causes both items to be tagged. My only guess is that /setblock ... destroy wasn't creating the item in the same tick that the command was executed in in 1.12. That issue seems to be fixed now, but the behavior you want/expect it to have isn't the behavior that it should have. Just because something used to work and doesn't work now does not necessarily mean that the new behavior is bugged and the old behavior was normal.
execute as @a[scores={treecap7=1..}] at @s at @e[type=item,distance=..40,tag=] if block ~ ~1 ~ #minecraft:logs run setblock ~ ~1 ~ air destroyThis command destroys the log block above an item, creating a new item within the same tick. Then,
will tag both items with the Treecap7 tag, again in the same tick. Can you explain why it is bugged behavior if the second item gets tagged when that item was created before the tag command was executed?
Since the current behavior seems to be the normal, expected outcome, try making this change to your function:
Add this at the beginning of the function:
Then change
to:
and add this command right after:
and finally change the tag= in each setblock command to tag=Active.
There is a simpler way to achieve the same result that involves splitting this into two functions and running the first function only once, but this method works for what you need. Tested both your original function and my updated one in 18w05a. The new function removes blocks up to the top of the tree, the old function destroys one block, tags both items, then seizes to function. This is likely the intentional behavior given the order and setup of the commands in the function. Also, because each subsequent setblock ... destroy command you have executes at an item, and each command creates a new item upon success, an unintentional spread of blocks getting destroyed occurs (the number of items roughly increases at an exponential rate). Depending on how thick the tree is, your function might work the way you intended, but something like a normal oak tree causes it to fail. I will attach a screenshot that demonstrates what these functions do to the first layer of logs (the first half of the function) when executed once. You can imagine how the second half of the function will affect the vertical spread of destroying blocks, since none of the items have been tagged yet. If you have any questions then ask away.