Setblock signs with text put "null" on empty lines by reloading the world

Confirmed for

• 15w35e when copying sign with NBT data

The problem is that Minecraft defaults not existing Text entries to "null":

{
	Text1:"{\"text\":\"Hello !\"}",
	Text2:"null",
	Text3:"null",
	Text4:"null"
}

However this is invalid as it now uses always JSON to store text on a sign, so when placing a copied sign or realoading a world, it thinks that the sign displays

Hello!
null
null
null

and transforms every entry that is not in JSON format to JSON format:

{
	Text1:"{\"text\":\"Hello !\"}",
	Text2:"{\"text\":\"null\"}",
	Text3:"{\"text\":\"null\"}",
	Text4:"{\"text\":\"null\"}"
}

Note: This also happens when you provide an empty string as value however placing a sign without NBT data acts different as it automatically uses the JSON format there

Confirmed for 15w40b.
Marcono is correct, setting blank lines to "{\"text\": \" \"}", will stop this from occurring. It only occurs when you have text and blank lines not using JSON.
The bug happens when you unload the sign as well as when you leave the world.

Confirmed also for 15w42a.
Edit: e.g. instead of:

setblock ~ ~1 ~ wall_sign 0 replace {
Text2:"{\"text\":\"OAK\",\"color\":\"dark_green\",\"bold\":true}"}

I've got to insert:

setblock ~ ~1 ~ wall_sign 0 replace {
Text1:"{\"text\":\"\"}",
Text2:"{\"text\":\"OAK\",\"color\":\"dark_green\",\"bold\":true}",
Text3:"{\"text\":\"\"}",
Text4:"{\"text\":\"\"}"}

for "null" to not appear on the empty sign lines.

I can confirm this for 15w47a

Are there currently any cases if you are not coming from a snapshot where this happens? If so, could you guys please give the command used, the source-version and the version last loaded in?

For me, it doesn't matter whether the world was already created in a 1.7.x release, a 1.8.x release, a 1.8 snapshot or a 1.9 snapshot version.
In all cases the sign shows "null".

Command used: See my comment 2 above yours.

@unknown what you are asking for rather sounds like MC-85627

Like I said in my comment above commands placed by setblock still default empty lines to "null". This was also the case in 1.8.8

Confirmed for

• 15w47c

@@unknown:
Yes.
Source version: 15w47c
Last version: 15w47c
Command used:

/setblock ~ ~ ~ minecraft:standing_sign 0 replace {Text1:"Hello !"}

Affected world attached: ^sign-null.zip

It now only accepts proper json for each line and each line has to exist.
It will show as an empty sign otherwise.

Grum, that sadly did not solve the problem 😞

The problem is that empty lines are replaced with "null" which is of course not proper json. This means every sign which is placed using /setblock or /fill and that has not all lines set will have its text removed after reloading the world.

Confirmed for

• 15w51b

The reason for this is , that the readFromNBT(NBTTagCompound compound) method of the net.minecraft.tileentity.TileEntitySign class (MCP 1.8 names) receives null as parsed IChatComponent.

public void readFromNBT(NBTTagCompound compound)
{
	this.isEditable = false;
	super.readFromNBT(compound);
	
	//...
	
	for (int var3 = 0; var3 < 4; ++var3)
	{
		String var4 = compound.getString("Text" + (var3 + 1));

		try
		{
			IChatComponent var5 = IChatComponent.Serializer.jsonToComponent(var4);
			
			// Added this
			if (var5 == null) var5 = new ChatComponentText("");

			try
			{
				this.signText[var3] = ChatComponentProcessor.func_179985_a(var2, var5, (Entity)null);
			}
			catch (CommandException var7)
			{
				this.signText[var3] = var5;
			}
		}
		catch (JsonParseException var8)
		{
			this.signText[var3] = new ChatComponentText(var4);
		}
	}
	
	//...
}

@@unknown: Example command?

@unknown That's exactly what Mr. Broes/Grum said though.
Basically: "All sign lines need to exist, or it'll return COMPLETELY EMPTY now instead of that "null" thing". - and that's the fix.

I'm also not happy with the "fix", or rather I can't understand why one has to reference ALL sign lines now; it makes signs too pricey/uses up too many characters.
Is that what "strict JSON" means?

Again, command example; instead of:

setblock ~ ~1 ~ wall_sign 0 replace {
Text2:"{\"text\":\"GREEN\",\"color\":\"dark_green\",\"bold\":true}"}

I've got to insert:

