mojira.dev
MCPE-156283

'/execute at' not applying position changes to '/execute as', '/execute at', and '/execute positioned as'

The bug

With the new /execute command syntax, setting the position to a target with the /execute at subcommand works normally in most circumstances, such as combining it with the (if|unless) entity subcommands, and it will correctly set the command's position to that target.

However, the command seemingly does not inherit the target's position in regard to finding new targets for the /execute as, /execute at or /execute positioned as subcommands; instead, it ignores the preceding at <target> subcommand and uses the command's current position. As pointed out in the comments, a second subcommand is needed following at <target> for the command to behave as expected.

Steps to reproduce

Method A

The primary goal here is to create a situation where one entity needs to be near another to succeed. I will be using an armor stand as an arbitrary position, and a fishing hook as the entity behaving as a condition.

  • Set up a new world with the Upcoming Creator Features experiment enabled.

  • Place down an armor stand somewhere.

  • Grab a fishing rod, and cast the bobber near the armor stand, somewhere within three blocks for this demonstration.

  • Stand at least three blocks away from the bobber and run this command in chat:

    /execute at @e[type=armor_stand] as @e[type=fishing_hook,r=3] run say @s

    →❌ "No targets matched selector". Only returns true when you stand within three blocks of the bobber, as the parser uses your position when finding the bobber instead of the armor stand's position.

Method B

The attached behavior pack has a unit test made with GameTest using similar reproduction steps, except the armor stand is replaced with a simulated player and the fishing bobber is replaced with an armor stand.

  • Make a new world with both the GameTest Framework and Upcoming Creator Features experiments enabled, or use an existing world.

  • Run the following command to start the unit test:

    /gametest run new_execute_command_tests:mcpe_156283

    →❌ "No targets matched selector"

Linked issues

Attachments

Comments

migrated

Sort of having the same issue on my end with my bug. I feel like something is definitely wrong with /execute and selectors. 

Former user

Here's another example:

 

when a player runs:

/execute as @e at @s at @s[r=0.1] run say @s

only the player itself is printed.

 

And when running:

/execute as @e at @s at @s at @s[r=0.1] run say @s

all entities are printed

 

And not only "at" has this bug, but "positioned as" and "positioned" also have.

 

Here're some pictures to roughly show the processing order of selectors and subcommands

[media][media][media]

 

[media]
Sprunkles

Updated the report to be clearer about what the problem is.

migrated

I believe I have pinpointed the problem. Please let me know if you agree or disagree with what I have written below:


Definitions

First, we must define the offending subcommands and affected subcommands.

Offending subcommands have been found as: /execute at <entity>, /execute positioned <coords>, and /execute positioned as <entity>.

Affected subcommands have been found as: /execute as <entity>, /execute at <entity>, and /execute positioned as <entity>.

This is an issue that occurs when an offending subcommand is immediately followed by an affected subcommand.

  • Correct behaviour: The affected subcommand's target selector should make its calculations from the position that has been changed by the offending subcommand.

  • Current behaviour: The affected subcommand's target selector makes its calculations from the position before it was changed by the offending subcommand.


Examples

These examples were performed with an armour stand with the tag test in the world with a command block nearby to run the commands in these examples.

❌ Examples of the unwanted behaviour

execute as @e[tag=test] at @s as @p[r=3] run say test
execute as @e[tag=test] at @s at @p[r=3] run setblock ~ ~3 ~ stone
execute as @e[tag=test] at @s positioned as @p[r=3] run setblock ~ ~3 ~ stone

execute as @e[tag=test] positioned as @s as @p[r=3] run say test
execute as @e[tag=test] positioned as @s at @p[r=3] run setblock ~ ~3 ~ stone
execute as @e[tag=test] positioned as @s positioned as @p[r=3] run setblock ~ ~3 ~ stone

execute at @e[tag=test] as @p[r=3] run say test
execute at @e[tag=test] at @p[r=3] run setblock ~ ~3 ~ stone
execute at @e[tag=test] positioned as @p[r=3] run setblock ~ ~3 ~ stone

These commands should execute when the player is within three blocks of the tagged entity. Instead, they execute when the player is within three blocks of the command block.

execute positioned ~ ~5 ~ as @p[r=3] run say test

This command should execute when the player is within three blocks of the position five blocks of the command block. Instead, it executes when the player is within three blocks of the command block itself.

