unlike in 1.8, JSON signs with scores in them do not update whenever the score changes. This issue is being updated due to the fixing of MC-101457 to reconsider the issue of whether scores should autoupdate or not.
Steps to reproduce:
1. Create a new world
2. run the following commands:
/scoreboard objectives add hi dummy
/scoreboard players set @p hi 1003. place a sign down
4. change the block data of the sign to the following:
{Text1:"[\"\",{\"text\":\"hi\"}]",Text2:"[\"\",{\"score\":{\"name\":\"@p\",\"objective\":\"hi\"}}]"}5. run the following command:
/scoreboard players set @p hi 5Notice how the sign's score stays at 100, instead of updating to 5. Doing the following steps in 1.8 you should see the sign automatically update to 5.
Linked issues
relates to 3
Comments 26
Put {code} tags before and after the text.
Go and edit the description of this ticket, then you'll see.
I can confirm that this happens in the last few snapshots. However in 1.8 it was not the case that scores update on their own, rather than they kept the value they resolved to when they were placed or when the blockdata for the given line was changed. Since it is easy to "refresh" the sign with a repeating commandblock containing a blockdata command (or using a clock in general looking back at 1.8) i see the static behaviour we saw until (including) 15w35 as the intended (and preferred from my side) behaviour.
In any case, having the content of the sign change based on chunkloading needs to change.
When I tested it in 1.8 I found that the signs did in fact update the scoreboards live. I think that for signs, scores are much more powerful when allowed to update live, if you think about what scoreboard signs are used for. If the signs didn't update when the chunks reloaded, I might have more reason to believe that this is intended.
After some more testing i can say: We are both right.
Just placing the sign made it react to every change of the assigned scoreboardvalue, just as you said. However, after performing the same actions that currently update the signs (e.g. reloading the chunk) the value is frozen, which happend to me before as well.
My opinion:
I fully disagree with "scores are much more powerful when allowed to update live".
If scores always update according to their selector you can't store numbers like highscores on signs without using fake players or "memory" entities.
The former is not leaving things very dynamic, the later adding unnecessary performance decrease if you need more than one. And both react badly if things get deleted or changed by accident.
Having the number burned into the sign makes it more safe. And as said, with a simple clock (or now repeating commandblock) you can still achieve a constant update. Although i can see how that brings the issue of more performance cost and less flexibility back.
Maybe an additional tag might help? Books have already a "resolved" tag that controls wether or not not update scores/selectors. A simple tag to turn auto-updates on/off might be the best solution?
3 options:
1. Dev changes his mind, ticket is reopened
2. Dev doesn't change his mind, ticket stays resolved and a comment is left explaining the decision
3. Nothing
Performance, most likely. However, I believe the conclusion was that they were never intended to update, and that they did (and still do, in some circumstances) was a side-effect of a different bug that was fixed. The behavior is still inconsistent, since they don't keep their text across a chunk reload, so it's probably going to require some more attention in the future to determine the correct behavior.
Seems like with the fixing of MC-101457 they've decided to go with non updating. I updated the issue in case of further discussion.
Thanks for the formatting! I wasn't sure how to format commands with NBT in them. How did you do it?