Parser

Directives

This mod lets you use so called "directives" in functions. To do this, a line has to start with @ followed by the directive name and arguments for the directive. The following directives exist at the moment:

• @language <language id> [<language args>]: This directive changes the language, which can change the syntax of the function until the next @language directive. For more info on languages see Languages.
• That was the only directive that exists at the moment...

Languages

To change to a different language in a function, use the following directive: @language <language id> [<language args>]

The only language id provided by CommandCrafter is vanilla. By default, this language behaves like vanilla functions. But additional features can be added to the vanilla syntax by providing one of the following language arguments:

• default: No additional features
• easyNewLine: Lets you write commands across multiple lines without \. Note that this doesn't apply to say. Some arguments like SNBT can continue on the next line without any problems, because Minecraft always knows whether the argument is done or not. However, when putting a command literal on the next line, this literal must be indented more than the first line of the command, so Minecraft knows that it supposed to be part of the same command.
• inlineResources: Lets you define functions and tags that are only used in once place directly where they are used, so no additional files are necessary. The inlined resource is allowed to be on multiple lines and the command can continue afterwards. Inline functions are defined by writing { } instead of the function id and putting the commands of the function inside the brackets. Inline tags are defined by writing an SNBT list ([ ]) instead of the tag id and putting the tag entries inside the SNBT list. The structure of this list is the same as the "values" field from normal tag files. Additionally, a function can call itself by writing this instead of the function id.
• improved: Combines easyNewLine and inlineResources
• noBuildCheck: Behaves like default, but makes /datapack build ignore errors and directly copy all lines from the source file to the output

Examples

Multiline commmands:

@language vanilla easyNewLine
execute
  as @a
  if block ~ ~-1 ~ diammond_block
  run give @s minecraft:diamond[
    minecraft:custom_name={text: "Hi!"},
    minecraft:enchantments={
      "minecraft:unbreaking": 2
    },
  ]

Inline Resources:

@language vanilla inlineResources
schedule function {
  say I'm late!
  tp @e[type=["minecraft:zombie", "minecraft:skeleton"]] ~ ~50 ~
} 1s

Transpiling to vanilla syntax

However useful those features might be, it would annoying if datapacks using those features could only run when the mod is installed. Because of this, the mod also offers a way to convert datapacks written with it to a vanilla datapack. This is done with the /datapack build <Datapack> command, which outputs the datapack as a zip file under saves/<World>/builtDatapacks/. The command can optionally take the following arguments:

• keepDirectives: Functions are kept the way they are and not transpiled for vanilla
• functionPermissionLevel=<Level>: Defines the permission level that should be used when parsing function files.

Examples:

/datapack build "file/MyDatapack"
/datapack build "file/MyDatapack" keepDirectives
/datapack build "file/MyDatapack" functionPermissionLevel=4
/datapack build "file/MyDatapack" keepDirectives functionPermissionLevel=4

Number Provider Expressions

In vanilla Minecraft, context int/float providers have to be specified through JSON/NBT, which means even simple calculations can be a lot to type and hard to read. To make this easier, CommandCrafter introduces the command_crafter:term number provider type, which uses a custom expression syntax that can produce number providers from very easy to type and easy to read terms. These expressions can also be transpiled to vanilla number providers using /datapack build. Note that they aren't available inside of macros or nested commands, because those aren't changed by the transpiler.

For example, this is a valid number provider: /compute default integer {type:"command_crafter:term",term:"(x + 2) * other:provider", inputs:{x: "ceil(another:provider)"}}

Numbers in expressions follow the same syntax as SNBT numbers (so it's also possible to specify hexadecimal if you want to). The operators that are allowed in int and float providers are +,-,*,/, and %. The order of operations is like normal, including the usage of parentheses. Additionally, any other number provider can be referred to by writing its id. Note that the id must include the namespace such that it can be distinguished from variables. Variables define a part of an expression that is substituted for another number provider from the inputs tag. Each variable can be associated with either an inline number provider or another expression, which itself can also refer to other variables from the same number provider (as long as there are no circular references). Variable names can contain letters, numbers and underscores, but the first character must not be a number. Keep in mind that the content of a variable is copied every time you reference it, which means the computation may be done multiple times, and also if the number provider includes randomness, not every usage of the variable has to result in the same number. Furthermore, int and float expressions allow you to write function calls that all have corresponding number provider types. These are:

Int providers: pow(base, exponent), random(min, max), floorMod(dividend, divisor), floorDiv(dividend, divisor), abs(x), max(...), min(...), avg(...)

Float providers: pow(base, exponent), random(min, max), floor(x), ceil(x), round(x), abs(x), sin(x), cos(x), sqrt(x), max(...), min(...), avg(...), length(...)

Lastly, float providers have two special variables available to them: PI and E that hold the values of the mathematical constants and can't be overriden.