[MC-124140] Anchoring does not reset after use, and is implicitly applied in nonsensical cases by default

What I expected:
I expected that after I anchored the origin of the local coordinate system to my eyes, and set a position using local coordinates, that the anchoring would be reset (as it no longer makes sense, though the option always exists to re-anchor).

What actually happened:
After anchoring the origin of the local coordinate system to my eyes, and setting the position using local coordinates, the anchoring still applied, and I had to use anchored feet to fix it.

More details:
See the image attachment. A workaround for this issue is adding anchored feet directly after anything that makes use of a non-default anchor point, but this is much less obvious given that the main use of anchored will be with entities, and changing the position would retain a seemingly-arbitrary offset.

Here are commands to reproduce the issue:

execute as @a at @s anchored eyes positioned ^ ^ ^3 run particle end_rod ~ ~ ~
execute as @a at @s anchored eyes positioned ^ ^ ^3 positioned ^ ^ ^ run particle flame ~ ~ ~
execute as @a at @s anchored eyes positioned ^ ^ ^3 positioned ~ ~ ~2 run particle flame ~ ~ ~
execute as @a at @s anchored eyes positioned ^ ^ ^3 facing ~ ~ ~2 positioned ^ ^ ^5 run particle flame ~ ~ ~

The first 3 commands function as markers to visualize the steps taken in the final command. The end rod particle represents the sensible step, 5 blocks in front of the players' eyes. But the flames represent a line segment created by anchored eyes being implicitly applied a second time, the bottom left of which is an endpoint.

Here are commands to show what I expected the above 4 commands to look like if this issue did not exist:

execute as @a at @s anchored eyes positioned ^ ^ ^3 run particle end_rod ~ ~ ~
execute as @a at @s anchored eyes positioned ^ ^ ^3 anchored feet positioned ^ ^ ^ run particle flame ~ ~ ~
execute as @a at @s anchored eyes positioned ^ ^ ^3 positioned ~ ~ ~2 run particle flame ~ ~ ~
execute as @a at @s anchored eyes positioned ^ ^ ^3 anchored feet facing ~ ~ ~2 positioned ^ ^ ^5 run particle flame ~ ~ ~

Linked issues

is duplicated by 1

MC-124381 /execute positioned no longer offsets properly when recursing. Resolved

Attachments

Comments 19

CreeperMagnet_ 2018-02-06T01:52:58Z

This still affects 18w05a. And you'd probably want to update the description, and this is a result of anchored simply not working with positioned, similarly to MC-124381, which I found. I have no idea why this is occurring, I've been testing a bunch, to no avail.

Brian McNamara 2018-02-07T02:01:35Z

This is all WAI.

OP's expectation is wrong, tildes never care about anchoring.

Alluet 2018-02-07T02:04:50Z

If you read the post, you'd see that I am using local coordinates. It's just facing some relative coordinates (which I only expect to be elevated after overwriting the position, not from the get-go).

Aaron Rhodes 2018-02-08T15:43:25Z

Anchored makes the rest of a command use feet/eyes for local coordinates and facing commands. This means that anchoring at the players eyes, then positioning 1 block forward will set the new foot level 1 block forward from the players eye level. chaining another positioned command will still run from the eye level, which is now 1.62 blocks above the current foot level. The same occurs if using a facing command, it will execute 1.62 blocks above whatever the current foot level is and run as though the player is looking at the location 2 blocks south (from the command you gave) of the current foot location (since relative coordinates were used). If local coordinates were used in the facing command, it would run as though the player is looking either to the side, up, or forward from their eye level. Anchored changes whether local coordinates execute from the players feet or eyes, but relative coordinates always execute from wherever the current foot location is (changed by using "at" or "positioned").

Alluet 2018-02-08T15:54:06Z

I understand the functionality of facing. However, after I change my base position using positioned and local coordinates, I expected to be able to execute further subcommands from that position. Instead, the facing subcommand I executed appears to have treated the new position as if it was the eye level, and decided to go down to the foot level since that's where relative coordinates always run. However, this new position is meant to replace the foot level, and the anchoring should be reset correctly.

9 more comments

Aaron Rhodes 2018-02-08T18:40:35Z

Anchoring is set for the duration of the command unless it is explicitly changed by the player. It does not reset on its own, it only updates relative to where the new foot location is.

"positioned" sets the new foot location.
relative coordinates run from the foot location.
"anchored" sets the location that local coordinates and facing commands are run from for the duration of the command (feet by default)
"facing" runs from the executing location to the location of the specified coordinates.

The facing command is not treating the new position as the eye level, it is executing from 1.62 blocks above the new position because "anchored eyes" is still in effect. The new position, or the new foot location, is what the relative coordinates specified in the facing command will be based on. It will face from the eye level to the location specified relative to the foot location (because of relative coordinates). Currently everything is working as intended, so I don't see the issue here. Please add a screenshot that shows 1.) the spot where the player is located and 2.) the spot where you expect the flame particle to appear. Mark both locations with a different block.

Aaron Rhodes 2018-02-08T18:51:59Z

