MC-124138local coordinates (^ ^ ^5) require an entity even after execute-facing
Put the following command in a command block and activate it:
execute at @p facing ~ ~ ~2 run summon pig ^ ^1 ^5
EXPECTED
summons a pig at location ~ ~1 ~5 from the player (at their position, facing positive Z, local ^ ^1 ^5)
ACTUAL
command fails, error in block is:
[14:09:27] An entity is required to run this command here
More generally, I expect that 'facing' should override subsequent carets, in the same way that `at` or `positioned` override subsequent tildes (and default x=,y=,z= in selectors).
LATER...
After a few days mulling, I think I grok the purpose of 'anchored' better now. In particular, if I want to use a teleport to change @p's rotation so that he is facing a baby zombie standing over yonder, I see that there are four possible rays (my eyes to zombie eyes, my feet to zombie eyes, my eyes to zombie feet, my feet to zombie feet) which correspond to four distinct angles. 'anchored' provides an incoming context by which to choose the origin (my eyes/feet), and tp's facing argument of eyes/feet provides a way to select the destination.
I guess the current system is fine, except that it would be really nice if, if @s is null, then 'anchored' computations are done 'as if @s were a zero-tall entity', that is eyes=feet, so that entity-less local-coordinates (a useful feature in prior snapshots) are still able to be used. That's the crux of this bug.
Created Issue:
local coordinates (^ ^ ^5) require an entity even after execute-facing
Put the following command in a command block and activate it:
execute at @p facing ~ ~ ~2 run summon pig ^ ^1 ^5EXPECTED
summons a pig at location ~ ~1 ~5 from the player (at their position, facing positive Z, local ^ ^1 ^5)
ACTUAL
command fails, error in block is:
[14:09:27] An entity is required to run this command hereMore generally, I expect that 'facing' should override subsequent carets in the same way that `at` or `positioned` override subsequent tildes (and default x=,y=,z= in selectors).
Put the following command in a command block and activate it:
execute at @p facing ~ ~ ~2 run summon pig ^ ^1 ^5EXPECTED
summons a pig at location ~ ~1 ~5 from the player (at their position, facing positive Z, local ^ ^1 ^5)
ACTUAL
command fails, error in block is:
[14:09:27] An entity is required to run this command hereMore generally, I expect that 'facing' should override subsequent carets, in the same way that `at` or `positioned` override subsequent tildes (and default x=,y=,z= in selectors).
Put the following command in a command block and activate it:
execute at @p facing ~ ~ ~2 run summon pig ^ ^1 ^5EXPECTED
summons a pig at location ~ ~1 ~5 from the player (at their position, facing positive Z, local ^ ^1 ^5)
ACTUAL
command fails, error in block is:
[14:09:27] An entity is required to run this command hereMore generally, I expect that 'facing' should override subsequent carets, in the same way that `at` or `positioned` override subsequent tildes (and default x=,y=,z= in selectors).
OTHER THOUGHTS
It has been suggested by others that perhaps 'facing' is more like 'teleport @s to point in a new direction', in which case it would require an executor (@s). However that seems like a weird design to me. My assumption was that execute-facing provided a 'local coordinates context, regardless of sender' the same way that 'execute-at' provided a 'relative coordinates context, regardless of sender'. What is execute-facing supposed to do?
Put the following command in a command block and activate it:
execute at @p facing ~ ~ ~2 run summon pig ^ ^1 ^5EXPECTED
summons a pig at location ~ ~1 ~5 from the player (at their position, facing positive Z, local ^ ^1 ^5)
ACTUAL
command fails, error in block is:
[14:09:27] An entity is required to run this command hereMore generally, I expect that 'facing' should override subsequent carets, in the same way that `at` or `positioned` override subsequent tildes (and default x=,y=,z= in selectors).
OTHER THOUGHTS
It has been suggested by others that perhaps 'facing' is more like 'teleport @s to point in a new direction', in which case it would require an executor (@s). However that seems like a weird design to me. My assumption was that 'execute-facing' provided a 'local coordinates context, regardless of sender' the same way that 'execute-at' provided a 'relative coordinates context, regardless of sender'. What is execute-facing supposed to do?
Put the following command in a command block and activate it:
execute at @p facing ~ ~ ~2 run summon pig ^ ^1 ^5EXPECTED
summons a pig at location ~ ~1 ~5 from the player (at their position, facing positive Z, local ^ ^1 ^5)
ACTUAL
command fails, error in block is:
[14:09:27] An entity is required to run this command hereMore generally, I expect that 'facing' should override subsequent carets, in the same way that `at` or `positioned` override subsequent tildes (and default x=,y=,z= in selectors).
OTHER THOUGHTS
It has been suggested by others that perhaps 'facing' is more like 'teleport @s to point in a new direction', in which case it would require an executor (@s). However that seems like a weird design to me. My assumption was that 'execute-facing' provided a 'local coordinates context, regardless of sender' the same way that 'execute-at' provided a 'relative coordinates context, regardless of sender'. What is execute-facing supposed to do?
EDIT
It has also been pointed out that anchor feet/eyes affects how ^^^ works, and thus a sender-entity-less command lacks an anchor. I feel like just assuming a 'null sender' behaves like a zero-tall entity (and thus feet or eyes both anchor to same position) is a reasonable thing to do. (Overall, a strong motivation among command-programmers is to 'reduce entities', and it would be nice to be able to use 'local coordinates' without an entity, which is what I was trying to do, that initially motivated this bug report.)
Put the following command in a command block and activate it:
execute at @p facing ~ ~ ~2 run summon pig ^ ^1 ^5EXPECTED
summons a pig at location ~ ~1 ~5 from the player (at their position, facing positive Z, local ^ ^1 ^5)
ACTUAL
command fails, error in block is:
[14:09:27] An entity is required to run this command hereMore generally, I expect that 'facing' should override subsequent carets, in the same way that `at` or `positioned` override subsequent tildes (and default x=,y=,z= in selectors).
OTHER THOUGHTS
It has been suggested by others that perhaps 'facing' is more like 'teleport @s to point in a new direction', in which case it would require an executor (@s). However that seems like a weird design to me. My assumption was that 'execute-facing' provided a 'local coordinates context, regardless of sender' the same way that 'execute-at' provided a 'relative coordinates context, regardless of sender'. What is execute-facing supposed to do?
EDIT
It has also been pointed out that anchor feet/eyes affects how ^^^ works, and thus a sender-entity-less command lacks an anchor. I feel like just assuming a 'null sender' behaves like a zero-tall entity (and thus feet or eyes both anchor to same position) is a reasonable thing to do. (Overall, a strong motivation among command-programmers is to 'reduce entities', and it would be nice to be able to use 'local coordinates' without an entity, which is what I was trying to do, that initially motivated this bug report.)
ANOTHER EDIT
Yeah, there was an idiom of 'entityless raytracing' where you have a recursive function that recurses via e.g.
execute at ^ ^ ^0.1 run function ns:selfwhere in prior snapshots the ^^^ were 'anchored' to the 'at' location. Now if 'anchoring' uses '@s' and '@s' is not moving/teleported in the recursive call, it is unclear to me if/how to realize that useful idiom.
Put the following command in a command block and activate it:
execute at @p facing ~ ~ ~2 run summon pig ^ ^1 ^5EXPECTED
summons a pig at location ~ ~1 ~5 from the player (at their position, facing positive Z, local ^ ^1 ^5)
ACTUAL
command fails, error in block is:
[14:09:27] An entity is required to run this command hereMore generally, I expect that 'facing' should override subsequent carets, in the same way that `at` or `positioned` override subsequent tildes (and default x=,y=,z= in selectors).
OTHER THOUGHTS
It has been suggested by others that perhaps 'facing' is more like 'teleport @s to point in a new direction', in which case it would require an executor (@s). However that seems like a weird design to me. My assumption was that 'execute-facing' provided a 'local coordinates context, regardless of sender' the same way that 'execute-at' provided a 'relative coordinates context, regardless of sender'. What is execute-facing supposed to do?
EDIT
It has also been pointed out that anchor feet/eyes affects how ^^^ works, and thus a sender-entity-less command lacks an anchor. I feel like just assuming a 'null sender' behaves like a zero-tall entity (and thus feet or eyes both anchor to same position) is a reasonable thing to do. (Overall, a strong motivation among command-programmers is to 'reduce entities', and it would be nice to be able to use 'local coordinates' without an entity, which is what I was trying to do, that initially motivated this bug report.)
ANOTHER EDIT
Yeah, there was an idiom of 'entityless raytracing' where you have a recursive function that recurses via e.g.
execute at ^ ^ ^0.1 run function ns:selfwhere in prior snapshots the ^^^ were 'anchored' to the 'at' location. Now if 'anchoring' uses '@s' and '@s' is not moving/teleported in the recursive call, it is unclear to me if/how to realize that useful idiom.
FINAL THOUGHT
I guess overall, I am unclear why 'anchoring' needs to be part of the local context. It seems to me that if "anchor eyes" just behaved the same as "positioned ~ ~N ~" where N was computed based on the value of @s, then this might be good enough? That is, "eyes" becomes shorthand for a @s-mob-lookup-table of eye-height values, but does not add an additional context field to the system, rather it just automatically adjusts y as part of the existing xyz context.
Put the following command in a command block and activate it:
execute at @p facing ~ ~ ~2 run summon pig ^ ^1 ^5EXPECTED
summons a pig at location ~ ~1 ~5 from the player (at their position, facing positive Z, local ^ ^1 ^5)
ACTUAL
command fails, error in block is:
[14:09:27] An entity is required to run this command hereMore generally, I expect that 'facing' should override subsequent carets, in the same way that `at` or `positioned` override subsequent tildes (and default x=,y=,z= in selectors).
OTHER THOUGHTS
It has been suggested by others that perhaps 'facing' is more like 'teleport @s to point in a new direction', in which case it would require an executor (@s). However that seems like a weird design to me. My assumption was that 'execute-facing' provided a 'local coordinates context, regardless of sender' the same way that 'execute-at' provided a 'relative coordinates context, regardless of sender'. What is execute-facing supposed to do?
EDIT
It has also been pointed out that anchor feet/eyes affects how ^^^ works, and thus a sender-entity-less command lacks an anchor. I feel like just assuming a 'null sender' behaves like a zero-tall entity (and thus feet or eyes both anchor to same position) is a reasonable thing to do. (Overall, a strong motivation among command-programmers is to 'reduce entities', and it would be nice to be able to use 'local coordinates' without an entity, which is what I was trying to do, that initially motivated this bug report.)
ANOTHER EDIT
Yeah, there was an idiom of 'entityless raytracing' where you have a recursive function that recurses via e.g.
execute at ^ ^ ^0.1 run function ns:selfwhere in prior snapshots the ^^^ were 'anchored' to the 'at' location. Now if 'anchoring' uses '@s' and '@s' is not moving/teleported in the recursive call, it is unclear to me if/how to realize that useful idiom.
FINAL THOUGHT
I guess overall, I am unclear why 'anchoring' needs to be part of the local context. It seems to me that if "anchor eyes" just behaved the same as "positioned ~ ~N ~" where N was computed based on the value of @s, then this might be good enough? That is, "eyes" becomes shorthand for a @s-mob-lookup-table of eye-height values, but does not add an additional context field to the system, rather it just automatically adjusts y as part of the existing xyz context. Then 'facing' becomes simple again, its origin is always just context's xyz, rather than (current) complicated combination of xyz, anchor setting, and @s value.
Put the following command in a command block and activate it:
execute at @p facing ~ ~ ~2 run summon pig ^ ^1 ^5EXPECTED
summons a pig at location ~ ~1 ~5 from the player (at their position, facing positive Z, local ^ ^1 ^5)
ACTUAL
command fails, error in block is:
[14:09:27] An entity is required to run this command hereMore generally, I expect that 'facing' should override subsequent carets, in the same way that `at` or `positioned` override subsequent tildes (and default x=,y=,z= in selectors).
OTHER THOUGHTS
It has been suggested by others that perhaps 'facing' is more like 'teleport @s to point in a new direction', in which case it would require an executor (@s). However that seems like a weird design to me. My assumption was that 'execute-facing' provided a 'local coordinates context, regardless of sender' the same way that 'execute-at' provided a 'relative coordinates context, regardless of sender'. What is execute-facing supposed to do?
EDIT
It has also been pointed out that anchor feet/eyes affects how ^^^ works, and thus a sender-entity-less command lacks an anchor. I feel like just assuming a 'null sender' behaves like a zero-tall entity (and thus feet or eyes both anchor to same position) is a reasonable thing to do. (Overall, a strong motivation among command-programmers is to 'reduce entities', and it would be nice to be able to use 'local coordinates' without an entity, which is what I was trying to do, that initially motivated this bug report.)
ANOTHER EDIT
Yeah, there was an idiom of 'entityless raytracing' where you have a recursive function that recurses via e.g.
execute at ^ ^ ^0.1 run function ns:selfwhere in prior snapshots the ^^^ were 'anchored' to the 'at' location. Now if 'anchoring' uses '@s' and '@s' is not moving/teleported in the recursive call, it is unclear to me if/how to realize that useful idiom.
FINAL THOUGHT
I guess overall, I am unclear why 'anchoring' needs to be part of the local context. It seems to me that if "anchor eyes" just behaved the same as "positioned ~ ~N ~" where N was computed based on the value of @s, then this might be good enough? That is, "eyes" becomes shorthand for a @s-mob-lookup-table of eye-height values, but does not add an additional context field to the system, rather it just automatically adjusts y as part of the existing xyz context. Then 'facing' become
ssimple again,itsorigin is always just context's xyz, rather than(current)complicated combination of xyz, anchor setting, and @s value.Put the following command in a command block and activate it:
execute at @p facing ~ ~ ~2 run summon pig ^ ^1 ^5EXPECTED
summons a pig at location ~ ~1 ~5 from the player (at their position, facing positive Z, local ^ ^1 ^5)
ACTUAL
command fails, error in block is:
[14:09:27] An entity is required to run this command hereMore generally, I expect that 'facing' should override subsequent carets, in the same way that `at` or `positioned` override subsequent tildes (and default x=,y=,z= in selectors).
OTHER THOUGHTS
It has been suggested by others that perhaps 'facing' is more like 'teleport @s to point in a new direction', in which case it would require an executor (@s). However that seems like a weird design to me. My assumption was that 'execute-facing' provided a 'local coordinates context, regardless of sender' the same way that 'execute-at' provided a 'relative coordinates context, regardless of sender'. What is execute-facing supposed to do?
EDIT
It has also been pointed out that anchor feet/eyes affects how ^^^ works, and thus a sender-entity-less command lacks an anchor. I feel like just assuming a 'null sender' behaves like a zero-tall entity (and thus feet or eyes both anchor to same position) is a reasonable thing to do. (Overall, a strong motivation among command-programmers is to 'reduce entities', and it would be nice to be able to use 'local coordinates' without an entity, which is what I was trying to do, that initially motivated this bug report.)
ANOTHER EDIT
Yeah, there was an idiom of 'entityless raytracing' where you have a recursive function that recurses via e.g.
execute at ^ ^ ^0.1 run function ns:selfwhere in prior snapshots the ^^^ were 'anchored' to the 'at' location. Now if 'anchoring' uses '@s' and '@s' is not moving/teleported in the recursive call, it is unclear to me if/how to realize that useful idiom.
FINAL THOUGHT
I guess overall, I am unclear why 'anchoring' needs to be part of the local context. It seems to me that if "anchor eyes" just behaved the same as "positioned ~ ~N ~" where N was computed based on the value of @s, then this might be good enough? That is, "eyes" becomes shorthand for a @s-mob-lookup-table of eye-height values, but does not add an additional context field to the system, rather it just automatically adjusts y as part of the existing xyz context. Then 'facing' and carets become simple again, the origin is always just context's xyz, rather than the current complicated combination of xyz, anchor setting, and @s value.
Put the following command in a command block and activate it:
execute at @p facing ~ ~ ~2 run summon pig ^ ^1 ^5EXPECTED
summons a pig at location ~ ~1 ~5 from the player (at their position, facing positive Z, local ^ ^1 ^5)
ACTUAL
command fails, error in block is:
[14:09:27] An entity is required to run this command hereMore generally, I expect that 'facing' should override subsequent carets, in the same way that `at` or `positioned` override subsequent tildes (and default x=,y=,z= in selectors).
OTHER THOUGHTS
It has been suggested by others that perhaps 'facing' is more like 'teleport @s to point in a new direction', in which case it would require an executor (@s). However that seems like a weird design to me. My assumption was that 'execute-facing' provided a 'local coordinates context, regardless of sender' the same way that 'execute-at' provided a 'relative coordinates context, regardless of sender'. What is execute-facing supposed to do?
EDIT
It has also been pointed out that anchor feet/eyes affects how ^^^ works, and thus a sender-entity-less command lacks an anchor. I feel like just assuming a 'null sender' behaves like a zero-tall entity (and thus feet or eyes both anchor to same position) is a reasonable thing to do. (Overall, a strong motivation among command-programmers is to 'reduce entities', and it would be nice to be able to use 'local coordinates' without an entity, which is what I was trying to do, that initially motivated this bug report.)
ANOTHER EDIT
Yeah, there was an idiom of 'entityless raytracing' where you have a recursive function that recurses via e.g.
execute at ^ ^ ^0.1 run function ns:selfwhere in prior snapshots the ^^^ were 'anchored' to the 'at' location. Now if 'anchoring' uses '@s' and '@s' is not moving/teleported in the recursive call, it is unclear to me if/how to realize that useful idiom.
FINAL THOUGHT
I guess overall, I am unclear why 'anchoring' needs to be part of the local context. It seems to me that if "anchor eyes" just behaved the same as "positioned ~ ~N ~" where N was computed based on the value of @s, then this might be good enough? That is, "eyes" becomes shorthand for a @s-mob-lookup-table of eye-height values, but does not add an additional context field to the system, rather it just automatically adjusts y as part of the existing xyz context. Then 'facing' and carets become simple again, the origin is always just context's xyz, rather than the current complicated combination of xyz, anchor setting, and @s value.
(apologies for the update-spam to those following this issue)
REALLY FINAL THOUGHT
18w02a system:
^ ^ ^1 means "origin=xyz, except if anchored=eyes use y=@s height + y instead, then angles=xrot/yrot, compute destination"proposed system:
^ ^ ^1 means "origin=xyz, angles=xrot/yrot, compute destination" (same as prior snapshot)I think the proposed system is much easier to reason about in general. The one thing the proposed system does make slightly more verbose is a scenario like this:
Teleport the player so that his eyes are 1 block closer to coordinate 100,100,100
Here it is each way:
18w02a system:
execute as @p at @s anchored eyes facing 100 100 100 run teleport @s ^ ^ ^1proposed system:
execute as @p at @s anchored eyes facing 100 100 100 at @s run teleport @s ^ ^ ^1Overall, I think 'fewer context variables is a good thing'. Having 'anchored' behave as an immediate offset, rather than a context, makes facing and carets easier to reason about in general, even if it does make certain scenarios slightly more verbose.
Put the following command in a command block and activate it:
execute at @p facing ~ ~ ~2 run summon pig ^ ^1 ^5EXPECTED
summons a pig at location ~ ~1 ~5 from the player (at their position, facing positive Z, local ^ ^1 ^5)
ACTUAL
command fails, error in block is:
[14:09:27] An entity is required to run this command hereMore generally, I expect that 'facing' should override subsequent carets, in the same way that `at` or `positioned` override subsequent tildes (and default x=,y=,z= in selectors).
LATER...
After a few days mulling, I think I grok the purpose of 'anchored' better now. In particular, if I want to use a teleport to change @p's rotation so that he is facing a baby zombie standing over yonder, I see that there are four possible rays (my eyes to zombie eyes, my feet to zombie eyes, my eyes to zombie feet, my feet to zombie feet) which correspond to four distinct angles. 'anchored' provides an incoming context by which to choose the origin (my eyes/feet), and tp's facing argument of eyes/feet provides a way to select the destination.
I guess the current system is fine, except that it would be really nice if, if @s is null, then 'anchored' computations are done 'as if @s were a zero-tall entity', that is eyes=feet, so that entity-less local-coordinates (a useful feature in prior snapshots) are still able to be used. That's the more important part of this bug.
The less important issue is whether 'having anchored as part of the context' is the best design. The current design is convenient for some stuff, but it does complicate the explanation of how ^^^ behaves, and creates the possibility for certain unintended errors (e.g. I author a raycasting function, test it, and it works, and much later discover it fails when called from an 'anchored eyes' context - more generally, the test surface area of any function using local coordinates now has @s-entity-type and anchored-context as implicit extra variables in the test matrix, though the function author can eliminate this complexity, if undesired, by adding 'anchored feet' to the start). An alternative design is just an offset-based one, where new subcommands 'eyesToFeet' and 'feetToEyes' behave as "positioned ~ ~N ~" and "positioned ~ ~-N ~" where N is @s's eye height. Such a design has its own merits and demerits, but it removes the implicit coupling between @s/facing and local coordinates that anchored has. I am no longer sure which design I prefer (or maybe there is another option), but hey, it's not my choices, these are just some thoughts
That said, I had a lot of other muddled thoughts evolve over a couple days, which I will preserve below, but which may not be worth reading.
OTHER THOUGHTS
It has been suggested by others that perhaps 'facing' is more like 'teleport @s to point in a new direction', in which case it would require an executor (@s). However that seems like a weird design to me. My assumption was that 'execute-facing' provided a 'local coordinates context, regardless of sender' the same way that 'execute-at' provided a 'relative coordinates context, regardless of sender'. What is execute-facing supposed to do?
EDIT
It has also been pointed out that anchor feet/eyes affects how ^^^ works, and thus a sender-entity-less command lacks an anchor. I feel like just assuming a 'null sender' behaves like a zero-tall entity (and thus feet or eyes both anchor to same position) is a reasonable thing to do. (Overall, a strong motivation among command-programmers is to 'reduce entities', and it would be nice to be able to use 'local coordinates' without an entity, which is what I was trying to do, that initially motivated this bug report.)
ANOTHER EDIT
Yeah, there was an idiom of 'entityless raytracing' where you have a recursive function that recurses via e.g.
execute at ^ ^ ^0.1 run function ns:selfwhere in prior snapshots the ^^^ were 'anchored' to the 'at' location. Now if 'anchoring' uses '@s' and '@s' is not moving/teleported in the recursive call, it is unclear to me if/how to realize that useful idiom.
FINAL THOUGHT
I guess overall, I am unclear why 'anchoring' needs to be part of the local context. It seems to me that if "anchor eyes" just behaved the same as "positioned ~ ~N ~" where N was computed based on the value of @s, then this might be good enough? That is, "eyes" becomes shorthand for a @s-mob-lookup-table of eye-height values, but does not add an additional context field to the system, rather it just automatically adjusts y as part of the existing xyz context. Then 'facing' and carets become simple again, the origin is always just context's xyz, rather than the current complicated combination of xyz, anchor setting, and @s value.
(apologies for the update-spam to those following this issue)
REALLY FINAL THOUGHT
18w02a system:
^ ^ ^1 means "origin=xyz, except if anchored=eyes use y=@s height + y instead, then angles=xrot/yrot, compute destination"proposed system:
^ ^ ^1 means "origin=xyz, angles=xrot/yrot, compute destination" (same as prior snapshot)I think the proposed system is much easier to reason about in general. The one thing the proposed system does make slightly more verbose is a scenario like this:
Teleport the player so that his eyes are 1 block closer to coordinate 100,100,100
Here it is each way:
18w02a system:
execute as @p at @s anchored eyes facing 100 100 100 run teleport @s ^ ^ ^1proposed system:
execute as @p at @s anchored eyes facing 100 100 100 at @s run teleport @s ^ ^ ^1Overall, I think 'fewer context variables is a good thing'. Having 'anchored' behave as an immediate offset, rather than a context, makes facing and carets easier to reason about in general, even if it does make certain scenarios slightly more verbose.
Put the following command in a command block and activate it:
execute at @p facing ~ ~ ~2 run summon pig ^ ^1 ^5EXPECTED
summons a pig at location ~ ~1 ~5 from the player (at their position, facing positive Z, local ^ ^1 ^5)
ACTUAL
command fails, error in block is:
[14:09:27] An entity is required to run this command hereMore generally, I expect that 'facing' should override subsequent carets, in the same way that `at` or `positioned` override subsequent tildes (and default x=,y=,z= in selectors).
LATER...
After a few days mulling, I think I grok the purpose of 'anchored' better now. In particular, if I want to use a teleport to change @p's rotation so that he is facing a baby zombie standing over yonder, I see that there are four possible rays (my eyes to zombie eyes, my feet to zombie eyes, my eyes to zombie feet, my feet to zombie feet) which correspond to four distinct angles. 'anchored' provides an incoming context by which to choose the origin (my eyes/feet), and tp's facing argument of eyes/feet provides a way to select the destination.
I guess the current system is fine, except that it would be really nice if, if @s is null, then 'anchored' computations are done 'as if @s were a zero-tall entity', that is eyes=feet, so that entity-less local-coordinates (a useful feature in prior snapshots) are still able to be used. That's the
more important partof this bug.The less important issue is whether 'having anchored as part of the context' is the best design. The current design is convenient for some stuff, but it does complicate the explanation of how ^^^ behaves, and creates the possibility for certain unintended errors (e.g. I author a raycasting function, test it, and it works, and much later discover it fails when called from an 'anchored eyes' context - more generally, the test surface area of any function using local coordinates now has @s-entity-type and anchored-context as implicit extra variables in the test matrix, though the function author can eliminate this complexity, if undesired, by adding 'anchored feet' to the start). An alternative design is just an offset-based one, where new subcommands 'eyesToFeet' and 'feetToEyes' behave as "positioned ~ ~N ~" and "positioned ~ ~-N ~" where N is @s's eye height. Such a design has its own merits and demerits, but it removes the implicit coupling between @s/facing and local coordinates that anchored has. I am no longer sure which design I prefer (or maybe there is another option), but hey, it's not my choices, these are just some thoughts
That said, I had a lot of other muddled thoughts evolve over a couple days, which I will preserve below, but which may not be worth reading.
OTHER THOUGHTS
It has been suggested by others that perhaps 'facing' is more like 'teleport @s to point in a new direction', in which case it would require an executor (@s). However that seems like a weird design to me. My assumption was that 'execute-facing' provided a 'local coordinates context, regardless of sender' the same way that 'execute-at' provided a 'relative coordinates context, regardless of sender'. What is execute-facing supposed to do?
EDIT
It has also been pointed out that anchor feet/eyes affects how ^^^ works, and thus a sender-entity-less command lacks an anchor. I feel like just assuming a 'null sender' behaves like a zero-tall entity (and thus feet or eyes both anchor to same position) is a reasonable thing to do. (Overall, a strong motivation among command-programmers is to 'reduce entities', and it would be nice to be able to use 'local coordinates' without an entity, which is what I was trying to do, that initially motivated this bug report.)
ANOTHER EDIT
Yeah, there was an idiom of 'entityless raytracing' where you have a recursive function that recurses via e.g.
execute at ^ ^ ^0.1 run function ns:selfwhere in prior snapshots the ^^^ were 'anchored' to the 'at' location. Now if 'anchoring' uses '@s' and '@s' is not moving/teleported in the recursive call, it is unclear to me if/how to realize that useful idiom.
FINAL THOUGHT
I guess overall, I am unclear why 'anchoring' needs to be part of the local context. It seems to me that if "anchor eyes" just behaved the same as "positioned ~ ~N ~" where N was computed based on the value of @s, then this might be good enough? That is, "eyes" becomes shorthand for a @s-mob-lookup-table of eye-height values, but does not add an additional context field to the system, rather it just automatically adjusts y as part of the existing xyz context. Then 'facing' and carets become simple again, the origin is always just context's xyz, rather than the current complicated combination of xyz, anchor setting, and @s value.
(apologies for the update-spam to those following this issue)
REALLY FINAL THOUGHT
18w02a system:
^ ^ ^1 means "origin=xyz, except if anchored=eyes use y=@s height + y instead, then angles=xrot/yrot, compute destination"proposed system:
^ ^ ^1 means "origin=xyz, angles=xrot/yrot, compute destination" (same as prior snapshot)I think the proposed system is much easier to reason about in general. The one thing the proposed system does make slightly more verbose is a scenario like this:
Teleport the player so that his eyes are 1 block closer to coordinate 100,100,100
Here it is each way:
18w02a system:
execute as @p at @s anchored eyes facing 100 100 100 run teleport @s ^ ^ ^1proposed system:
execute as @p at @s anchored eyes facing 100 100 100 at @s run teleport @s ^ ^ ^1Overall, I think 'fewer context variables is a good thing'. Having 'anchored' behave as an immediate offset, rather than a context, makes facing and carets easier to reason about in general, even if it does make certain scenarios slightly more verbose.
Put the following command in a command block and activate it:
execute at @p facing ~ ~ ~2 run summon pig ^ ^1 ^5EXPECTED
summons a pig at location ~ ~1 ~5 from the player (at their position, facing positive Z, local ^ ^1 ^5)
ACTUAL
command fails, error in block is:
[14:09:27] An entity is required to run this command hereMore generally, I expect that 'facing' should override subsequent carets, in the same way that `at` or `positioned` override subsequent tildes (and default x=,y=,z= in selectors).
LATER...
After a few days mulling, I think I grok the purpose of 'anchored' better now. In particular, if I want to use a teleport to change @p's rotation so that he is facing a baby zombie standing over yonder, I see that there are four possible rays (my eyes to zombie eyes, my feet to zombie eyes, my eyes to zombie feet, my feet to zombie feet) which correspond to four distinct angles. 'anchored' provides an incoming context by which to choose the origin (my eyes/feet), and tp's facing argument of eyes/feet provides a way to select the destination.
I guess the current system is fine, except that it would be really nice if, if @s is null, then 'anchored' computations are done 'as if @s were a zero-tall entity', that is eyes=feet, so that entity-less local-coordinates (a useful feature in prior snapshots) are still able to be used. That's the crux of this bug.
![[Mojang] Nathan Adams](../../../data/assets/gravatar/dinnerbone.png){kind=small}
[Mojang] Nathan Adams
I'd like to note that the workaround to this bug is using `as`, which is not something that should be required for anything related purely to position/rotation. Even if taking advantage of the `anchored` subcommand, the command executor should not be involved (store the height data in the command "source", separate from the executing entity. If there is no entity, make `eyes` the same location as `feet`). I'm not sure if the existence of `anchored` (and the fact that by default it's `feet`, in contrast to being a position) is the cause of this issue, but I did want to throw that out there.