textutils.serializeJSON keys are in qoutes

[Lion4ever]

Reproduce:
-Summon a cow
-run commands.entitydata("@e[r=10]",{Motion={0.0001,1.8,1.8}})
Expected result:
-cow flying into the distance
Real result:
NBT of cow: {"Motion":[0.00001,1.8,1.8],Motion:[0,0,0]}

[Lion4ever]

Side Note: I used 0.0001 because it need to be a double and would not work with an integer

[Wojbie]

This is related to this:
http://www.computercraft.info/forums2/index.php?/topic/22279-cc173ssp-textutilsserializejson-broken-for-datatags/page__fromsearch__1
And possibly this:
http://www.computercraft.info/forums2/index.php?/topic/23892-173libraries-textutilsserializejson-does-not-handle-some-non-printable-characters-correctly/page__fromsearch__1

[dan200]

ok, so here's the issue:

The JSON specification (http://www.json.org/) defines that object keys must be quoted strings. So textutils.serializeJSON() is correct here. Many Minecraft commands (ie. /tellraw), obey this specification, and expect and accept objects in this format.

However, some older commands (such as /setblock), expect their data in a bastardised, incorrect JSON format. I could provide an option for serializeJSON to emit strings in this format, but when autoconverting tables, commands.blah() wouldn't know which one to use.

Unsure what to do here.

[dan200]

More info on the differences here:
http://minecraft.gamepedia.com/Commands#Raw_JSON_text (JSON)
http://minecraft.gamepedia.com/Commands#Data_tags (Not JSON)

[Lion4ever]

what are the options?
-hardcode the qotation option based on the commands method called
-no quotations and the user has to provide ""strings like this""
-add an option to the serializeJSON Method
-file a minecraft bug report like this one, for the old methods: https://bugs.mojang.com/browse/MC-83460

[dan200]

Ok, decided on a solution:

The signature of serialiseJSON is now:
textutils.serializeJSON( value, bNBTStyle )
If the second parameter is true, quotes are stripped from object keys, it defaults to false.

When the autogenerated commands.blah() methods encounter tables, they serialise by passing in true, except for the methods "tellraw" and "title", as the wiki incates that those are the only two methods which use proper, non-bastardised JSON.

These changes will be in 1.76pr4.

[Lion4ever]

that is a great solution 👍

[BombBloke]

Could the affected functions in the commands table - eg commands.setblock - be rigged to set this flag to true if they find themselves calling textutils.serializeJSON? They don't seem to do so under pr6, meaning the coder has to pre-convert their tables to strings before passing them to the affected "command" functions.

[dan200]

Unless theres's a bug in my code, that's exactly what happens in pr6. Can
you give me an example of a command that doesn't work and what the expected
result is (i'm not to hot on commands)?

On 18 December 2015 at 11:34, Bomb Bloke notifications@github.com wrote:

Could the affected functions in the commands table - eg commands.setblock

• be rigged to set this flag to true if they find themselves calling
  textutils.serializeJSON? They don't seem to do so under pr6, meaning the
  coder has to pre-convert their tables to strings before passing them to the
  affected "command" functions.

—
Reply to this email directly or view it on GitHub
#39 (comment)
.

[dan200]

(by command here i mean "line of lua code that calls commands.blah()")

On 18 December 2015 at 11:38, Daniel Ratcliffe dratcliffe@gmail.com wrote:

Unless theres's a bug in my code, that's exactly what happens in pr6. Can
you give me an example of a command that doesn't work and what the expected
result is (i'm not to hot on commands)?

On 18 December 2015 at 11:34, Bomb Bloke notifications@github.com wrote:

Could the affected functions in the commands table - eg commands.setblock

• be rigged to set this flag to true if they find themselves calling
  textutils.serializeJSON? They don't seem to do so under pr6, meaning the
  coder has to pre-convert their tables to strings before passing them to the
  affected "command" functions.

—
Reply to this email directly or view it on GitHub
#39 (comment)
.

[BombBloke]

Apologies, I can no longer reproduce. Either the issue is intermittent, or more likely, there was something else wrong with my table; having restarted the game since I can no longer check my command history, so we'll go with "I'm crazy".

[dan200]

Could you provide a test case anyway? I'd like to confirm/double check for
myself

On 18 December 2015 at 12:04, Bomb Bloke notifications@github.com wrote:

Apologies, I can no longer reproduce. Either the issue is intermittent, or
more likely, there was something else wrong with my table; having restarted
the game since I can no longer check my command history, so we'll go with
"I'm crazy".

—
Reply to this email directly or view it on GitHub
#39 (comment)
.

[BombBloke]

Sure:

commands.setblock("~ ~1 ~ minecraft:standing_sign 0 replace", {["Text2"] = "\1671Hello", ["Text3"] = "\1674World"})