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.
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?
WubbiConcepts
MC-44890![[Mojang] Nathan Adams](../../../data/assets/gravatar/dinnerbone.png){kind=small}
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.
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?
Happened to me in 15w47c as well.