Support multi-line JSON and NBT blocks of code without needing the backslash (\)

[GnaspGames]

Moesh raised this as an issue and I agree (http://moesh.ca/journal/time-to-release-minecraftcommandcode/#liveblog-entry-311).

"One final problem comes from how Smelt handles “multiple lines” of code. It allows you to add a bashslash to split up lines of commands. I don’t like this. I think Smelt should handle this inherently, especially for JSON and NBT tags, which where this would be used the most."

I think it should be possible to determine if a line has a starting { bracket and then match that to a closing } one. Maybe using a regular expression of something similar.

[GnaspGames]

I've been thinking about this more. Maybe I should change the way Smelt is handling multiple lines all together. I used the \ backslash because I've built it to ignore any line that doesn't start with the trigger characters #, {, / or ! - but maybe I should move away from that.

By making an explicit commenting syntax (I used -- to mark a comment in my code) then Smelt could be changed to believe every line is a continuation of the last line until if finds a new trigger character at the start of a line.

I need to consider this further.

[GnaspGames]

Saying that... I'm not sure how Smelt would know whether a line that starts with { is a JSON line or NBT that is continuing from a previous command. :disappointed:

[Moesh-zz]

Could use regex to detect open and close brackets, or perhaps a "at least one tabbed indent AND not a commandblockdefinition/command/bang/etc and this is part of the last line" test?

I'm currently using indents to denote "conditional blocks", but having the ability to actually split out large NBT tags/JSON tags is far more important.

[GnaspGames]

I really wouldn't want to introduce meaning to tabs. I use tabs extensively as a formatting tool. I don't feel like they should have syntactical value that would change the behaviour of Smelt.

My main concern is this:

{
    "type":"impulse",
    "auto":true
}
/title @p title 
{
    "text":"GRAVITATE",
    "color":"green",
    "bold":"true"
}

How can I tell Smelt that the first set of {} brackets is JSON to be processed by itself, and that the second set of brackets is a continuation of the /title command?

[JBartelsson]

I'd suggest a solution here:

1. Scan the file until a trigger character comes in(# ! / {)
2. Until you find a next trigger character you can add all the lines(/characters) to a string variable
3. If you find that trigger character proceed with the action with the string variable
4. Do until End of file This may need some rearranging of the code but it could be a solution As I'm writing this I think you need another way of marking the Command options thing { "type":"impulse", "auto":true because other wise you cant distinguish the characters from each other

[Moesh-zz]

Come to think of it, why isn't creating a new function a bang command?

[GnaspGames]

@SkaranYT Yes, I think you see the issue I was referring to in my comment above.

I can only see that I have to either introduce a new trigger character for JSON blocks. Say an @ symbol. For example

@{
    "type":"impulse",
    "auto":true
}
/title @p title 
{
    "text":"GRAVITATE",
    "color":"green",
    "bold":"true"
}

Or we're going to have to insist on using the backslash \ when we want to force the next line to be considered part of the current line. Meaning that the second { would be in ignored in this example:

{
    "type":"impulse",
    "auto":true
}
/title @p title \
{
    "text":"GRAVITATE",
    "color":"green",
    "bold":"true"
}

Seeing as; (1) we're already using \ in the current version, (2) the second example only requires a backslash to join a command with NBT data following on the next line, and (3) that this won't require folks to add a trigger character in-front of all their existing JSON blocks; I think the second idea is the best.

Thoughts?

[GnaspGames]

@Moesh "Come to think of it, why isn't creating a new function a bang command?"

^^ I'm not sure what you mean here? Is this a new idea, not related to what we're talking about in this thread :wink: :wink: ?

[VexSpectre]

@GnaspGames: I can only see that I have to either introduce a new trigger character for JSON blocks. Say an @ symbol

I think the new trigger is the best way to go. This also helps to differentiate clearly between a row/command-block property and a JSON/NBT Tag of a Command.

[JBartelsson]

I updated the FileParser and did a Pull request. This should work now.

[GnaspGames]

Thanks @SkaranYT! I have seen the request, but I haven't had time to review it yet.

Since it's going to be a breaking change for folks who are already using Smelt, I want to make sure it's good, and that folks are happy with it before pushing it out.

[GnaspGames]

This has been completed with #42