MC-89667Position based selector arguments fail finding entity if it has been moved to a different chunk in the same tick
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 by2
Created Issue:
Chain command selectors don't work correctly when teleporting an entity to a different chunk
When an entity gets teleported to a different chunk (sometimes 1 chunk distance is not enough), selectors that use an r argument will not find that entity correctly if they are triggerd afterwards in a chain.
This can be easily observed with this setup:
Commands (first is an impulse, second one is a chain command that is always active):
/tp @e[type=ArmorStand] 500 50 500 (absolute coordinates near the commandblock)
/execute @e[type=ArmorStand] ~ ~ ~ /execute @e[r=0] ~ ~ ~ /say hiIf you now summon an ArmorStand near your commandblocks (in the same chunk), everything works as expected. The ArmorStand teleports and sais hi.
If you fly a chunk or two away and execute the commands, the ArmorStand still gets telepoted, but there is no Chat output anymore.
The ArmorStand is no longer within a radius 0 of itself.From testing it does have to do with the chunkboarder, but in rare occasions one chunk distance still works fine.
This is not a problem with /execute. The /testfor command has the same issue and I would guess any other commands as well.
The same problem occurs when telepoting an entity to another entity instead of absolute coordinates.
This might seem like a very special problem, but because of this every command block system that teleports entitys (and uses chain command blocks) might possibly just not work!
Environment
System.getProperty('os.name') == 'Windows 7'
System.getProperty('os.version') == '6.1'
System.getProperty('os.arch') == 'amd64'
System.getProperty('java.version') == '1.8.0_45'
System.getProperty('java.vendor') == 'Oracle Corporation'
System.getProperty('sun.arch.data.model') == '64'
relates to
System.getProperty('os.name') == 'Windows 7'
System.getProperty('os.version') == '6.1'
System.getProperty('os.arch') == 'amd64'
System.getProperty('java.version') == '1.8.0_45'
System.getProperty('java.vendor') == 'Oracle Corporation'
System.getProperty('sun.arch.data.model') == '64''os.name' = 'Windows 7'
'os.version' = '6.1'
'os.arch' = 'amd64'
'java.version' = '1.8.0_45'
'java.vendor' = 'Oracle Corporation'
'sun.arch.data.model' = '64'
When an entity gets teleported to a different chunk (sometimes 1 chunk distance is not enough), selectors that use an r argument will not find that entity correctly if they are triggerd afterwards in a chain.
This can
beeasily observed with this setup:Commands (first is an impulse, second one is a chain command that is always active):
/tp @e[type=ArmorStand] 500 50 500 (absolute coordinates near the commandblock)
/execute @e[type=ArmorStand] ~ ~ ~ /execute @e[r=0] ~ ~ ~ /say hiIf you now summon an Armor
Stand near your commandblocks (in the same chunk), everything works as expected. The ArmorStand teleports and sais hi.If you
flya chunk or two away and execute the commands, the ArmorStand still gets telepoted, but there is noChat output anymore.
The ArmorStand isno longer within a radius 0 of itself.From testing it does have to do with the chunkboarder, but in rare occasions one chunk distance still works fine.
This is not a problem with /execute. The /testfor command has the same issue and I would guess any other commands as well.
The same problem occurs when telepoting an entity to another entity instead of absolute coordinates.
This might seem like a very special problem, but because of this every command block system that teleports entitys (and uses chain command blocks) might possibly just not work!
When an entity gets teleported to a different chunk (sometimes 1 chunk distance is not enough), selectors that use an r argument will not find that entity correctly if they are triggerd afterwards in a chain.
This can easily be observed with this setup:
Commands (first is an impulse, second one is a chain command that is always active):
- /tp @e[type=armor_stand] 500 50 500 (absolute coordinates near the commandblock)
- /execute @e[type=armor_stand] ~ ~ ~ /execute @e[r=0] ~ ~ ~ /say hi
If you now summon an Armorstand near your commandblocks (in the same chunk), everything works as expected. The Armorstand teleports and sais hi.
If you summon in a chunk or two away and execute the commands, the Armorstand still gets teleported, but there is no chat output anymore -> The Armorstand is no longer within a radius 0 of itself.
This is not special to r=0, if the Armorstand is teleported more than one block r=1 fails too.
From testing it does have to do with the chunkboarder, but in rare occasions one chunk distance still works fine.
This is not a problem with /execute. The /testfor command has the same issue and I would guess any other commands as well.
The same problem occurs when telepoting an entity to another entity instead of absolute coordinates.
This might seem like a very special problem, but because of this every command block system that teleports entitys (and uses chain command blocks) might possibly just not work!Relevance of chunk borders
It seems that if the radius is large enough to touch a chunk border (actually 1 block less than enough to touch a chunk border) from the target position the next chunk behind that border behaves correctly. This would explain the fact that "sometimes 1 chunk distance is not enough".
This can be observed by choosing target coordinates that are right next to a chunkborder.The following experiments used the target coordinates 0 56 0 wich is right next to a chunkborder (The position of the commandblocks dos not seem to matter) and were executed using 1.11.
First command: /tp @e[type=armor_stand] 0 56 0Experiment #1:
- Place the Armorstand at 0.5 56 -15.5 (16 blocks / 1 chunk away from the target coordinates)
- Use a radius of 0: /execute @e[type=armor_stand] ~ ~ ~ /execute @e[r=0] ~ ~ ~ /say hi
Result: Armorstand is found
Experiment #3:
- Place the Armorstand at 0.5 56 -16.5 (17 blocks / 2 chunk away from the target coordinates)
- Use a radius of 14: /execute @e[type=armor_stand] ~ ~ ~ /execute @e[r=14] ~ ~ ~ /say hi
Result: Armorstand is not found
Experiment #3:
- Place the Armorstand at 0.5 56 -16.5 (17 blocks / 2 chunk away from the target coordinates)
- Use a radius of 15: /execute @e[type=armor_stand] ~ ~ ~ /execute @e[r=15] ~ ~ ~ /say hi
Result: Armorstand is found
When an entity gets teleported to a different chunk (sometimes 1 chunk distance is not enough), selectors that use an r argument will not find that entity correctly if they are triggerd afterwards in a chain.
This can easily be observed with this setup:
Commands (first is an impulse, second one is a chain command that is always active):
- /tp @e[type=armor_stand] 500 50 500 (absolute coordinates near the commandblock)
- /execute @e[type=armor_stand] ~ ~ ~ /execute @e[r=0] ~ ~ ~ /say hi
If you now summon an Armorstand near your commandblocks (in the same chunk), everything works as expected. The Armorstand teleports and sais hi.
If you summon in a chunk or two away and execute the commands, the Armorstand still gets teleported, but there is no chat output anymore -> The Armorstand is no longer within a radius 0 of itself.
This is not special to r=0, if the Armorstand is teleported more than one block r=1 fails too.
From testing it does have to do with the chunkboarder, but in rare occasions one chunk distance still works fine.
This is not a problem with /execute. The /testfor command has the same issue and I would guess any other commands as well.
The same problem occurs when telepoting an entity to another entity instead of absolute coordinates.
This might seem like a very special problem, but because of this every command block system that teleports entitys (and uses chain command blocks) might possibly just not work!Relevance of chunk borders
It seems that if the radius is large enough to touch a chunk border (actually 1 block less than enough to touch a chunk border) from the target position the next chunk behind that border behaves correctly. This would explain the fact that "sometimes 1 chunk distance is not enough".
This can be observed by choosing target coordinates that are right next to a chunkborder.The following experiments used the target coordinates 0 56 0 wich is right next to a chunkborder (The position of the commandblocks dos not seem to matter) and were executed using 1.11.
First command: /tp @e[type=armor_stand] 0 56 0Experiment #1:
- Place the Armorstand at 0.5 56 -15.5 (16 blocks / 1 chunk away from the target coordinates)
- Use a radius of 0: /execute @e[type=armor_stand] ~ ~ ~ /execute @e[r=0] ~ ~ ~ /say hi
Result: Armorstand is found
Experiment #
3:
- Place the Armorstand at 0.5 56 -16.5 (17 blocks / 2 chunk away from the target coordinates)
- Use a radius of 14: /execute @e[type=armor_stand] ~ ~ ~ /execute @e[r=14] ~ ~ ~ /say hi
Result: Armorstand is not found
Experiment #3:
- Place the Armorstand at 0.5 56 -16.5 (17 blocks / 2 chunk away from the target coordinates)
- Use a radius of 15: /execute @e[type=armor_stand] ~ ~ ~ /execute @e[r=15] ~ ~ ~ /say hi
Result: Armorstand is found
When an entity gets teleported to a different chunk (sometimes 1 chunk distance is not enough), selectors that use an r argument will not find that entity correctly if they are triggerd afterwards in a chain.
This can easily be observed with this setup:
Commands (first is an impulse, second one is a chain command that is always active):
- /tp @e[type=armor_stand] 500 50 500 (absolute coordinates near the commandblock)
- /execute @e[type=armor_stand] ~ ~ ~ /execute @e[r=0] ~ ~ ~ /say hi
If you now summon an Armorstand near your commandblocks (in the same chunk), everything works as expected. The Armorstand teleports and sais hi.
If you summon in a chunk or two away and execute the commands, the Armorstand still gets teleported, but there is no chat output anymore -> The Armorstand is no longer within a radius 0 of itself.
This is not special to r=0, if the Armorstand is teleported more than one block r=1 fails too.
From testing it does have to do with the chunkboarder, but in rare occasions one chunk distance still works fine.
This is not a problem with /execute. The /testfor command has the same issue and I would guess any other commands as well.
The same problem occurs when telepoting an entity to another entity instead of absolute coordinates.
This might seem like a very special problem, but because of this every command block system that teleports entitys (and uses chain command blocks) might possibly just not work!Relevance of chunk borders
It seems that if the radius is large enough to touch a chunk border (actually 1 block less than enough to touch a chunk border) from the target position the next chunk behind that border behaves correctly. This would explain the fact that "sometimes 1 chunk distance is not enough".
This can be observed by choosing target coordinates that are right next to a chunkborder.The following experiments used the target coordinates 0 56 0 wich is right next to a chunkborder (The position of the commandblocks dos not seem to matter) and were executed using 1.11.
First command: /tp @e[type=armor_stand] 0 56 0Experiment #1:
- Place the Armorstand at 0.5 56 -15.5 (16 blocks / 1 chunk away from the target coordinates)
- Use a radius of 0: /execute @e[type=armor_stand] ~ ~ ~ /execute @e[r=0] ~ ~ ~ /say hi
Result: Armorstand is found
Experiment #2:
- Place the Armorstand at 0.5 56 -16.5 (17 blocks / 2 chunk away from the target coordinates)
- Use a radius of 14: /execute @e[type=armor_stand] ~ ~ ~ /execute @e[r=14] ~ ~ ~ /say hi
Result: Armorstand is not found
Experiment #3:
- Place the Armorstand at 0.5 56 -16.5 (17 blocks / 2 chunk away from the target coordinates)
- Use a radius of 15: /execute @e[type=armor_stand] ~ ~ ~ /execute @e[r=15] ~ ~ ~ /say hi
Result: Armorstand is found
When an entity gets teleported to a different chunk (sometimes 1 chunk distance is not enough), selectors that use an r argument will not find that entity correctly if they are triggerd afterwards in a chain.
This can easily be observed with this setup:
Commands (first is an impulse, second one is a chain command that is always active):
- /tp @e[type=armor_stand] 500 50 500 (absolute coordinates near the commandblock)
- /execute @e[type=armor_stand] ~ ~ ~ /execute @e[r=0] ~ ~ ~ /say hi
If you now summon an Armorstand near your commandblocks (in the same chunk), everything works as expected. The Armorstand teleports and sais hi.
If you summon in a chunk or two away and execute the commands, the Armorstand still gets teleported, but there is no chat output anymore -> The Armorstand is no longer within a radius 0 of itself.
This is not special to r=0, if the Armorstand is teleported more than one block r=1 fails too.
From testing it does have to do with the chunkboarder, but in rare occasions one chunk distance still works fine.
This is not a problem with /execute. The /testfor command has the same issue and I would guess any other commands as well.
The same problem occurs when telepoting an entity to another entity instead of absolute coordinates.
This might seem like a very special problem, but because of this every command block system that teleports entitys (and uses chain command blocks) might possibly just not work!Relevance of chunk borders
It seems that if the radius is large enough to touch a chunk border (actually 1 block less than enough to touch a chunk border) from the target position the next chunk behind that border behaves correctly. This would explain the fact that "sometimes 1 chunk distance is not enough".
This can be observed by choosing target coordinates that are right next to a chunkborder.The following experiments used the target coordinates 0 56 0 wich is right next to a chunkborder (The position of the commandblocks dos not seem to matter) and were executed using 1.11.
First command: /tp @e[type=armor_stand] 0 56 0Here is a video showing this bug: https://www.youtube.com/watch?v=ls03ofiNTSA
Experiment #1:
- Place the Armorstand at 0.5 56 -15.5 (16 blocks / 1 chunk away from the target coordinates)
- Use a radius of 0: /execute @e[type=armor_stand] ~ ~ ~ /execute @e[r=0] ~ ~ ~ /say hi
Result: Armorstand is found
Experiment #2:
- Place the Armorstand at 0.5 56 -16.5 (17 blocks / 2 chunk away from the target coordinates)
- Use a radius of 14: /execute @e[type=armor_stand] ~ ~ ~ /execute @e[r=14] ~ ~ ~ /say hi
Result: Armorstand is not found
Experiment #3:
- Place the Armorstand at 0.5 56 -16.5 (17 blocks / 2 chunk away from the target coordinates)
- Use a radius of 15: /execute @e[type=armor_stand] ~ ~ ~ /execute @e[r=15] ~ ~ ~ /say hi
Result: Armorstand is found
relates to
![[Mod] Michael Wobst](../../../data/avatars/users/37868.png){kind=small}
When an entity gets teleported to a different chunk (sometimes 1 chunk distance is not enough), selectors that use an r argument will not find that entity correctly if they are triggerd afterwards in a chain.
This can easily be observed with this setup:
Commands (firstis animpulse, second one is a chain command that is always active):
- /tp @e[type=armor_stand] 500 50 500 (absolute coordinates near the commandblock)
- /execute @e[type=armor_stand] ~ ~ ~ /execute @e[r=0] ~ ~ ~ /say hi
If you now summon an Armorstand near your commandblocks (in the same chunk), everything works as expected. The Armorstand teleports and sais hi.
If you summon in a chunk or two away and execute the commands, the Armor
stand still gets teleported, but there is no chat output anymore -> The Armorstand is no longer within a radius 0 of itself.This is not special to r=0, if the Armorstand is teleported more than one blockr=1 fails too.
From testing it does have to do with the chunkboarder, but in rare occasions one chunk distance still works fine.This is not a problem with /execute. The /testforcommand has the same issue and I would guess any other commands as well.
The same problem occurs when telepoting an entity to another entity instead of absolute coordinates.
This might seem like a very special problem, but because of this every command block system that teleports entitys (and uses chain command blocks) might possibly just not work!Relevance of chunk borders
It seems that if the radius is large enough to touch a chunk border (actually 1 block less than enough to touch a chunk border) from the target position the next chunk behind that border behaves correctly. This would explain the fact that "sometimes 1 chunk distance is not enough".
This can be observed by choosing target coordinates that are right next to a chunkborder.The following experiments used the target coordinates 0 56 0 wich is right next to a chunkborder (The position of the commandblocks dos not seem to matter) and were executed using 1.11.
First command: /tp @e[type=armor_stand] 0 56 0Here is a video showing this bug: https://www.youtube.com/watch?v=ls03ofiNTSA
Experiment #1:
- Place the Armor
stand at 0.5 56 -15.5 (16 blocks / 1 chunk away from the target coordinates)- Use a radius of 0: /execute @e[type=armor_stand] ~ ~ ~ /execute @e[r=0] ~ ~ ~ /say hi
Result: Armor
stand is foundExperiment #2:
- Place the Armor
stand at 0.5 56 -16.5 (17 blocks / 2 chunk away from the target coordinates)- Use a radius of 14: /execute @e[type=armor_stand] ~ ~ ~ /execute @e[r=14] ~ ~ ~ /say hi
Result: Armor
stand is not foundExperiment #3:
- Place the Armor
stand at 0.5 56 -16.5 (17 blocks / 2 chunk away from the target coordinates)- Use a radius of 15: /execute @e[type=armor_stand] ~ ~ ~ /execute @e[r=15] ~ ~ ~ /say hi
Result: Armor
stand is foundWhen an entity gets teleported to a different chunk (sometimes 1 chunk distance is not enough), selectors that use an r argument will not find that entity correctly if they are triggered afterwards in a chain.
This can easily be observed with this setup:
Commands (first is an impulse, second one is a chain command that is always active):
- /tp @e[type=armor_stand] 500 50 500 (absolute coordinates near the command block)
- /execute @e[type=armor_stand] ~ ~ ~ /execute @e[r=0] ~ ~ ~ /say hi
If you now summon an Armor Stand near your Command Blocks (in the same chunk), everything works as expected. The Armor Stand teleports and says hi.
If you summon in a chunk or two away and execute the commands, the Armor Stand still gets teleported, but there is no chat output anymore -> The Armor Stand is no longer within a radius 0 of itself.
This is not special to r=0, if the Armor Stand is teleported more than one block r=1 fails too.
From testing it does have to do with the chunk border, but in rare occasions one chunk distance still works fine.
This is not a problem with /execute. The /testfor command has the same issue and I would guess any other commands as well.
The same problem occurs when teleporting an entity to another entity instead of absolute coordinates.
This might seem like a very special problem, but because of this every command block system that teleports entities (and uses chain command blocks) might possibly just not work!Relevance of chunk borders
It seems that if the radius is large enough to touch a chunk border (actually 1 block less than enough to touch a chunk border) from the target position the next chunk behind that border behaves correctly. This would explain the fact that "sometimes 1 chunk distance is not enough".
This can be observed by choosing target coordinates that are right next to a chunk border.The following experiments used the target coordinates 0 56 0 which is right next to a chunk border (The position of the command blocks does not seem to matter) and were executed using 1.11.
First command: /tp @e[type=armor_stand] 0 56 0Here is a video showing this bug: https://www.youtube.com/watch?v=ls03ofiNTSA
Experiment #1:
- Place the Armor Stand at 0.5 56 -15.5 (16 blocks / 1 chunk away from the target coordinates)
- Use a radius of 0: /execute @e[type=armor_stand] ~ ~ ~ /execute @e[r=0] ~ ~ ~ /say hi
Result: Armor Stand is found
Experiment #2:
- Place the Armor Stand at 0.5 56 -16.5 (17 blocks / 2 chunk away from the target coordinates)
- Use a radius of 14: /execute @e[type=armor_stand] ~ ~ ~ /execute @e[r=14] ~ ~ ~ /say hi
Result: Armor Stand is not found
Experiment #3:
- Place the Armor Stand at 0.5 56 -16.5 (17 blocks / 2 chunk away from the target coordinates)
- Use a radius of 15: /execute @e[type=armor_stand] ~ ~ ~ /execute @e[r=15] ~ ~ ~ /say hi
Result: Armor Stand is found
When an entity gets teleported to a different chunk (sometimes 1 chunk distance is not enough), selectors that use an r argument will not find that entity correctly if they are triggered afterwards in a chain.
This can easily be observed with this setup:
Commands (first is an impulse, second one is a chain command that is always active):
- /tp @e[type=armor_stand] 500 50 500 (absolute coordinates near the command block)
- /execute @e[type=armor_stand] ~ ~ ~ /execute @e[r=0] ~ ~ ~ /say hi
If you now summon an Armor Stand near your Command Blocks (in the same chunk), everything works as expected. The Armor Stand teleports and says hi.
If you summon in a chunk or two away and execute the commands, the Armor Stand still gets teleported, but there is no chat output anymore -> The Armor Stand is no longer within a radius 0 of itself.
This is not special to r=0, if the Armor Stand is teleported more than one block r=1 fails too.
From testing it does have to do with the chunk border, but in rare occasions one chunk distance still works fine.
This is not a problem with/execute. The/testforcommand has the same issue and I would guess any other commands as well.
The same problem occurs when teleporting an entity to another entity instead of absolute coordinates.
This might seem like a very special problem, but because of this every command block system that teleports entities (and uses chain command blocks) might possibly just not work!Relevance of chunk borders
It seems that if the radius is large enough to touch a chunk border (actually 1 block less than enough to touch a chunk border) from the target position the next chunk behind that border behaves correctly. This would explain the fact that "sometimes 1 chunk distance is not enough".
This can be observed by choosing target coordinates that are right next to a chunk border.The following experiments used the target coordinates 0 56 0 which is right next to a chunk border (The position of the command blocks does not seem to matter) and were executed using 1.11.
First command: /tp @e[type=armor_stand] 0 56 0Here is a video showing this bug: https://www.youtube.com/watch?v=ls03ofiNTSA
Experiment #1:
- Place the Armor Stand at 0.5 56 -15.5 (16 blocks / 1 chunk away from the target coordinates)
- Use a radius of 0: /execute @e[type=armor_stand] ~ ~ ~ /execute @e[r=0] ~ ~ ~ /say hi
Result: Armor Stand is found
Experiment #2:
- Place the Armor Stand at 0.5 56 -16.5 (17 blocks / 2 chunk away from the target coordinates)
- Use a radius of 14: /execute @e[type=armor_stand] ~ ~ ~ /execute @e[r=14] ~ ~ ~ /say hi
Result: Armor Stand is not found
Experiment #3:
- Place the Armor Stand at 0.5 56 -16.5 (17 blocks / 2 chunk away from the target coordinates)
- Use a radius of 15: /execute @e[type=armor_stand] ~ ~ ~ /execute @e[r=15] ~ ~ ~ /say hi
Result: Armor Stand is found
When an entity gets teleported to a different chunk (sometimes 1 chunk distance is not enough), selectors that use an r argument will not find that entity correctly if they are triggered afterwards in a chain.
This can easily be observed with this setup:
Commands (first is an impulse, second one is a chain command that is always active):
- /tp @e[type=armor_stand] 500 50 500 (absolute coordinates near the command block)
- /execute @e[type=armor_stand] ~ ~ ~ /execute @e[r=0] ~ ~ ~ /say hi
If you now summon an Armor Stand near your Command Blocks (in the same chunk), everything works as expected. The Armor Stand teleports and says hi.
If you summon in a chunk or two away and execute the commands, the Armor Stand still gets teleported, but there is no chat output anymore -> The Armor Stand is no longer within a radius 0 of itself.
This is not special to r=0, if the Armor Stand is teleported more than one block r=1 fails too.
From testing it does have to do with the chunk border, but in rare occasions one chunk distance still works fine.
This is not a problem with /execute. The /testfor command has the same issue and I would guess any other commands as well.
The same problem occurs when teleporting an entity to another entity instead of absolute coordinates.
This might seem like a very special problem, but because of this every command block system that teleports entities (and uses chain command blocks) might possibly just not work!Relevance of chunk borders
It seems that if the radius is large enough to touch a chunk border (actually 1 block less than enough to touch a chunk border) from the target position the next chunk behind that border behaves correctly. This would explain the fact that "sometimes 1 chunk distance is not enough".
This can be observed by choosing target coordinates that are right next to a chunk border.The following experiments used the target coordinates 0 56 0 which is right next to a chunk border (The position of the command blocks does not seem to matter) and were executed using 1.11.
First command: /tp @e[type=armor_stand] 0 56 0Here is a video showing this bug: https://www.youtube.com/watch?v=ls03ofiNTSA
Experiment #1:
- Place the Armor Stand at 0.5 56 -15.5 (16 blocks / 1 chunk away from the target coordinates)
- Use a radius of 0: /execute @e[type=armor_stand] ~ ~ ~ /execute @e[r=0] ~ ~ ~ /say hi
Result: Armor Stand is found
Experiment #2:
- Place the Armor Stand at 0.5 56 -16.5 (17 blocks / 2 chunk away from the target coordinates)
- Use a radius of 14: /execute @e[type=armor_stand] ~ ~ ~ /execute @e[r=14] ~ ~ ~ /say hi
Result: Armor Stand is not found
Experiment #3:
- Place the Armor Stand at 0.5 56 -16.5 (17 blocks / 2 chunk away from the target coordinates)
- Use a radius of 15: /execute @e[type=armor_stand] ~ ~ ~ /execute @e[r=15] ~ ~ ~ /say hi
Result: Armor Stand is found
When an entity gets teleported to a different chunk (sometimes 1 chunk distance is not enough), selectors that use an r argument will not find that entity correctly if they are triggered afterwards in a chain.
This can easily be observed with this setup:
Commands (first is an impulse, second one is a chain command that is always active):
- /tp @e[type=armor_stand] 500 50 500 (absolute coordinates near the command block)
- /execute @e[type=armor_stand] ~ ~ ~ /execute @e[r=0] ~ ~ ~ /say hi
If you now summon an Armor Stand near your Command Blocks (in the same chunk), everything works as expected. The Armor Stand teleports and says hi.
If you summon in a chunk or two away and execute the commands, the Armor Stand still gets teleported, but there is no chat output anymore -> The Armor Stand is no longer within a radius 0 of itself.
This is not special to r=0, if the Armor Stand is teleported more than one block r=1 fails too.
From testing it does have to do with the chunk border, but in rare occasions one chunk distance still works fine.
This is not a problem with /execute. The /testfor command has the same issue and I would guess any other commands as well.
The same problem occurs when teleporting an entity to another entity instead of absolute coordinates.
This might seem like a very special problem, but because of this every command block system that teleports entities (and uses chain command blocks) might possibly just not work!Relevance of chunk borders
It seems that if the radius is large enough to touch a chunk border (actually 1 block less than enough to touch a chunk border) from the target position the next chunk behind that border behaves correctly. This would explain the fact that "sometimes 1 chunk distance is not enough".
This can be observed by choosing target coordinates that are right next to a chunk border.The following experiments used the target coordinates 0 56 0 which is right next to a chunk border (The position of the command blocks does not seem to matter) and were executed using 1.11.
First command: /tp @e[type=armor_stand] 0 56 0Here is a video showing this bug: https://www.youtube.com/watch?v=ls03ofiNTSA
Experiment #1:
- Place the Armor Stand at 0.5 56 -15.5 (16 blocks / 1 chunk away from the target coordinates)
- Use a radius of 0: /execute @e[type=armor_stand] ~ ~ ~ /execute @e[r=0] ~ ~ ~ /say hi
Result: Armor Stand is found
Experiment #2:
- Place the Armor Stand at 0.5 56 -16.5 (17 blocks / 2 chunk away from the target coordinates)
- Use a radius of 14: /execute @e[type=armor_stand] ~ ~ ~ /execute @e[r=14] ~ ~ ~ /say hi
Result: Armor Stand is not found
Experiment #3:
- Place the Armor Stand at 0.5 56 -16.5 (17 blocks / 2 chunk away from the target coordinates)
- Use a radius of 15: /execute @e[type=armor_stand] ~ ~ ~ /execute @e[r=15] ~ ~ ~ /say hi
Result: Armor Stand is found
EDIT:
Apparently there are also horizontal borders (using y coordinates) wich is a big problem for boat ray casting. Because boats can't be turned invisible they have to be teleported high up in the sky, but they can be affected by this bug, for instance if you have to teleport them to another entity to inherit the rotation
When an entity gets teleported to a different chunk (sometimes 1 chunk distance is not enough), selectors that use an r argument will not find that entity correctly if they are triggered afterwards in a chain.
This can easily be observed with this setup:
Commands (first is an impulse, second one is a chain command that is always active):
- /tp @e[type=armor_stand] 500 50 500 (absolute coordinates near the command block)
- /execute @e[type=armor_stand] ~ ~ ~ /execute @e[r=0] ~ ~ ~ /say hi
If you now summon an Armor Stand near your Command Blocks (in the same chunk), everything works as expected. The Armor Stand teleports and says hi.
If you summon in a chunk or two away and execute the commands, the Armor Stand still gets teleported, but there is no chat output anymore -> The Armor Stand is no longer within a radius 0 of itself.
This is not special to r=0, if the Armor Stand is teleported more than one block r=1 fails too.
From testing it does have to do with the chunk border, but in rare occasions one chunk distance still works fine.
This is not a problem with /execute. The /testfor command has the same issue and I would guess any other commands as well.
The same problem occurs when teleporting an entity to another entity instead of absolute coordinates.
This might seem like a very special problem, but because of this every command block system that teleports entities (and uses chain command blocks) might possibly just not work!Relevance of chunk borders
It seems that if the radius is large enough to touch a chunk border (actually 1 block less than enough to touch a chunk border) from the target position the next chunk behind that border behaves correctly. This would explain the fact that "sometimes 1 chunk distance is not enough".
This can be observed by choosing target coordinates that are right next to a chunk border.The following experiments used the target coordinates 0 56 0 which is right next to a chunk border (The position of the command blocks does not seem to matter) and were executed using 1.11.
First command: /tp @e[type=armor_stand] 0 56 0Here is a video showing this bug: https://www.youtube.com/watch?v=ls03ofiNTSA
Experiment #1:
- Place the Armor Stand at 0.5 56 -15.5 (16 blocks / 1 chunk away from the target coordinates)
- Use a radius of 0: /execute @e[type=armor_stand] ~ ~ ~ /execute @e[r=0] ~ ~ ~ /say hi
Result: Armor Stand is found
Experiment #2:
- Place the Armor Stand at 0.5 56 -16.5 (17 blocks / 2 chunk away from the target coordinates)
- Use a radius of 14: /execute @e[type=armor_stand] ~ ~ ~ /execute @e[r=14] ~ ~ ~ /say hi
Result: Armor Stand is not found
Experiment #3:
- Place the Armor Stand at 0.5 56 -16.5 (17 blocks / 2 chunk away from the target coordinates)
- Use a radius of 15: /execute @e[type=armor_stand] ~ ~ ~ /execute @e[r=15] ~ ~ ~ /say hi
Result: Armor Stand is found
EDIT:
Apparently there are also horizontal borders (using y coordinates) wich is a big problem for boat ray casting. Because boats can't be turned invisible they have to be teleported high up in the sky, but they can be affected by this bug, for instance if you have to teleport them to another entity to inherit the rotation
Chain command selectors don't work correctly when teleporting an entityto a different chunkPosition based selector arguments fail finding entity if it has been moved to a different chunk in the same tick
'os.name' = 'Windows 7'
'os.version' = '6.1'
'os.arch' = 'amd64'
'java.version' = '1.8.0_45'
'java.vendor' = 'Oracle Corporation'
'sun.arch.data.model' = '64'
When an entity gets teleported to a different chunk (sometimes 1 chunk distance is not enough), selectors that use an r argument will not find that entity correctly if they are triggered afterwards in a chain.
This can easily be observed with this setup:
Commands (first is an impulse, second one is a chain command that is always active):
- /tp @e[type=armor_stand] 500 50 500 (absolute coordinates near the command block)
- /execute @e[type=armor_stand] ~ ~ ~ /execute @e[r=0] ~ ~ ~ /say hi
If you now summon an Armor Stand near your Command Blocks (in the same chunk), everything works as expected. The Armor Stand teleports and says hi.
If you summon in a chunk or two away and execute the commands, the Armor Stand still gets teleported, but there is no chat output anymore -> The Armor Stand is no longer within a radius 0 of itself.
This is not special tor=0, if the Armor Stand is teleported more than one block r=1 fails too.From testing it does have to do with the chunk border, but in rare occasions one chunk distance still works fine.
This is not a problem with /execute. The /testfor command has the same issue and I would guess any other commands as well.
The same problem occurs when teleporting an entity to another entity instead of absolute coordinates.
This might seem like a very special problem, but because of this every command block system that teleports entities (and uses chain command blocks) might possibly just not work!Relevance of chunk borders
It seems that if the radius is large enough to touch a chunk border (actually 1 block less than enough to touch a chunk border) from the target position the next chunk behind that border behaves correctly. This would explain the fact that "sometimes 1 chunk distance is not enough".
This can be observed by choosing target coordinates that are right next to a chunk border.The following experiments used the target coordinates 0 56 0 which is right next to a chunk border (The position of the command blocks does not seem to matter) and were executed using 1.11.
First command: /tp @e[type=armor_stand] 0 56 0
Here is a video showing this bug:https://www.youtube.com/watch?v=ls03ofiNTSA
Experiment #1:
- Place the Armor Stand at 0.5 56 -15.5 (16 blocks / 1 chunk away from the target coordinates)
- Use a radius of 0: /execute @e[type=armor_stand] ~ ~ ~ /execute @e[r=0] ~ ~ ~ /say hi
Result: Armor Stand is found
Experiment #2:
- Place the Armor Stand at 0.5 56 -16.5 (17 blocks / 2 chunk away from the target coordinates)
- Use a radius of 14: /execute @e[type=armor_stand] ~ ~ ~ /execute @e[r=14] ~ ~ ~ /say hi
Result: Armor Stand is not found
Experiment #3:
- Place the Armor Stand at 0.5 56 -16.5 (17 blocks / 2 chunk away from the target coordinates)
- Use a radius of 15: /execute @e[type=armor_stand] ~ ~ ~ /execute @e[r=15] ~ ~ ~ /say hi
Result: Armor Stand is found
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 likelyMC-108469because 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
→
is duplicated by
relates to
![[Mod] Asteraoth](../../../data/avatars/users/92886.png){kind=small}
![[Mod] Neko](../../../data/avatars/users/92901.png){kind=small}
is duplicated by
![[Mojang] Nathan Adams](../../../data/assets/gravatar/dinnerbone.png){kind=small}
![[Mod] violine1101](../../../data/avatars/users/92858.png){kind=small}
Relate to MC-89667
Would it make sense to rather directly update the chunk entity lists as soon as the position of an entity changes? Otherwise MC-89667 would remain unfixed and require a different solution.
Sounds like a duplicate of MC-89667
Oh, I see. And you're sure this isn't a duplicate of MC-89667?
And is this also an issue in 1.12.2 for you?
"Would it make sense to rather directly update the chunk entity lists as soon as the position of an entity changes? Otherwise MC-89667 would remain unfixed and require a different solution."
Yes editing all the entity.setLocation/positions if chunk detected has been changed it would make sense to remove the entity from that chunk and add it to the new one. This would be more of a proper fix for everything. Then the entity selectors from the other issue mentioned here should work as well if not they should be able to easily wip up a fix
Could have sworn they made this bug fix a long time ago like in beta guess they must have reverted their code since jeb took over
Please reduce this report to @s not being considered when resolving text components of signs and create a separate report for the other part. Though it sounds like that might be MC-89667.
Thanks for the prompt answers.
@FVbico: I wasn't aware that the sign resolves the JSON and not the one who executes the actual command. Thank you for clarifying that!
@Marcono1234: I agree that this is the same problem as in the MC-89667. I didn't realise that this issue was independent of the JSON and as such didn't specify my previous searches correctly...
I highly doubt this has to do with my computer, but to be sure it would be nice if someone could confirm this.
Still an issue in 15w46a
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.
Here is a video showing this bug: https://www.youtube.com/watch?v=ls03ofiNTSA
OH! I see now. I thought you meant teleporting the entity to a completely far away chunck. I'll have me and my friends vote on this bug.
Confirmed for 1.9-pre1
Confirmed for 1.9-pre4
This bug is so frustrating for me, yet it doesn't get attention.
Make sure to include the 1.9.1 pre release versions as the effected versions if it occurs on one of the 1.9.1 pre releases. And dude, there are many bug tickets that mojang has to go through. So have patience and in time, it will get looked at by a mojangsta.
I changed the description and removed large parts of it, I hope you are fine with this.
As per my comment on
MC-124491, I think it's fine if this is WAI or WontFix (for efficiency reasons), but it would be good to get an 'official ruling'.Unless I have reproduced this bug wrong, then it seems to be fixed in 1.13-pre8.
Edit: Yup, I have reproduced this wrong affects both 1.12.2 and 1.13-pre8.
[Mod] Asteraoth, could you repro this in 1.12.2?
Confirmed for 1.13
Confirmed in 18w30b
Confirmed for 18w31a
Confirmed for 18w32a
Confirmed for 18w33a
Confirmed for 1.13.1-pre1
Confirmed in 1.15.2 and 1.16 Release Candidate 1.
Affects 1.16.1 and 20w27a
fixed in 20w45a; likely because
MC-108469was fixedI cannot even reproduce this in 1.16.4. Can someone still reproduce this in 1.16.4 (or 20w45a)? If not we will resolve this report as "Cannot Reproduce" since the exact fix version is unknown.
Though interestingly I am seeing the following warning in 1.16.4 which I am not seeing in 20w45a (but the armor stand is still present when loading the chunk where it has been teleport to):
I am unable to reproduce this in 20w49a.
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.
This can be reproduced additionally if you do the following method:
This bug is circumvented if you do the following:
attached a video demonstrating the datapack reproducing the issue
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.Thanks for letting us know, Onnowhere. I will resolve this report as "Cannot Reproduce" then since we don't know for sure if 20w45a really had the intention to fix this specific bug, or only fixed it by accident.