MC-117562Executing a function as an entity doesn't use new sender
Add a function with a command such as setblock ~ ~2 ~ stone or say @s.
In the world place a command block and run the function as a player (or other entity):
/execute @p ~ ~ ~ function foo:bar
The expected behaviour is that a stone block is placed above the nearest player, however, it is placed at the command block instead. As well, using @s in the function does nothing, as the command block is the sender.
Affects similar commands in other contexts as well.
Linked Issues
is duplicated by2
Created Issue:
Executing a function as a player in a command block makes the function execute at the command block
Add a function, with a command such as "setblock ~ ~2 ~ stone"
In the world place a command block and run the function:
/execute @p ~ ~ ~ function foo:barThe expected behavior is that a stone block is placed above the player, however it is placed at the command block instead.
Add a function, with a command such as "setblock ~ ~2 ~ stone"
In the world place a command block and run the function as a player (or other entity):
/execute @p ~ ~ ~ function foo:barThe expected behavior is that a stone block is placed above the player, however it is placed at the command block instead.
Add a function, with a command such as "setblock ~ ~2 ~ stone"
In the world place a command block and run the function as a player (or other entity):
/execute @p ~ ~ ~ function foo:barThe expected behavior is that a stone block is placed above the player, however, it is placed at the command block instead.
Add a function, with a command such as "setblock ~ ~2 ~ stone"
In the world place a command block and run the function as a player (or other entity):
/execute @p ~ ~ ~ function foo:barThe expected behaviour is that a stone block is placed above the player, however, it is placed at the command block instead.
Add a function, with a command such as "setblock ~ ~2 ~ stone"
In the world place a command block and run the function as a player (or other entity):
/execute @p ~ ~ ~ function foo:barThe expected behaviour is that a stone block is placed above the nearest player, however, it is placed at the command block instead.
![[Mod] tryashtar](../../../data/avatars/users/41963.png){kind=small}
Executing a function as aplayerin a command blockmakes the function execute atthe command blockExecuting a function as an entity in a command block uses the command block as sender
Add a function, with a command such as "setblock ~ ~2 ~ stone"
In the world place a command block and run the function as a player (or other entity):
/execute @p ~ ~ ~ function foo:barThe expected behaviour is that a stone block is placed above the nearest player, however, it is placed at the command block instead.
Add a function with a command such as setblock ~ ~2 ~ stone or say @s.
In the world place a command block and run the function as a player (or other entity):
/execute @p ~ ~ ~ function foo:barThe expected behaviour is that a stone block is placed above the nearest player, however, it is placed at the command block instead. As well, using @s in the function does nothing, as the command block is the sender.
Executing a function as an entityin a command block uses the command block assenderExecuting a function as an entity doesn't use new sender
Add a function with a command such as setblock ~ ~2 ~ stone or say @s.
In the world place a command block and run the function as a player (or other entity):
/execute @p ~ ~ ~ function foo:barThe expected behaviour is that a stone block is placed above the nearest player, however, it is placed at the command block instead. As well, using @s in the function does nothing, as the command block is the sender.
Affects similar commands in other contexts as well.
relates to
is duplicated by
![[Mod] Neko](../../../data/avatars/users/92901.png){kind=small}
is duplicated by
![[Mojang] Nathan Adams](../../../data/assets/gravatar/dinnerbone.png){kind=small}
[Mojang] Nathan AdamsThank you for your report!
However, this issue has been closed as a Duplicate of MC-117562.
It has been linked to this report. If you have additional information, please add it to that report.
Please search before reporting, as it's likely that one exists already.
Quick Links:
📓 Issue Guidelines – 💬 Community Support – 📧 Customer Support – 📖 Game Wiki
![[Mod] Pokechu22](../../../data/avatars/users/92931.png){kind=small}
This is written as a feature request, which we don't handle on this tracker (use /r/minecraftsuggestions). That said, check MC-117562; I believe it is the same thing you are describing. The test cases you provide probably could go there.
Attached some images shown in my (duplicate) report: https://bugs.mojang.com/browse/MC-117588
In my report, I tried to get a cow to say hi using the function Tyruswoo:Hi
This worked in 1.12pre1 and 1.12pre2, but in 1.12pre3 it was broken, making me (the executor) say hi. My intent was for the cow (the target of the execute command) to say hi.
The problem is, in 1.12 they added a new type of ICommandSender, let's call it DelegatingCommandSender, which, as the name suggests, delegates to another command sender. It's used by the execute command and functions.
Now, the execute command overrides the ICommandSender.getEntity() method to return the entity matched by the selector, so this mostly works fine. However, in the case that another DelegatingCommandSender delegates to this DelegatingCommandSender, which in turn delegates to the executor of the execute command (in your example the command block), there is a problem.
There is currently an oversight in DelegatingCommandSender. If it's told to delegate to another DelegatingCommandSender, it thinks "oh look! another delegating command sender. That's just delegating somewhere else, there's no point going through it, so I'm just going to bypass it and delegate to its child delegate instead". It does not take into account that the execute command and functions have subclassed DelegatingCommandSender.
So, in conclusion:
That sounds really complex! It seems pretty simple to just let @s refer to the target of /execute, but I guess there are a lot of things going on in the background! Really hope this can be fixed!
By the way, this bypassing of delegation is important to prevent StackOverflowError s from occurring while executing recursive functions. So if you reverse it you break something else, so it's a kind of catch 22.
The solution that springs to my mind is to do away with delegation and, it might be possible to store all the ICommandSender s on a stack instead.
I'm not trying to get recursive functions, myself. I guess some people may want recursive functions, but I'm just looking for the gameLoopFunction to be able to make entities execute functions. That wouldn't involve any recursion. I guess this must involve concerns about recursion, but I'd prefer us not worrying about recursion and just letting the function writer take responsibility for any recursion they cause, as recursion should be fairly obvious--I mean, the function writer will probably notice if they are having functions refer backwards. It's a lot easier to write functions in a "parent to child" fashion so that the gameLoopFunction calls certain functions, which may call other functions, but not recursing backwards. Anyway, so much more we can do if the gameLoopFunction can cause entities to run functions.
If the problem is the risk of Stackoverflow due to recursion, it would just be enough to add a gamerule which defines the maximum number of calls to the children, which would solve the problem.
In case it helps, here is my original description from my (duplicate) bug report:
Summary:
When /execute is used to make an entity run a function, the function is instead run by the source of the /execute command.
Expected outcome:
When /execute is used to make an entity run a function, the function is run by the targeted entity.
Steps to reproduce:
1. Create a function.
2. Run that function as yourself. Note that you run the function.
3. Execute that function to be run by another entity. Note that the entity does not know that it is running the function, as evidenced by @s not working. Instead, the function thinks it is being run by you, because you ran the execute command.
Attached images of this being demonstrated with a Hi function that runs the following command:
say I am @s Hi!
(Note: In Minecraft 1.12 Pre-Release 1 and 1.12 Pre-Release 2, this worked correctly, so that the function would run from the entity targeted by /execute. See attached images.)
This bug greatly reduces the uses of the @s selector. In 1.12 Pre-Release 1 and 1.12 Pre-Release 2, we were able to run the gameLoopFunction to target entities and tell them to run functions. This was great, because it allowed functions to run in an object-oriented fashion, so that commands were executed from their @s source. This bug breaks that feature.
Hoping this can be fixed!
We need recursion at the moment because there is no way to make a loop in a function. All I am saying is that such a seemingly simple fix to this bug here might have dire consequences for recursive functions (as I explained in more detail above). That doesn't mean that this bug can't be fixed, it just means that the fix might be slightly more complex, that's all.
The dilemma they have is they have to fix this bug without breaking
MC-117428again (which is still a bit broken, but that's another story).Just want to throw this in here:
As I was typing that both bugs got fixed haha
Great! Yeah, if both are fixed, that's even better!
Just checked that it works with the Cow Hi test, and uploaded a photo!
Thank you!