A "node" is an element that looks like this:
{
"type": "root|literal|argument",
"parser": "", // only applicable if type is argument
"properties": {}, // only applicable if type is argument, defaults to empty object
"executable": true, // default if not specified is false, meaning it isn't a runnable command by itself
"children": {}, // default if not specified is {}, meaning no children
"redirect": [] // default if not specified is null, meaning no redirect
}
A redirect
is a path to another node in the tree. ["foo", "bar", "baz"]
means "find the child named foo
of the root, then the child of that named bar
, then the child of that named baz
".
Every element of children
is another node, which itself may have more children.
A literal
type means "I expect the literal name of this node", and has no properties
.
An argument
type means it's dynamically parsed, using parser
(and any optional properties
)
This looks pretty nice already. It's good to have an official in depth description of command syntax.
I'm kind of missing permissions, tho. Say you want to write a command parser for functions. Commands like
/ban
are probably not going to be allowed in functions. It would be nice if we could filter these out.It would also be nice to have a list of valid parsers, a description, and valid properties for the specific parser, including default values.
The description might be anything from a small sentence to json tree similar to this on. Especially for
minecraft:entity
, it might be good to describe the selector arguments similarly, tho.Also, I know that for
minecraft:particle
it is mostly literals of valid particle ids, but some ids might have additional arguments as it looks like. E.g. blockdust expects a block:minecraft:blockdust minecraft:stone
, without a block id, the blockdust particle isn't actually valid. I don't know if there are more special cases where similar things apply, but that's also a reason I would like a better description for the parsers.