The bug
Selector arguments which select entities based on their position fail finding them if they have been moved to a different chunk in the same tick. Moving the entity to the next chunk might not always cause this bug since the initial entity search area can be larger than the specified values.
The root cause is likely MC-108469 because at least in 1.12.2 selectors get the entities to check from the respective chunks and if the entity lists have not been updated the entities will not be found.
Note: This does not affect the @s
selector.
Affected selector arguments
Last updated for 17w50a
distance
dx
dy
dz
How to reproduce
Place an impulse command block with the following command
/execute as @e[type=armor_stand] at @s run teleport @s ~33 ~ ~
Place an always active chain command block with the following command behind it
/execute as @e[type=armor_stand] at @s run say @e[distance=0]
Place an armor stand
Power the impulse command block
→ ❌ It fails finding itself
Linked issues
is duplicated by 2
relates to 1
Attachments
Comments 30
It's because entities don't run commands in unloaded chunks; this has nothing to do with the chain command block's functionality.
It's that you're teleporting the entity in a unloaded chunk. Now, it might seem like it works when you're near the command blocks and run the commands, which is because you loaded the entity for a few seconds or less allowing the commands to be executed. You'll need to load the chunk first before teleporting the entity to that location in order for it to work even though you're far from the command blocks.
@Logical_Cyclops No that is not true. Both the chunk that the entity starts in and the chunk it get's teleportet to are loaded. As I stated in the Description even a distance of two chunks is to much.
By the way this also affects Players (wich is the actual use case for me) and I would think that Players should always be loaded.
Attached a datapack. I can reliably reproduce this with the following steps, however I am not sure if this is a new related bug or the same bug.
Summon one 'selected' stand and a few extra stands at your position with /function teleport_position_bug:summon
Move yourself an arbitrary distance, or /tp ~32 ~ ~
Run the following function to teleport the 'selected' stand to you, then teleport all stands to it, and print out whether it found any armor stands within 1 block of it /function teleport_position_bug:move
If the output is 'NO OUTPUT' the selected stand found no other stands in 1 block. You will notice that the armor stands are indeed all teleported to the stand, thus the bug has been reproduced.
If the output is 'ENTITY FOUND' the other stands were found. Repeat and/or change the distance you move.
This can be reproduced additionally if you do the following method:
Summon a moving pig /summon pig ~ ~ ~ {Motion:[0.0d,5.0d,0.0d]}
Spam this command to see both 'NO OUTPUT' and 'ENTITY FOUND' at different intervals of the pig's flight /execute as @e[type=pig] at @s run function teleport_position_bug:move
This bug is circumvented if you do the following:
Repeat the original steps, but in step 3 use /function teleport_position_bug:move_from_stand
This will summon a stand at your position, then run the move function, then kill the original stand. Somehow when there is not a direct teleport to an existing entity, this bug is circumvented
Correction on the previous comments: This bug looks like it has been fixed. In 1.16.4 this bug was present, however in 20w45a it was fixed. This is very likely due to the resolution of MC-108469. I cannot reproduce this bug anymore from 20w45a onwards using my provided datapack.
I highly doubt this has to do with my computer, but to be sure it would be nice if someone could confirm this.