click events on signs with relative commands are inconsistent
Click events on signs are sometimes processed as the clicking player and sometimes as the sign itself.
To reproduce, put down a sign and put a command block on top of it with the respective command:
/blockdata ~ ~-1 ~ {Text2:"{\"text\":\"\",\"clickEvent\":{\"action\":\"run_command\",\"value\":\"[enter Command here, see below]\"}}"}
Activate the command block, right-click the sign.
Test-cases:
- Command:
/say @p
This outputs "[name] name" of the clicking player, even if another player is closer to the sign.
- Command:
/say @a[c=1]
Same as @p.
- Command
/say @a[c=2]
Outputs the name of right-clicking player in square brackets but states the two closest players to the sign, in order of distance.
- Command
/say @e[c=1]
Same as @p.
- Command
/say @e[c=2]
Outputs the name of the clicking player in square brackets but states the two closest entities to the sign, in order of distance.
- Command
/setblock ~ ~2 ~ gold_block
Sets a gold block 2 blocks above the sign.
- Command
/teleport @p ~ ~2 ~
Teleports the player that clicked the sign 2 blocks above the sign.
These test-cases show an inconsistency in the processing of the commands on signs.
Created Issue:
click event on signs with relative commands are inconsistent
click events on signs are sometimes processed as the clicking player and sometimes as the sign itself.
To reproduce, put down a sign and put a commandblock on top of it with the respective command:
`/blockdata ~ ~-1 ~ {Text2:"{\"text\":\"\",\"clickEvent\":{\"action\":\"run_command\",\"value\":\"/ [enter Command here] \"}}"}`activate the comandblock, rightclick the sign.
Testcases:
Command: `/say @p`
this outputs "[playername] playername" of the clicking player, even if another player is closer to the sign.Command: `/say @a[c=1]`
same as @pCommand `/say @a[c=2]`
outputs the name of rightclicking player in square brackets but states the two closest players to the sign, in order of distance.Command `/say @e[c=1]`
same as @pCommand `/say @e[c=2]`
outputs the name of the clicking player in quare brackets but states the two closest entities to the sign, in order of distance.Command `/setblock ~ ~2 ~ gold_block`
sets a goldblock 2 blocks above the signCommand `/teleport @p ~ ~2 ~`
teleports the player that clicked the sign 2 blocks above the signThese testcases show an inconsistency in the processing of the commands on signs.
click events on signs with relative commands are inconsistent
click events on signs are sometimes processed as the clicking player and sometimes as the sign itself.
To reproduce, put down a sign and put a commandblock on top of it with the respective command:
`/blockdata ~ ~-1 ~ {Text2:"{\"text\":\"\",\"clickEvent\":{\"action\":\"run_command\",\"value\":\"/ [enter Command here] \"}}"}`activate the comandblock, rightclick the sign.
Testcases:
Command: ``/say @p``
this outputs "[playername] playername" of the clicking player, even if another player is closer to the sign.Command: `/say @a[c=1]`
same as @pCommand `/say @a[c=2]`
outputs the name of rightclicking player in square brackets but states the two closest players to the sign, in order of distance.Command `/say @e[c=1]`
same as @pCommand `/say @e[c=2]`
outputs the name of the clicking player in quare brackets but states the two closest entities to the sign, in order of distance.Command `/setblock ~ ~2 ~ gold_block`
sets a goldblock 2 blocks above the signCommand `/teleport @p ~ ~2 ~`
teleports the player that clicked the sign 2 blocks above the signThese testcases show an inconsistency in the processing of the commands on signs.
click events on signs are sometimes processed as the clicking player and sometimes as the sign itself.
To reproduce, put down a sign and put a commandblock on top of it with the respective command:
`/blockdata ~ ~-1 ~ {Text2:"{\"text\":\"\",\"clickEvent\":{\"action\":\"run_command\",\"value\":\"/ [enter Command here] \"}}"}`activate the comandblock, rightclick the sign.
Testcases:
Command:
``/say @p``
this outputs "[playername] playername" of the clicking player, even if another player is closer to the sign.Command: `/say @a[c=1]`
same as @pCommand `/say @a[c=2]`
outputs the name of rightclicking player in square brackets but states the two closest players to the sign, in order of distance.Command `/say @e[c=1]`
same as @pCommand `/say @e[c=2]`
outputs the name of the clicking player in quare brackets but states the two closest entities to the sign, in order of distance.Command `/setblock ~ ~2 ~ gold_block`
sets a goldblock 2 blocks above the signCommand `/teleport @p ~ ~2 ~`
teleports the player that clicked the sign 2 blocks above the signThese testcases show an inconsistency in the processing of the commands on signs.
click events on signs are sometimes processed as the clicking player and sometimes as the sign itself.To reproduce, put down a sign and put a commandblock on top of it with the respective command:
`/blockdata ~ ~-1 ~ {Text2:"{\"text\":\"\",\"clickEvent\":{\"action\":\"run_command\",\"value\":\"/ [enter Command here] \"}}"}`activate the comandblock, rightclick the sign.
Testcases:
Command: `/say @p`
this outputs "[playername] playername" of the clicking player, even if another player is closer to the sign.Command: `/say @a[c=1]`
same as @pCommand `/say @a[c=2]`
outputs the name of rightclicking player in square brackets but states the two closest players to the sign, in order of distance.Command `/say @e[c=1]`
same as @pCommand `/say @e[c=2]`
outputs the name of the clicking player in quare brackets but states the two closest entities to the sign, in order of distance.Command `/setblock ~ ~2 ~ gold_block`
sets a goldblock 2 blocks above the signCommand `/teleport @p ~ ~2 ~`
teleports the player that clicked the sign 2 blocks above the signThese testcases show an inconsistency in the processing of the commands on signs.
Click events on signs are sometimes processed as the clicking player and sometimes as the sign itself.
To reproduce, put down a sign and put a command block on top of it with the respective command:
/blockdata ~ ~-1 ~ {Text2:"{\"text\":\"\",\"clickEvent\":{\"action\":\"run_command\",\"value\":\"[enter Command here, see below]\"}}"}Activate the command block, right-click the sign.
Test-cases:
- Command:
/say @pThis outputs "[name] name" of the clicking player, even if another player is closer to the sign.
- Command:
/say @a[c=1]Same as @p.
- Command
/say @a[c=2]Outputs the name of right-clicking player in square brackets but states the two closest players to the sign, in order of distance.
- Command
/say @e[c=1]Same as @p.
- Command
/say @e[c=2]Outputs the name of the clicking player in square brackets but states the two closest entities to the sign, in order of distance.
- Command
/setblock ~ ~2 ~ gold_blockSets a gold block 2 blocks above the sign.
- Command
/teleport @p ~ ~2 ~Teleports the player that clicked the sign 2 blocks above the sign.
These test-cases show an inconsistency in the processing of the commands on signs.
To clear up what's going on, which is consistent across all commands:
There is a single object containing all information about what is executing the command (I'll refer to it as the "executor"), which is used no matter what the context is for command execution (player-executed, command-block-executed, sign-executed, /execute-executed). Included in that set of data is a "sender", an "origin", a "permission level", a "CommandStats target", and a "display name" (among other things).
MC-80893).MC-62255). Anything that deals with XYZ origins will be dealing with the sign's origin. This allows modifying the clicked sign without knowing where the sign is, and /execute can otherwise be used to change the origin to that of the clicker (by using sender bias described above). Selectors use that origin, which is why the @a[c=2] and @e[c=2] selectors obtain targets starting at the sign (and technically @a[c=1] does too, but see MC-78006 as to why the sender isn't targeted for the other selectors).There are no exceptions for a command being run. The interaction with the executor does not explicitly change if it's a sign versus a command block, player, etc. All that changes is what the data is stored in the "executor" object.