JSON requires quotes around the keys in the "/title" and "/tellraw" commands and NBT tags "pages", "Text1" .. "Text4"

it worked fine in 1.8
and for example:

/give @p minecraft:written_book 1 0 {title:"",author:"",pages:["{text:lenient,color:blue}"]}

and

/setblock ~ ~1 ~ minecraft:standing_sign 0 replace {Text1:"{text:lenient,color:blue}"}

works fine, so if it remains this way, there is also inconsistency among json in commands

(can this be changed to the discription too please?(I'd do it myself, and keep this updated if I were to become the reporter))
PS: this happens only for title and tellraw

thank you @unknown

tellraw @a {"text":"","extra":[{"text":"[Matrix Server] ","color":"dark_red","italic":"false"},{"text":"Welcome ","color":"dark_green","italic":"true"},{selector:"@a[team=]"}]}

Worked perfect in 1.8* and now all of a sudden with Snapshot it went an broke it and im stumped if i can see what has been changed, so i agree saying its broken.

So, this is a bug and will be fixed, right?

?

I'd like to add that setblock / nbt "json" has ALWAYS conformed to a custom system and not regular json.

This bug is in 15w31c, please update!

/tellraw @a [{text:"hello"}]

must be

/tellraw @a [{"text":"hello"}]

with the "" around text.
Please update to 15w31c!

tellraw @a[x=64,y=77,z=538,r=3] {color:green, ["text:"Your new bank score is: ",extra:[{score:{name:"*",objective:"bank"}}]]}

Errors Line 1 Coloumn 3 .... is this because of something broken in Snapshot or am i not updating to the code correctly ?

@Warren Liddell It should be

tellraw @a[64,77,538,3] {"color":"green", "text":"Your new bank score is: ","extra":[{"score":{"name":"*","objective":"bank"}}]}

tellraw @a[{"text":"","extra":[{"text":"Lottery Drawn & The Winner Is ","color":"yellow","italic":"true"},{selector:"@a[score_lottery2_min=1]"}]]}

This one dosent work, but at the same time dosent throw any errors even when using " around the selector argument

@Warren Liddell You forgot the space after the initial @a.

Tbh at this stage im winging a lot of this by what you've said and ive found as a lot of the systems i had where done by a prev mod on my server who has since gone MIA, so im trying to fix everything an so far you've proivided the most assistance, so thankyou.

I now have a series of tellraw an title commands working in snapshot, idk if the changes made are indeed an issue or not, but once the added quotes and/or spaces are placed in it all works normally

JSON parsing will be strict everywhere in the game, I recommend not using lenient syntax anywhere anymore.

But... but the backwards compatibility!

In order to maintain backward compatibility, would it not be better to allow the more lenient json parsing, and just to encourage strict JSON adherence, maybe requiring it in new commands that are added to the game (or not, because that might get annoying - though it would encourage people to use strict JSON wherever they're adding new stuff) - I say that because I am currently working on a HUGE redstone project filled with command blocks, all of which use lenient JSON. It would take many hours to rectify this, and I'm not the only one who would be affected by this. Every creation using JSON from 1.8 backwards would stop working, causing even more custom map compatibility issues than 1.5

I would like to point out that writing lenient JSON is bad practice, and I have always been perplexed why people opted to write it in lenient syntax.

Firstly it's faster and easier, and secondly, that's what all the big YouTubers (that I've seen anyway) do. Heck, even the Minecraft Wiki does it with lenient syntax.

Why it should go back: Lots of people do not write code for a living or at all really and it is much easier to simply type in the words (text: extra: etc..). Also, like Julian Chan said, it is much faster.

Why it should stay: Like Ezekiel said, it is bad practice to use lenient syntax.

Easy fix/Improvements: 1 Have command blocks, when you are done with the command automatically put in the "" for you on each word that needs it ("text:", "selector:", "extra:", etc..) so players can still type in lenient syntax but the game automatically corrects it into ... non-lenient syntax? Idk, i'm not a coder.. But I love writing commands which uses the lenient syntax (for minecraft only.. its the only place I use any type of code) 2 As commands/strings/whatever they are called are typed into a command or command block, they are automatically corrected/autoplaced (like notepad++ does with the "" autofill and text autofill, kinda)

If it were possible to reliably convert data written in lenient syntax into strict syntax, the latter would be unnecessary, and probably wouldn't have been created in the first place – what we call lenient would have been considered strict. You already have to use strict syntax in any case where the meaning would be ambiguous. Because of that, it should be possible to convert data in existing worlds into strict syntax, but it would not be possible for the game to automatically convert anything you type into strict syntax. For some commands, it would guess correctly, and for others it would not, and you'd have to sort it out manually anyway. Requiring everything to be in strict syntax in the first place removes the ambiguity, which means less guesswork about why one thing works, and something else mysteriously breaks.

Good point... If the current way (in 1.9) commands like tellraw are read by the game work in 1.8, why was the change made in the first place? Searge did say, "JSON parsing will be strict everywhere in the game, I recommend not using lenient syntax anywhere anymore.", I'm just curious why the change was made in the first place. Maybe it's easier for them?

I thought I already explained that. Strict syntax eliminates ambiguity, making it possible to reliably parse the data. If the data is ambiguous, then there will be cases where it is parsed incorrectly, causing errors. It makes for fragile code that you can't touch or improve without breaking something, because it's dependent on ambiguous behavior. That's what caused so many things that use JSON to break in the snapshots: if you change anything about how the data is read or written, you'll change how the same data is interpreted, and something will break. If the data is unambiguous, then you can reliably transform it without distorting its meaning. Sign text was invisibly corrupted through multiple versions because it was ambiguous, and the consequences were only revealed in these snapshots.

The only alternative to forcing strict syntax would be to never touch anything that uses JSON ever again, or expect any new features to break backwards compatibility. In short, forcing strict syntax is the only way to ensure forwards compatibility with future versions. Otherwise, they'd encounter situations where they'd have to decide between new features and breaking backwards compatibility. The longer they wait to make these kind of changes, the worse the problem becomes.

While I totally agree that it should have been strict JSON from the start, the fact is that that wasn't the case.
I can think of three options:
1 (Hard to implement, solves most issues): Automatically edit all JSON stored in saves from earlier versions to put quotes around keys. This might break some JSON, but most command blocks should survive the disambiguation correctly. From 1.9 on, require strict JSON
2 (easy to implement, screws backward compatibility, still ensuring forward compatibility): Parse JSON strictly, everything else is invalid. This would annoy the hell out of loads of people, but would ensure forward compatibility.
3 (disaster): Keep the lenient JSON, while keeping as much backward compatibility as we'll ever get (definitely no better than updating all the command blocks) while breaking forward compatibility.

I'd go with option 1, option 2 breaks too much old stuff and option 3 is just silly.

To my knowledge,this should work, but doesn't:

/tellraw @a {"color":"aqua", "clickEvent":{"action":"run_command","value":"/setblock 390 56 -532 minecraft:redstone_block"},"text":"Up"},"extra":[{"color":"aqua", "clickEvent":{"action":"run_command","value":"/setblock 388 56 -532 minecraft:redstone_block"},"text":"Down"},{"color":"aqua", "clickEvent":{"action":"run_command","value":"/setblock 394 56 -532 minecraft:redstone_block"},"text":"Forward"},{"color":"aqua", "clickEvent":{"action":"run_command","value":"/setblock 392 56 -532 minecraft:redstone_block"},"text":"Back"},{"color":"aqua", "clickEvent":{"action":"run_command","value":"/setblock 398 56 -532 minecraft:redstone_block"},"text":"Left"},{"color":"aqua", "clickEvent":{"action":"run_command","value":"/setblock 396 56 -532 minecraft:redstone_block"},"text":"Right"}]}

Anything after the "extra" doesn't work

@ThirdOfFive: Your JSON is structured incorrectly; it wouldn't work in previous versions regardless. You closed the JSON completely before adding the "extra" tag. Fixed:

/tellraw @a {"color":"aqua","clickEvent":{"action":"run_command","value":"/setblock 390 56 -532 minecraft:redstone_block"},"text":"Up","extra":[{"color":"aqua","clickEvent":{"action":"run_command","value":"/setblock 388 56 -532 minecraft:redstone_block"},"text":"Down"},{"color":"aqua","clickEvent":{"action":"run_command","value":"/setblock 394 56 -532 minecraft:redstone_block"},"text":"Forward"},{"color":"aqua","clickEvent":{"action":"run_command","value":"/setblock 392 56 -532 minecraft:redstone_block"},"text":"Back"},{"color":"aqua","clickEvent":{"action":"run_command","value":"/setblock 398 56 -532 minecraft:redstone_block"},"text":"Left"},{"color":"aqua","clickEvent":{"action":"run_command","value":"/setblock 396 56 -532 minecraft:redstone_block"},"text":"Right"}]}

You can use find web-based JSON validators to locate structural issues, such as JSONlint.

@Skylinerw Oh... xD

thanks

As Torabi has stated before, the previous system allowed for some ambiguity. For example:

{ c:"d"}

could mean either of the following

{" c":"d"}
{ "c":"d"}

Leaving quotes out of the key names is invalid JSON and really shouldn't even have been used in the first place. If Mojang decides that this is intended, then there is no point in arguing, since it isn't your game to develop.

As far as I know, there is no Minecraft JSON key that is the same as a different key with a space before it. Also, if it shouldn't have been used in the first place, it shouldn't have been allowed in the first place. Finally Minecraft as a game wouldn't have survived without the community, as it is the community that shaped the game and made it as successful as it is today.

sorry, was away on vacation for 2 weeks, thus the inactivity

I understand now why this has been changed, but will other commands like summon, setblock, give, etc also undergo this change? because for example summon only functions with lenient JSON

summon Skeleton ~ ~ ~ {CustomName:Hi}
summon Skeleton ~ ~ ~ {CustomName:"Hi"}

works, and

summon Skeleton ~ ~ ~ {"CustomName":Hi}
summon Skeleton ~ ~ ~ {"CustomName":"Hi"}

doesn't

Whitespace such as spaces and any characters used to define the structure of the data (curly braces, square brackets, commas, colons, etc) can cause ambiguity when used in a key or a value. Quotation marks remove the ambiguity, and were already required in some cases. While strict JSON is certainly more visually cluttered, and can require some extra effort to produce, it reduces confusion, both for the code that has to process it, and for the person writing it. Instead of getting strange errors or unexpected behavior when the parser interprets the data differently than the person expected, or wondering whether quotation marks will be required around a particular value, the answer is simply "always".

For Mojang, this makes future updates easier, because they won't have to make so many exceptions when parsing old data. As I said before, that's what caused signs to break in the snapshots.

@unknown, as @unknown said, "JSON parsing will be strict everywhere in the game". That means all commands will be changed in this way, even though they haven't yet. MC-37661 suggests that strict JSON not being accepted in some commands was a bug, that was then fixed, and now broken again, probably because they switched parsers at some point. In this case, it would probably be better to file a new issue than reopen MC-37661.

@FVbico, @Torabi, NBT data in commands is not JSON, it's a completely separate format.

ok, thanks @unknown that clears it up completely for me, that was the only thing I was still confused about

@unknown it might be, but that doesn't mean it won't get updated

@FVbico, Searge has stated on Skype that the change is concerning the JSON text component specifically. NBT data is not the JSON text component and is a custom format unrelated to it.

yes, tellraw and title (anything using text components) needs to be strict JSON now

@unknown wait, you have @unknown on skype?

Broken Command = Works As Intended. Makes sense.

Its not broken, its just changed now, everyone else has managed to get things working. All my json coding from 1.8 ive long since got it all working in snapshot. There is no use complaigning something is broken when its clearly not.

Could someone help me with this?

/give @p minecraft:compass 1 1 {"display":{"name":"Haunt","color":"dark_red","lore":["Teleport to the nearest survivor"],"color":"dark_red"}}

@ThirdOfFive, NBT data is not JSON and neither the "Name" nor "Lore" tags support the JSON text component currently:

/give @p minecraft:compass 1 0 {display:{Name:"Haunt",Lore:["Teleport to the nearest survivor"]}}

Also note that "true" and "false" are boolean literals and should not be enclosed in quotes.

Now that's going to be confusing.

/setblock ~ ~1 ~ minecraft:standing_sign 0 replace {Text1:"{text:lenient,color:blue}"}

This command setblocks a sign that says: lenient,:color:blue. the text is uncolored. Help?

That is not valid JSON syntax. See http://www.json.org/ for the specification.

I wrote an MCEdit filter to fix command blocks with tellraw or title commands in the lenient syntax. This will not fix commands written in blatantly wrong JSON syntax and will handle ambiguous cases ambiguously.

Nice!

If you leave it like this then you could allow signs and books to have their texts either in String OR Compound.
It would eliminate the need of so many escape characters.

I mean just look at this:

Text1: "{\"text\":\"quote: \\\"HI!\\\"\"}"

It looks like every NBT tag has a static type, so it may not be possible to add, but would be useful.

That's only the tip of the iceberg, Ferenc.
The number of backslashes needed for each quotation mark increases exponentially for each quote within a quote.
It starts with the initial quotation marks. It then, within that, needs 1 backslash per quotation mark, then 3, then 7, then 15, and then 31.
The number of backslashes you need for each quotation mark is double and one more than the number needed previously.
Observe the following command, which gives you a sign that when placed and right-clicked gives you a different sign that, when also placed and right-clicked, gives you yet another sign.
I predict that, following the pattern, if I where to add another sign, I would need 63 backslashes per quotation mark for the Text2: tag of the new sign. I would then need 127 backslashes per quotation mark to format the text on the new sign. Then consider the number of quotation marks I need to do this. That's a lot of backslashes.
I would like to understand why it's like this.

/give nozpqg sign 1 0 
{BlockEntityTag:
{Text2:
"
	{\"text\":\"Backslash Hell\",
	\"color\":\"blue\",
	\"clickEvent\":{
	\"action\":\"run_command\",
	\"value\":
	\"
	/give @p sign 1 0 
	{BlockEntityTag:
	{Text2:
		\\\"
			{\\\\\\\"text\\\\\\\":\\\\\\\"Backslash Hell\\\\\\\",
			\\\\\\\"color\\\\\\\":\\\\\\\"light_purple\\\\\\\",
			\\\\\\\"clickEvent\\\\\\\":{
			\\\\\\\"action\\\\\\\":\\\\\\\"run_command\\\\\\\",
			\\\\\\\"value\\\\\\\":
			\\\\\\\"/give @p sign 1 0 
			{BlockEntityTag:
			{Text2:
				\\\\\\\\\\\\\\\"
					{\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\"text\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\":\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\"Backslash Hell\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\",
					\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\"color\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\":\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\"yellow\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\"}
				\\\\\\\\\\\\\\\"}}
			\\\\\\\"}}
		\\\"}}
	\"}}
"}}

Yeah it's because you have to escape the backslashes themself, too. That's intended and totally okay in a string but with this style it's aweful.

An other way to solve it is to just make every line a Compound and convert simple "text" to {"text":"text"}.

I'm having trouble using Anon Ymus's filter to convert the JSON text in my old maps. It throws an error if the selection size is too large http://i.imgur.com/5Krqz8T.png

What's in the console? Are you sure your commands were all valid lenient JSON before? You can attach the world if you want me to take a look at why it isn't working. I didn't do much testing of the filter.