setblock ~ ~1 ~ wall_sign 0 replace {
Text1:"{\"text\":\"\"}",
Text2:"{\"text\":\"GREEN\",\"color\":\"dark_green\",\"bold\":true}",
Text3:"{\"text\":\"\"}",
Text4:"{\"text\":\"\"}"}

Before, if I wouldn't reference all sign lines, (null) would appear on those not referenced lines on relog into the world.
Now it returns the whole sign completely empty on relog.

Pics attached.

Re-emphasized @unknown's comment:

It now only accepts proper json for each line and each line has to exist.
It will show as an empty sign otherwise.

@unknown I'm aware of that, that's exactly what my last comment said, that Mr. Broes said it would return empty if not each line is referenced.
I'll use more direct words to make myself clear:

I was pointing out that it doesn't seem like a >>>real fix<<< to me, but more like a "hack".
And was asking if "strict JSON" means each line MUST be referenced - which would make the "fix" not seem a "hack", but the sole possible solution of that bugfix.

That's the only thing I'd like to know - if there'd be a better bugfix solution which is not done yet due to time or general issues, hence that seemingly "hack".
E.g. preferred outcome: Not all lines have to be referenced, like it was in 1.8.x - or if that's not possible as it would conflict with what "strict JSON" means (about which I don't have a clue at all minecraftcodingwise; I'm only an user of it).

Flagged for review.

Yes, sorry I kind of skipped this part by accident. However this really does not solve the problem, like @unknown said in 1.8 not all lines had to be referenced. This means in 1.9 about 90% of the commands placing signs will not work anymore. The fix provided should solve this.
Edit: This also causes MC-87281

Personally, I'm not so much worried about old 1.8 signs showing up empty all of a sudden in 1.9.
As we got so many new cool commands and additional CommandBlocks, surely many maps have to be redone for 1.9 anyway, just think e.g. of all the laggy fillclocks we can get rid of.
Which means 1.8 maps will remain 1.8 maps, and for 1.9 considerate mapmakers will change their whole machinery/CommandBlocks as well as commands setup to make things easier for them, better, also for the sake of the players of their maps.

My concerns are mainly the "why clog up the commands and use more characters than seemingly needed".
It's bad enough we've got to use strict JSON which uses up already many more characters, so, if possible, it'd be nice if not each line has to be referenced, like in 1.8 - which would, of course, also possibly result in old 1.8 signs still working in 1.9, as @unknown mentioned.

@unknown the amount of characters used should not be the first priority in my opinion. I thought this way before as well, but knowing all exceptions for String escaping in NBT commands is just too complicated so escaping properly is way easier and also produces less problems.

The reason why they made strict JSON necessary is reasonable. This lenient JSON parsing is only something that Gson (Google's JSON parser) supports. It is not defined in the official standard. This means they would be bound to Gson and could never switch the parser they are using (and there are again all kind of exceptions when quotation is needed and when not).

And it also does not affect upgrading from 1.8 to 1.9. This works fine.

@unknown Thank you for the explanation regarding JSON/Gson!
It's good that it doesn't affect going from 1.8 to 1.9 }=) - but I could swear it was an issue in a previous snapshot, as "null" appeared for me on signs from older versions.
Might be I'm mistaken and I set those signs in an older 1.9 snapshot right before the change to strict JSON.

Whether or not the amount of characters shouldn't be the first priority depends on the perspective.
Whether one likes or despises misleadingly so-called "One Command" contraptions or not, they are a big thing since a while in the commandblocking community, and quite often those things that are loved or sought-after by the community or their mapmakers or minigames servers, are being supported (I'm assuming hence e.g. new CommandBlocks/commands + positioning of items in headslot of ArmorStands), to uphold the popularity of Minecraft.

Those strict JSON signs are very "pricey" as for the needed characters.

So, no matter if I personally support "one command" things or not, for the sake of Minecraft's popularity I guess it's reasonable to support the current "trend" in CommandBlocking.

Also, we shouldn't forget it's not just fancy stuff that can be done with those stacked commands, but also major and foremost easy changes in maps, so it's also a really good utility/tool.
Thus keeping some often needed commands small in the amount of to-be-used characters doesn't seem wrong to me.

Of course, the related bugpost that you linked that is being caused by this seems severe and important enough so that a reopening of this very bugpost and finding another solution for a fix should be considered, no matter what other motivations there could be as of why having to reference also not needed sign lines.

Is this report still flagged for review?

It is not.

The data required by the sign is changed, if there is an upgradepath issue other than with the commands to set it (with an invalid/incomplete set of data) I can look into it.

@unknown have you considered using the fix provided in this comment?