Confirmed to happen with:
/tellraw/titleBooks and signs
tellraw and title doesn't work like it used to in 1.8
tellraw @a {text:"this is a text"}
title @a title {text:"this is a title"}this works fine in 1.8, but in the 1.9 snapshots it doesn't.
it the 1.9 snapshots you require
tellraw @a {"text":"this is a text"}
title @a title {"text":"this is a title"}to make it work.
in case of title, 1 worded titles would also work with
title @a title hellobut now needs to be
title @a title {"text":"hello"}this will break a lot of maps made in 1.8, and also gives inconsistency among commands as, 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}"}work fine, so why should tellraw and title have quotes around the keys too?
Linked issues
is duplicated by 90
MC-86769
command block chain
Resolved
MC-83696
Tellraw not functional
Resolved
MC-83760
/title command not working
Resolved
MC-84141
Title and Tellraw command always saying 'Invalid json: malformed JSON at line 1 column 3
Resolved
MC-84234
title command returns malformed json
Resolved
MC-84484
Malformed JSON at line 1 column 4 - Bug or change to JSON text?
Resolved
MC-84538
Tellraw, JSON, Etc.
Resolved
MC-84690
When using /title, It kept saying invalid json
Resolved
MC-84695
Tellraw is still broken.
Resolved
MC-84948
JSON text claims to be invalid
Resolved
MC-84972
Title/Subtitle Bug
Resolved
MC-85078
Json scripts not working! (title and tellraw)
Resolved
MC-85203
Tellraw does not work
Resolved
MC-85251
/tellraw doesnt work in snapshot 15w32a
Resolved
MC-85265
/tellraw is broken
Resolved
MC-85300
setblock command not working with signs
Resolved
MC-85338
Setblock sign json escaping not working correctly
Resolved
MC-85357
/setblock sign text
Resolved
MC-85543
setblock command not working with signs
Resolved
MC-85626
clickable sign is desplaying strange
Resolved
MC-85669
/tellraw Command Not Working On 15w32c
Resolved
MC-85763
Tellraw doesn´t work
Resolved
MC-86006
Tellraw & Title Commands Broken Again (15w33b)
Resolved
MC-86058
NBT Data Tags don't work on signs
Resolved
MC-86120
Cannot use /title command
Resolved
MC-86304
/title: title and subtitle not working
Resolved
MC-86376
In /tellraw, tag names have to be delineated with double quotes.
Resolved
MC-86514
/tellraw commands do not work in latest snapshot
Resolved
MC-86515
Commands involving JSON are not working
Resolved
MC-86557
Command blocks cannot place signs with JSON text
Resolved
MC-86587
Json doesn't work, title and tellraw commands broken
Resolved
MC-86588
command blocks
Resolved
MC-86603
RAW JSON in signs don't work
Resolved
MC-86667
Title command no longer executes, returns JSON error.
Resolved
MC-86704
Tellraw signs wont work apperently. Look at dis pick
Resolved
MC-86717
Title commands don't work
Resolved
MC-86773
Tellraw not working even with the right syntax and json formatting... Am i doing something wrong?
Resolved
MC-86814
title commands still not working did search said resolved
Resolved
MC-86829
tellraw, title and subtitle commands dont work
Resolved
MC-86839
1.9 Snapshots json format not working
Resolved
MC-86882
/title Command will not work!
Resolved
MC-86900
Title/Subtitle JSON format
Resolved
MC-86999
color in command title does not work
Resolved
MC-87051
/title does not work
Resolved
MC-87083
JSON Signs don't work anymore
Resolved
MC-87104
Title and Tellraw "Malformed JSON" bug
Resolved
MC-87105
/tellraw command doesnt seem to work in the latest snapshot, when you use a {text:} tag it says "invalid JSON"
Resolved
MC-87112
JSON in tellraw doesn't respond
Resolved
MC-87255
Tellraw command not working
Resolved
MC-87409
JSON Tag Not working in 15w35b
Resolved
MC-87449
Tellraw is broken again.
Resolved
MC-87477
title/tellraw json is broken
Resolved
MC-87577
/tellraw
Resolved
MC-87579
Bug
Resolved
MC-87601
Malformed JSON on /tellraw
Resolved
MC-87848
JSON text format does not work when text commands (/title, /tellraw) are ran.
Resolved
MC-87980
Json text not working
Resolved
MC-88074
/tellraw and /title always issue
Resolved
MC-88116
commands on 1.9
Resolved
MC-88288
JSON does not work in display Commands.
Resolved
MC-88607
Title / Tellraw Jar bug
Resolved
MC-88658
JSON fails to work
Resolved
MC-88817
15w37a json in tellraw
Resolved
MC-89035
tellraw bug
Resolved
MC-89117
Signs don't change correctly with /blockdata via Json format
Resolved
MC-89148
Cannot display a players score or name on a sign with commands
Resolved
MC-89957
Title Command Not Working
Resolved
MC-90793
/title command
Resolved
MC-90918
Text on Signs Not Working with Block Data Command
Resolved
MC-90935
Tellraw Command Doesn't work
Resolved
MC-91432
Tellraw
Resolved
MC-91503
Tellraw doesn't run and produces error message
Resolved
MC-91546
commands on 1.9
Resolved
MC-91709
/tellraw broken Invalid json: malformed JSON at line 1 column 1
Resolved
MC-92411
Title command does not work
Resolved
MC-92571
JSON fail (/tellraw)
Resolved
MC-92843
The sign with the team is not work. The team is displayed just as text.
Resolved
MC-93184
/tellraw not working
Resolved
MC-93403
Commands Tellraw and title doesn´t work!!!
Resolved
MC-95646
The /tellraw and /title command dont work
Resolved
MC-95837
JSON Parse on tellraw and title commands.
Resolved
MC-95961
cant use command like /title on 16w03a server
Resolved
MC-96767
Command /title is broken
Resolved
MC-96771
Tellraw, title and other commands that use JSON don't work
Resolved
MC-97650
Selector command not working in 1.9
Resolved
MC-98457
JSON Doesn't work in Minecraft 1.9
Resolved
MC-100409
Tellraw and Title command doesn't work
Resolved
MC-100666
the command /title doesn't work
Resolved
MC-135273
When using /title this appears: Invalid chat component. Use JSONReader.setLenient(true) to accept malformed Json
Resolved
MC-232605
Title is only Numberic
Resolved
relates to 3
Comments 58
confirmed for 15w31b when using
tellraw @a {text:"Hi"}which mostly gets used already
it works fine when using
tellraw @a {"text":"Hi"}trough
can this be reopened? this isn't fully fixed yet
But isn't the first not not valid JSON?
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?
[media]?
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.
I'll have to check later because I'm not at my computer ATM. My commands are all valid lenient JSON as they work in 1.8. Of course the commands without JSON aren't valid, but I think the filter ignores those. Some of my worlds also have JSON signs with /blockdata commands in lenient JSON which I don't know if the filter fixes. If we could find a way to PM that would be great.
I'm /u/anonymu on Reddit, if you want to talk there.
Perfect. I have to do some testing though.
It said on the fix version, 15w31b, still not fixed. :<
It was fixed, but is now intended behavior.
This ticket is incomplete. Please review the guidelines before reporting issues.
For technical support please use the Mojang Support Center.
--- This action was performed automatically. If you believe this was done erroneously, please :light_bulb_on: raise an issue.