JSON requires quotes around the keys in the "/title" and "/tellraw" commands and NBT tags "pages", "Text1" .. "Text4"
Confirmed to happen with:
- /tellraw
- /title
- Books 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 hello
but 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 by90
MC-83696Tellraw not functionalDuplicateMC-83760/title command not workingDuplicateMC-84141Title and Tellraw command always saying 'Invalid json: malformed JSON at line 1 column 3DuplicateMC-84234title command returns malformed jsonDuplicateMC-84484Malformed JSON at line 1 column 4 - Bug or change to JSON text?DuplicateMC-84538Tellraw, JSON, Etc.DuplicateMC-84690When using /title, It kept saying invalid jsonDuplicateMC-84695Tellraw is still broken.DuplicateMC-84948JSON text claims to be invalidDuplicateMC-84972Title/Subtitle BugDuplicateMC-85078Json scripts not working! (title and tellraw)DuplicateMC-85203Tellraw does not workDuplicateMC-85251/tellraw doesnt work in snapshot 15w32aDuplicateMC-85265/tellraw is brokenDuplicateMC-85300setblock command not working with signsDuplicateMC-85338Setblock sign json escaping not working correctlyDuplicateMC-85357/setblock sign text DuplicateMC-85543setblock command not working with signsDuplicateMC-85626clickable sign is desplaying strangeDuplicateMC-85669/tellraw Command Not Working On 15w32cDuplicateMC-85763Tellraw doesn´t workDuplicateMC-86006Tellraw & Title Commands Broken Again (15w33b)DuplicateMC-86058NBT Data Tags don't work on signsDuplicateMC-86120Cannot use /title commandDuplicateMC-86304/title: title and subtitle not workingDuplicateMC-86376In /tellraw, tag names have to be delineated with double quotes.DuplicateMC-86514/tellraw commands do not work in latest snapshotDuplicateMC-86515Commands involving JSON are not workingDuplicateMC-86557Command blocks cannot place signs with JSON textDuplicateMC-86587Json doesn't work, title and tellraw commands brokenDuplicateMC-86588command blocksDuplicateMC-86603RAW JSON in signs don't workDuplicateMC-86667Title command no longer executes, returns JSON error.DuplicateMC-86704Tellraw signs wont work apperently. Look at dis pickDuplicateMC-86717Title commands don't workDuplicateMC-86769command block chainDuplicateMC-86773Tellraw not working even with the right syntax and json formatting... Am i doing something wrong?DuplicateMC-86814title commands still not working did search said resolvedDuplicateMC-86829tellraw, title and subtitle commands dont workDuplicateMC-868391.9 Snapshots json format not workingDuplicateMC-86882/title Command will not work!DuplicateMC-86900Title/Subtitle JSON formatDuplicateMC-86999color in command title does not workDuplicateMC-87051/title does not workDuplicateMC-87083JSON Signs don't work anymoreDuplicateMC-87104Title and Tellraw "Malformed JSON" bugDuplicateMC-87105/tellraw command doesnt seem to work in the latest snapshot, when you use a {text:} tag it says "invalid JSON"DuplicateMC-87112JSON in tellraw doesn't respondDuplicateMC-87255Tellraw command not workingDuplicateMC-87409JSON Tag Not working in 15w35bDuplicateMC-87449Tellraw is broken again.DuplicateMC-87477title/tellraw json is brokenDuplicateMC-87577/tellrawDuplicateMC-87579BugDuplicateMC-87601Malformed JSON on /tellrawDuplicateMC-87848JSON text format does not work when text commands (/title, /tellraw) are ran.DuplicateMC-87980Json text not workingDuplicateMC-88074/tellraw and /title always issueDuplicateMC-88116commands on 1.9DuplicateMC-88288JSON does not work in display Commands.DuplicateMC-88607Title / Tellraw Jar bugDuplicateMC-88658JSON fails to workDuplicateMC-8881715w37a json in tellrawDuplicateMC-89035tellraw bugDuplicateMC-89117Signs don't change correctly with /blockdata via Json formatDuplicateMC-89148Cannot display a players score or name on a sign with commandsDuplicateMC-89957Title Command Not WorkingDuplicateMC-90793/title commandDuplicateMC-90918Text on Signs Not Working with Block Data CommandDuplicateMC-90935Tellraw Command Doesn't workDuplicateMC-91432TellrawDuplicateMC-91503Tellraw doesn't run and produces error messageDuplicateMC-91546commands on 1.9DuplicateMC-91709/tellraw broken Invalid json: malformed JSON at line 1 column 1DuplicateMC-92411Title command does not workDuplicateMC-92571JSON fail (/tellraw)DuplicateMC-92843The sign with the team is not work. The team is displayed just as text.DuplicateMC-93184/tellraw not workingDuplicateMC-93403Commands Tellraw and title doesn´t work!!!DuplicateMC-95646The /tellraw and /title command dont workDuplicateMC-95837JSON Parse on tellraw and title commands.DuplicateMC-95961cant use command like /title on 16w03a serverDuplicateMC-96767Command /title is brokenDuplicateMC-96771Tellraw, title and other commands that use JSON don't workDuplicateMC-97650Selector command not working in 1.9DuplicateMC-98457JSON Doesn't work in Minecraft 1.9DuplicateMC-100409Tellraw and Title command doesn't workDuplicateMC-100666the command /title doesn't workDuplicateMC-135273When using /title this appears: Invalid chat component. Use JSONReader.setLenient(true) to accept malformed JsonDuplicateMC-232605Title is only NumbericDuplicaterelates to5
MC-82968Kicked from server when in certain area: com.google.gson.stream.MalformedJsonException: Use JsonReader.setLenient(true) to accept malformed JSON at line 1 column 1FixedMC-83088Title command requires text to be wrapped in JSONWorks As IntendedMC-87143Setblock signs with text put "null" on empty lines by reloading the worldFixedMC-87587Server kicks client when executing: /title @a title [] or tellraw @a []FixedMC-93094Strict JSON does not work for most NBT data.Invalid
Created Issue:
Tellraw is completely broken!
Environment
Not sure about Singleplayer but tellraw is completely broken
![[Bot] Arisa](../../../data/assets/gravatar/mustek2.png){kind=small}
is duplicated by
Tellrawis completely broken!/tellraw requires quotes around JSON keys
is duplicated by
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 requiretellraw @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?
/tellraw requiresquotes around JSON keys/tellraw and /title require quotes around JSON keys
Not sure about Singleplayer but tellraw is completely broken
is duplicated by
is duplicated by
relates to
is duplicated by
is duplicated by
relates to
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
/tellraw and /titlerequire quotes aroundJSONkeysJSON requires quotes around the keys
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
![[Mojang] Searge (Michael Stoyke)](../../../data/assets/gravatar/searge.png){kind=small}
[Mojang] Searge (Michael Stoyke)is duplicated by
Confirmed to happen with:
- /tellraw
- /title
- Books 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 requiretellraw @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?
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
I agree. What really annoys me is that it isn't consistent, either. Trying to type a /tellraw command is absolute hell, as I don't know which parts need to be in quotes, and which don't.
An update that completely changes a perfectly OK system into a tedious, headache-inducing one that's technically better but painful to use?
I'm not saying that his has Microsoft written all over it, but...
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
![[Mod] Torabi](../../../data/assets/gravatar/torabi.png){kind=small}
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
relates to
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
relates to
JSON requires quotes around the keys in the "/title" and "/tellraw" commands and NBT tags "pages", "Text1" .. "Text4"
relates to
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
R.I.P. me ever learning to use json, ive spent a week trying to get this working and im now done, I just found this was the issue, and it now is almost certain to make it into the official 1.9 since it's in pre release 2.
is duplicated by
is duplicated by
is duplicated by
relates to
relates to
![[Mod] tryashtar](../../../data/avatars/users/41963.png){kind=small}
is duplicated by
is duplicated by
Dupe of MC-83460
Dupe of MC-83460
Dupe of MC-83460
Malformed JSON. MC-83460
Malformed JSON. MC-83460
Dupe of MC-83460
Dupe of MC-83460
WAI. You now need quotes around the keys as JSON is now strict. MC-83460
Dupe of MC-83460.
You now need quotes around the keys as JSON is now strict.
Dupe of MC-83460
Per MC-83460, quotes are now required around the keys.
WAI. Per MC-83460, you now need quotes around the keys.
WAI. Per MC-83460, you now need quotes around the keys.
see MC-83460
see MC-83460
Duplicate of MC-83460, which is resolved as Works as Intended, not Fixed. Use quotes around your keys.
Duplicate of MC-83460 – If you searched the tracker before creating this report, and were unable to find the indicated ticket, please comment with the keywords you searched for so that the original report can be improved.
see MC-83460, it's about all keys in tellraw and title
Dupe of MC-83460
WAI. Per MC-83460, you now need quotes around the keys.
Duplicate of MC-83460.
WAI. Per MC-83460, you now need quotes around the keys.
Duplicate of MC-83460 – If you searched the tracker before creating this report, and were unable to find the indicated ticket, please comment with the keywords you searched for so that the original report can be improved.
To the second point, that is MC-83460
You require quotes around all json keys and values
tellraw @a
This has been reported a lot of times, please search before submitting a issue
MC-83460
WAI. Per MC-83460, you now need quotes around the keys.
53rd dupe of MC-83460
54th duplicate of MC-83460
Dupe of MC-83460
Do you have an example of the scoreboard objective ? Thinking about MC-83460.
After having this issue: Please attach the complete output of the "Game Output (Your Minecraft name) " which can be found on the fourth tab of the launcher to this ticket (or the server log, if that's a multiplayer world)
If the launcher closes after game start, please edit your profile and select "Launcher visibility" then, "Keep the launcher open".
tellraw and title now require strickt json, see MC-83460
WAI. Per MC-83460, JSON now requires quotes around the keys.
Dupe of MC-83460. Quotes are now required around the keys.
![[Mod] Neko](../../../data/avatars/users/92901.png){kind=small}
Dupe of MC-83460
Cough cough MC-83460
Dupe of MC-83460. You now need quotes around the keys.
You need to stricktify your json in the sign's Text1/2/3/4 tags, see MC-83460
You didn't read MC-83460 at all, did you
Use
/blockdata ~ ~1 ~ {Text1:"{\"text\":\"1\",\"clickEvent\":{\"action\":\"run_command\",\"value\":\"say Hello World!\"},\"bold\":\"true\"}",Text2:"{\"text\":\"2\",\"bold\":\"true\"}",Text3:"{\"text\":\"3\",\"bold\":\"true\"}",Text4:"{\"text\":\"4\",\"bold\":\"true\"}"}
![[Mod] NeunEinser](../../../data/avatars/users/39263.png){kind=small}
This issue is related to MC-83460
In the issue above it is clearly said that with 1.9 lenient JSON will be gone. Honestly, I hate this change a lot (welcome to backslash hell), but however so far only JSON texts (like in /tellraw or /title or a bok or a sign) can be written in strict JSON.
If JSON has to be written in a strict JSON format in future versions, I want to do this as soon as possible.
If I try the following command, it will not work, although it is strict JSON.
/give @a minecraft:sign 1 0 {"display":{"Name":"JSON"}}
However, it does work like this:
/give @a minecraft:sign 1 0 {display:{Name:"JSON"}}}
or even without any quotes:
/give @a minecraft:sign 1 0 {display:{Name:JSON}}
When I however want to do a /tellraw I need to do strict JSON (as inttended).
/tellraw @a {"text":"I like blue","color":"blue"}
If I want to add this text in JSON format into my book, I need to mix different JSON parsing.
/give @a minecraft:sign 1 0
{
display:
{
Name:"JSON"
},
BlockEntityTag:
{
Text1:
"{
\"text\":\"I like blue\",
\"color\":\"blue\"
}"
}
}
It becomes even more weird when I now add a clickEvent which gives me a book called JSON that has some JSON-text in it. See:
/give @a minecraft:sign 1 0
{
display:
{
Name:JSON
},
BlockEntityTag:
{
Text1:
"{
\"text\":\"Wanna have a\",
\"color\":\"blue\",
\"clickEvent\":
{
\"action\":\"run_command\",
\"value\":
\"
/give @p minecraft:written_book 1 0
{
title:JSON,
author:me,
pages:
[
\\\"
{
\\\\\\\"text\\\\\\\":\\\\\\\"Welcome to the backslash-hell (\\\\\\\\\\\\)\\\\\\\",
\\\\\\\"color\\\\\\\":\\\\\\\"dark_red\\\\\\\"
}
\\\"
]
}
\"
}
}",
Text2:
"{
\"text\":\"book?\",
\"color\":\"blue\"
}"
}
}
In the middle of it I have to use for the book's NBT again lenient JSON. An I am not able to use quotes there. This is inconsistent.
I would prefer it much if you could lenient JSON again (seriously look at the amount of backslashes!). But Mojang must have big reasons top change it. But it's a bug that you can't use strict JSON everywhere.
I hope minecraft will move to slash heaven soon again. But let's make it consistent at first. Otherwise the change simply makes no sense at all.
Dupe of MC-83460. Quotes are now required around the keys.
![[Mod] Skylinerw](../../../data/assets/gravatar/skylinerw.png){kind=small}
Duplicate of MC-83460.
HeroBrineNZK : This issue is already resolved as Duplicate of MC-83460, so if you want to give any updates, do it on MC-83460 instead. BUT this issue was resolved as "Works as intended" by mojang. This mean that mojang is aware of this issue, and consider it being an intended behaviour (they do have sufficient reasons on this one), so it won't be fixed, and you don't have to give any updates.
I see some invalid JSON around here :
{"text":" has just earned the achievement",color:white}
see MC-83460
This is intended, the letinent syntax is being removed, use strict JSON from now on, see MC-83460
Please use the search function in the future
looks like MC-83460, you require quotes around both the key's and their values now
![[Bot] Arisa](../../../data/avatars/users/43007.png){kind=small}
Thank you for your report!
We're tracking this issue in MC-83460, so this ticket is being resolved and linked as a duplicate.
That ticket has already been resolved as working as intended, which means this is not considered a bug and won't be fixed. Please do not leave a comment on the linked ticket.
If you haven't already, you might like to make use of the search feature to see if the issue has already been mentioned.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
– I am a bot. This action was performed automatically! The ticket was resolved by one of our moderators, and I left this message to give more information to you.
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
raise an issue.
https://twitter.com/SeargeDP/status/626445233765658624
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 Anon Ymus
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.
user-f2760, as [Mojang] Searge (Michael Stoyke) 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-37661suggests 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 reopenMC-37661.@FVbico, @Torabi, NBT data in commands is not JSON, it's a completely separate format.
ok, thanks [Mod] Torabi that clears it up completely for me, that was the only thing I was still confused about
[Mod] Skylinerw 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.
[Mod] Skylinerw wait, you have [Mojang] Searge (Michael Stoyke) 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:
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.