It executes 3 blocks forward in the direction the player is facing from their eye level, then the facing command executes from 1.62 blocks above that point down at an angle of 54.09593142 degrees (arcsin(1.62/2)) and facing south. The last positioned command executes 5 blocks out from the same spot as the facing command at the same angle, which causes the flame particle to appear close to the same y value as your original foot level. This behavior is intentional and I hope you have learned how these commands operate.

Alluet 2018-02-08T19:52:46Z

Ah, I see. Thanks for those details, the math checks out. It is definitely strange that anchored eyes would still apply after one use, but adding anchored feet between the first positioned and facing fixed the issue. I will be rewriting the description of this bug to reflect that.

Aaron Rhodes 2018-02-08T20:32:13Z

It is definitely causing issues when the anchoring doesn't reset, as the only alternatives are using /execute positioned ~ ~1.62 ~, and /execute anchored eyes positioned ^ ^ ^ anchored feet, and maybe a few other setups. Not every player will know the exact height of the players eyes, so the first option isn't sufficient enough. The second option just seems too cluttered and unnecessary. Other than that, the player would have to continually adjust for the offset that anchored eyes adds to each iteration. Observing this behavior definitely makes it seem more like a bug than an intended feature. The description is much more concise now and gets to the root of the issue.

CreeperMagnet_ 2018-02-15T22:53:42Z

Still affects 18w07b. 😞

Aaron Rhodes 2018-02-15T23:34:08Z

Now that I think about it, the anchored setting shouldn't get reset. Using positioned after anchored eyes does not apply the setting in the right way. The new position should be anchored at the current eye level, not get set as the new foot level then apply the anchored eyes. If you really need something that works, you can use positioned ~ ~1.62 ~ outside of a function to get it at eye level, which is the exact function that anchored eyes should have.

Brian McNamara 2018-02-16T00:43:13Z

This is WAI

Alluet 2018-02-16T01:02:17Z

When I talked to him a while back, Dinnerbone implied that the functionality implicitly encouraged by this bug would never be used in practice, but was still meant to be an option. Perhaps this issue is WAI, but I still feel like it deserves to be considered.

Maxaxik 2018-03-21T17:37:51Z

This is still the case in 18w11a
I also find it confusing that commands such as:
/execute as @a at @s anchored eyes positioned ^ ^ ^ positioned ^ ^ ^ run particle flame ^ ^ ^
stack the positions up, causing the particle to appear ~5 blocks above the player, instead of appearing at their eyes.

Hugman_76 2018-04-16T18:20:42Z

Affects 18w15a.

CreeperMagnet_ 2018-06-10T19:44:56Z

Affects 1.13-pre1, and I think this is more an issue that positioned with local coordinates doesn't reposition the eye level when working with local coordinates.

ie.

/execute anchored eyes positioned ^ ^ ^1 positioned ^ ^ ^1 run setblock ~ ~ ~ stone

will execute off the eyes, but the reposition where the feet are, to one block from the eyes, and then since the feet are repositioned, it thinks the eyes are up there too, and then repositions it again to where the eyes are, making it so the stone ends up two blocks from where you're looking, and two player eye heights up.

This should really reposition where the eyes are if the command is already anchored to the eyes, so the stone would appear 2 blocks from the player's eyes.

CreeperMagnet_ 2018-07-05T17:42:06Z

Affects 1.13-pre6.

Maxaxik 2018-08-31T15:45:56Z

Affects 1.13.1

Fwuhfwi 2019-08-31T10:17:45Z

Seems to affect 1.14.4.

Found this bug by running a datapack with two functions, "namespace:trigger" and "namespace:raycast", for a total of three commands.
Contents of "namespace:trigger":
execute as @s anchored eyes positioned ^ ^ ^1 run function namespace:raycast
Contents of "namespace:raycast":
execute run particle flame ~ ~ ~ 0 0 0 0 1
execute as @s positioned ^ ^ ^0.1 run function namespace:raycast

The intuitive and expected result after calling "namespace:trigger" with the function command in-game would be a line of flame particles drawn from the user's eyes onwards in the direction they are facing. The trigger function should set the initial base for the local coordinates to the user's eyes, then run the recursive raycast function which spawns a flame particle at the local coordinates, then shifts the local coordinates forward by 0.1 blocks and runs itself again.

What happens instead is a line of flame particles are drawn upwards in intervals of the player's height (from feet to eyes). Similar to what CreeperMagnet_ said, what is likely happening in this scenario is that every time the raycast function is called, the local coordinates are raised by the height of the user's eye level as though the anchored subcommand is being called upon again after repositioning. In the comments section of MC-124381, Aaron Rhodes suggested adding "anchored feet" to counteract the "anchored eyes" in the command. This fixes the problem, supporting that the cause of the issue lies somewhere with the execute command repeatedly "anchoring" the local coordinates to a height corresponding to the user's eye level every time the following commands are run. (I would also like to add that although inserting "anchored feet" may resolve the issue in some circumstances, it's a bit of an unintuitive solution.)