mojira.dev
MC-279273

Setblock/fill does not update client rendering when only block entity data is changed

The server will not send client new information on a block if its visual changes have to do with block entity data, if only block entity data was being changed, and if it was changed via /setblock or /fill. In particular, signs and campfires will not change text/shown items, but there may be other blocks that I haven't thought of in which it is possible to only change block entity data and expect a visual difference.

To replicate this issue, create a sign with any text. Then use F3 + I to copy that sign's exact data, make any change to the text of the sign (or anything other block entity data that has a visual change), and run the command. As far as the server is concerned, all is well, but the client never receives the new information about the sign until prompting the server to do so via either leaving and re-entering draw distance or rejoining.

Block entity data of a sign with the problem in question:

[media]

What the sign looks like, with coordinate confirmation:

[media]

Linked issues

Attachments

Comments 5

You say to run a command, what command?

The modified command copied to the clipboard when using F3 + I.

For me, this will work:

 

/data merge block 33 101 -4 {front_text: {messages:[{text:"hi"}]}}

 

I'm pretty sure I know why this is true: It seems to me that the list of messages (lines) on a sign must either be all simple text or all compound text. The following seem both to be legal 'messages' values:

["", "hi", "there", ""]

[{text: ""}, {text: "hi"}, {text: "there"}, {text: ""}] 

When you create a sign, it starts out with plaint text: ["", "", "", ""]. But when you subsequently try to set a specific line to a compound object, such as to have a click_action, that is considered improper, and is rejected, pretty much silently.

So right now, the only way to have a sign with a compound text is to set all the lines to compound text, you can't just change one.

I should note that while there is a workaround, it is quite ugly. In effect, it means that unless you know in advance whether there is any compound text, you really don't know how to set text on a sign successfully unless you want to set it all.

Actually, I take it back, I can't find a real workaround. I just noticed that the sign lines are converted to simple text if they are all basic compound nodes (with only a 'text' field). So I cannot set up my sign to use compound text for when I add a click_action to it. I am restricted to simple text, or compound tags with at least one non-simple compound tag.

This means that my two example legal values are only sorta true. The compound one is legal when setting, but it converts to the simple one automatically.

But the following isn't even syntactically legal:

/setblock 34 101 -4 pale_oak_wall_sign[]{front_text:{messages:["", {text: "hi"}, "there", ""]}}

I can do this:

/setblock 34 101 -4 pale_oak_wall_sign[]{front_text:{messages:[{text: ""}, {text: "hi"}, {text: "there"}, {text: ""}]}}

But then look at the output of /data get block 34 101 -4:

[22:55:12] [Render thread/INFO]: [System] [CHAT] 34, 101, -4 has the following block data: {back_text: {has_glowing_text: 0b, color: "black", messages: ["", "", "", ""]}, is_waxed: 0b, x: 34, y: 101, z: -4, id: "minecraft:sign", front_text: {has_glowing_text: 0b, color: "black", messages: ["", "hi", "there", ""]}}

Now it's all simple text.

(Let me say that I think the stuff you're doing to eliminate the special JSON syntax is very cool, this is just one of the edges that needs cleaning up, but generally, THANKS!)

Lizard16

(Unassigned)

Unconfirmed

(Unassigned)

25w02a

25w03a

Retrieved