MC-88957JSON signs with scoreboard objectives don't auto update scores
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 100
3. 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 5
Notice 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.
Normal- Works As Intended
Ely G- 28
- 9
- Confirmed
15w38b - 1.11-pre1
15w38b 15w39b 15w39c 15w40a 15w40b 15w41b 15w42a 15w43a 15w44a 15w44b 15w45a 15w46a 15w47a 15w47b 15w47c 15w49a 15w49b 15w50a 15w51a 15w51b 16w02a 16w03a 16w04a 16w05a 16w05b 16w06a 16w07a 16w07b 1.9-pre1 1.9-pre2 1.9-pre3 1.9-pre4 1.9 1.9.1-pre1 1.9.1-pre2 1.9.1-pre3 1.9.1 1.9.2 16w14a 16w15a 16w15b 1.9.3-pre1 1.9.3-pre2 1.9.3-pre3 1.9.3 1.9.4 16w20a 16w21a 16w21b 1.10-pre1 1.11-pre1
Created Issue:
JSON signs with scoreboard objectives don't update scores until world is reloaded
unlike in 1.8, JSON signs with scores in them do not update whenever the score changes; rather they will only update when the world is reloaded or their block data is updated.
Steps to reproduce:
1. Create a new world
{\"text\":\"hi\"}
2. run the following commands:
/scoreboard objectives add hi dummy
/scoreboard players set @p hi 100
3. place a sign down
4. change the block data of the sign to the following:
{Text1:"[\"\",]",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. It only updates to 5 upon world reload, or if the block data is updated. Doing the following steps in 1.8 you should see the sign automatically update to 5.
unlike in 1.8, JSON signs with scores in them do not update whenever the score changes; rather they will only update when the world is reloaded or their block data is updated.
Steps to reproduce:
1. Create a new world
{\"text\":\"hi\"}
2. run the following commands:
/scoreboard objectives add hi dummy
/scoreboard players set @p hi 100
3. place a sign down
4. change the block data of the sign to the following:
{{{Text1:"[\"\",]",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. It only updates to 5 upon world reload, or if the block data is updated. Doing the following steps in 1.8 you should see the sign automatically update to 5.
unlike in 1.8, JSON signs with scores in them do not update whenever the score changes; rather they will only update when the world is reloaded or their block data is updated.
Steps to reproduce:
1. Create a new world
{\"text\":\"hi\"}
2. run the following commands:
/scoreboard objectives add hi dummy
/scoreboard players set @p hi 100
3. place a sign down
4. change the block data of the sign to the following:
{{{Text1:"[\"\",]",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. It only updates to 5 upon world reload, or if the block data is updated. Doing the following steps in 1.8 you should see the sign automatically update to 5.
unlike in 1.8, JSON signs with scores in them do not update whenever the score changes; rather they will only update when the world is reloaded or their block data is updated.
Steps to reproduce:
1. Create a new world
{\"text\":\"hi\"}
2. run the following commands:
/scoreboard objectives add hi dummy
/scoreboard players set @p hi 100
3. place a sign down
4. change the block data of the sign to the following:
{Text1:"[\"\",]",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. It only updates to 5 upon world reload, or if the block data is updated. Doing the following steps in 1.8 you should see the sign automatically update to 5.
unlike in 1.8, JSON signs with scores in them do not update whenever the score changes; rather they will only update when the world is reloaded or their block data is updated.
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. It only updates to 5 upon world reload, or if the block data is updated. Doing the following steps in 1.8 you should see the sign automatically update to 5.
relates to
relates to
unlike in 1.8, JSON signs with scores in them do not update whenever the score changes; rather they will only update when the world is reloaded or their block data is updated.
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.
It only updates to 5 upon world reload, or if the block data is updated.Doing the following steps in 1.8 you should see the sign automatically update to 5.unlike in 1.8, JSON signs with scores in them do not update whenever the score changes. This issue is being reopened due to the fixing of
MC-101457to 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.
JSON signs with scoreboard objectives don't update scoresuntil world is reloadedJSON signs with scoreboard objectives don't auto update scores
unlike in 1.8, JSON signs with scores in them do not update whenever the score changes. This issue is being
reopened due to the fixing ofMC-101457to 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.
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-101457to 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.
![[Mod] violine1101](../../../data/avatars/users/92858.png){kind=small}
relates to
![[Mod] Skylinerw](../../../data/assets/gravatar/skylinerw.png){kind=small}
The value key is meant to be used as a priority display instead of a processed score. For example, given the following score:
/scoreboard objectives add TEST dummy /scoreboard players set @p TEST 1
The following would show "hello" in 1.8, but still shows "1" in 1.9:
/tellraw @a {"score":{"name":"@p","objective":"TEST","value":"hello"}}
/title @a title {"score":{"name":"@p","objective":"TEST","value":"hello"}}
/setblock ~ ~1 ~ standing_sign 0 replace {Text1:"{\"score\":{\"name\":\"@p\",\"objective\":\"TEST\",\"value\":\"hello\"}}",Text2:"[\"\"]",Text3:"[\"\"]",Text4:"[\"\"]"}
/give @p written_book 1 0 {title:"",author:"",resolved:0b,pages:["{\"score\":{\"name\":\"@p\",\"objective\":\"TEST\",\"value\":\"hello\"}}"]}
In 1.9, the book sets value as the player's processed score, overwriting the original value of "hello", and at that point it does work as the priority display. As such, setting resolved to 1 does allow it to work based on my input in 1.9, but it's a feature only available for books (and in 1.8, resolved can be 0 and my inserted value takes precedence):
/give @p written_book 1 0 {title:"",author:"",resolved:1b,pages:["{\"score\":{\"name\":\"@p\",\"objective\":\"TEST\",\"value\":\"hello\"}}"]}
This is likely related to the issue described in MC-88957.
Related to MC-88957 ?
7. Repeat steps in 1.9.3-pre1 or previous versions (You will notice that it now works as intended)
Actually it did not work as intended, due to MC-88957. This was made irrelevant due to this bug, however it was reported as WaI when it is in fact not intended; after all the scores are either supposed to update live or not at all; not on chunk reload
Thanks for the formatting! I wasn't sure how to format commands with NBT in them. How did you do it?
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?
Yes. I think an additional tag is the best solution. Though unlike "resolved", which is set to 1 every time a book is opened, this tag would be static and part of the score JSON format thing, and would determine whether or not to live-update the value.
still a problem in 16w02a
Confirmed for 1.9-pre1
Affects 1.9pre4. Relates to
MC-98224Isn't this rather blocked by
MC-98224, that one states it'll be empty after reload, while this one states it won't updatethe score until reloadThis still applies in the sense that the scores won't update. Just now they won't reload either.
Ely G They don't update automatically for me either (if I trigger the CB manually they update though to the current score).
And upon world reload the signs are indeed blank.. but if I trigger the CB again, it shows the current score again.
Does it not for you? - Sorry if I misunderstood the issue.
Pretty much, yes.
Invalid via
MC-101457. However it may become valid afterMC-101457is fixed, so I'm not sure the best resolution.Scoreboard values on signs do not update on their own.
...They did in 1.8... why all the sudden the WAI resolution?
A dev said it. I'll mark this ticket for review.
k. good to know. Even if they aren't supposed to update (which would be a real shame), they still shouldn't be updating on reload
Would hooking the system up to a clock solve it?
Although it's debatable performance-wise, of course.. but maybe a slow clock, not a RCB?
Constantly replacing the sign will update its contents, yes.
What will happen when this ticket is reviewed?
The developer will reopen, or will leave a comment explaining the resolution.
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
any justification yet as to why this is intended?
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-101457they've decided to go with non updating. I updated the issue in case of further discussion.