execute positioned ~ ~5 ~ at @e[tag=test] as @p[r=3] run say test

Here, we added positioned ~ ~5 ~ as a decoy before setting the position to the entity that we want. Yet, the bug makes it so that @p[r=3] begins searching from ~ ~5 ~, which is not correct. It should be searching from the location of the tagged entity.

✔ Similar examples that do not cause unwanted behaviour

execute as @e[tag=test] at @s if entity @p[r=3] run say test
execute as @e[tag=test] positioned as @s if entity @p[r=3] run say test
execute at @e[tag=test] if entity @p[r=3] run say test

These commands execute in the expected manner, printing test if there is a player within three blocks of the tagged entity. They also execute correctly with unless. This shows that the if and unless subcommands are not affected by this bug.

execute at @e[tag=test] run tellraw @a {"rawtext":[{"selector":"@p[r=3]"}]}
execute at @e[tag=test] run effect @p[r=3] jump_boost 10 0 true

These commands execute in the expected manner, printing/effecting the player only if they are within three blocks of the tagged entity. This shows that target selectors in the run command are not affected by this bug.

execute at @e[tag=test] positioned ~ ~3 ~ run setblock ~ ~ ~ stone

This command executes in the expected manner, setting a block three blocks above the tagged entity. This shows that positioned <coords> is not an affected subcommand. If it were an affected subcommand, the stone may have been placed three blocks above the command block.

Examples of temporary workarounds to correct the unwanted behaviour

This unwanted behaviour can be corrected by inserting any subcommand in between the offending and affected subcommands.

Here are six of the nine commands from the first example, each with a different example of a remedy:

execute as @e[tag=test] at @s run execute as @p[r=3] run say test
execute as @e[tag=test] at @s if entity @s at @p[r=3] run setblock ~ ~3 ~ stone
execute as @e[tag=test] at @s at @s positioned as @p[r=3] run setblock ~ ~3 ~ stone

execute as @e[tag=test] positioned as @s as @s as @p[r=3] run say test
execute as @e[tag=test] positioned as @s positioned as @s at @p[r=3] run setblock ~ ~3 ~ stone
execute as @e[tag=test] positioned as @s unless entity @e[tag=impossible] positioned as @p[r=3] run setblock ~ ~3 ~ stone

We inserted a different subcommand in between the offending and affected subcommands, and no matter what separates them, it corrects the unwanted behaviour.

The simplest remedies are:

  • run execute

  • if entity @s

  • as @s

The latter two will only work if an @s entity has been defined with as beforehand, and run execute will always work. The common thing about these remedies is that when they do work, they will not change anything.

Also shown are less common remedies that are not recommended but will still work in some (not all) situations. These include:

  • Repeating the offending subcommand: at @s at @s or positioned as @s positioned as @s. A repetition will not change anything, provided that only one entity is selected and/or @s is defined, if applicable (or both).

  • unless entity @e[tag=impossible] will always pass, but is considered acceptable separation and will work to remedy the bug.

  • if entity @e is also an option if if entity @s is inapplicable in the current situation. However it is less efficient on performance.


Conclusions

This bug produces unexpected behaviour to certain combinations of subcommands within the new /execute command. Extensive testing was required to pinpoint the exact combinations that cause the unwanted behaviour. We also find that this bug is easily worked around while it is still present, in many ways. However, it is still behaviour that is illogical to the way /execute should be working, and it requires the insertion of redundant checks, the least intrusive being run execute, but which still takes resources, as it has to look up what /execute is again. The behaviour seen here is most likely unintended, and this problem should be corrected at the team's earliest convenience.

Sprunkles

Updated the report and attached a GameTest pack for testing.

migrated

It appears that there may be a potential fix in an upcoming release. Testing will need to occur to ensure that all subcommands have been fixed, and that none have been left behind.

Edit: From testing, it appears that most if not all of the subcommands from the examples in my previous comment have been fixed. I tested several from the large list of nine commands, and each example from the single examples as well. The issue appears to be fixed at this point. Thank you to the team for fixing this problem.

Sprunkles

(Unassigned)

796780

Confirmed

Windows

1.19.10.20 Preview, 1.19.10, 1.19.30.20 Preview, 1.19.20

1.19.30.22 Preview, 1.19.30

Retrieved