Entity selectors within a "score" expression in a JSON text behave unexpected, when combining /execute with /data merge.
Behaviour can be reproduced as follows:
1) prepare function with following lines (called test.mcfunction, see attached file):
scoreboard objectives add test_value dummy
scoreboard players set @s test_value 10
setblock ^ ^ ^10 minecraft:sign
tp ^ ^ ^10
execute at @s run data merge block ~ ~ ~ {Text1:"[ {\"text\":\"@s: \"},{\"score\":{\"name\":\"@s\",\"objective\":\"test_value\"}}]"}
execute at @s run data merge block ~ ~ ~ {Text2:"[ {\"text\":\"0.1: \"},{\"score\":{\"name\":\"@e[distance=..0.1,type=armor_stand,sort=nearest,limit=1]\",\"objective\":\"test_value\"}}]"}
execute at @s run data merge block ~ ~ ~ {Text3:"[ {\"text\":\"20: \"},{\"score\":{\"name\":\"@e[distance=..20,type=armor_stand,sort=nearest,limit=1]\",\"objective\":\"test_value\"}}]"}
2) place an armor_stand
3) run function on armor_stand via following command:
/execute as @e[type=minecraft:armor_stand,sort=nearest,limit=1] at @s run function <namespace>:test
Expected behaviour:
objective test_value is created
test_value is set to 10 for the armor_stand
sign is placed 10 blocks in front of armor_stand
armor_stand is teleported to sign
First line on sign should now be set to "@s: 10"
Second line on sign should now be set to "0.1: 10"
Third line on sign should now be set to "20: 10"
Found behviour:
1.-4. As expected
5./6. "score" doesn't seem to find the armor_stand, although the command /data is called by the armor_stand from current position (via /execute) => only the "text" is written in the first two line, no "score"
7. As expected
It seems like the @s-selector isn't properly set during evaluation of the JSON-text. Even when the player, which calls the original function, himself possesses a valid value for test_value, no "score" is expressed.
It further seems like the @e-selector uses the original position of the armor_stand, instead of the current position, contrary to what would be expected when using the /execute at @s command.
Related issues
Attachments
Comments


Please reduce this report to @s
not being considered when resolving text components of signs and create a separate report for the other part. Though it sounds like that might be MC-89667.

@s not being considered for signs is WAI, the sign will resolve the JSON text component, not the command, and as such, @s will give no result as there's no executor.
The same goes for the rest, there's no entity in that range of the sign.

Thanks for the prompt answers.
@FVbico: I wasn't aware that the sign resolves the JSON and not the one who executes the actual command. Thank you for clarifying that!
@Marcono1234: I agree that this is the same problem as in the MC-89667. I didn't realise that this issue was independent of the JSON and as such didn't specify my previous searches correctly...