blocks

Blocks

Every block in the blocks array follows the value:

{
    id: "block" | "bracket" // it is the type of block
}

Each type has different values in the object itself

bracket

Brackets are the simplest, so are going first.

Pretty much self-explanatory, their data goes as such:

{
    id:     "bracket",        // cannot be block
    direct: "open" | "close", // Open (as a piston) faces to the right, and close faces left
    type:   "norm" | "repeat" // If the bracket is sticky or not. "norm" isn't and "repeat" is.
}

block

I sort blocks into 4 types: SelectionBlock, SubActionBlock, DataBlock, and Else They all follow the data pattern.

{
    id:    "block", // uhuh
    block: "call_func" | "control" | "else" | "entity_action" | "entity_event" | "event" | "func" | "game_action" | "if_entity" | "if_game" | "if_player" | "if_var" | "player_action" | "process" | "repeat" | "select_obj" | "set_var" | "start_process",
    // All the internal names of block types
}

Any dynamic value which "df doesn't care about" can have any value and will import ignoring what is in the value. They support color codes if using § to prefix the color code (not &). Hex probably wont work

Else

Else is simple, has no dynamic values, and follows data pattern

{
    id:    "block",
    block: "else"
}

Action Blocks

Blocks with actions. They follow the data pattern

{
    id:        "block",
    block:     string,     // Only supports options found in the subtypes.
    action:    string,     // There are lots and will be too many to list. DF doesn't care about what's on it.
 // inverted:  "" | "NOT", // If the block is inverted with the NOT arrow. Only IF blocks use this. DF doesn't care about what's on it.
    attribute: "" | "LS-CANCEL" | "NOT", // Deprecates inverted, events which can be automatically cancelled with the cancel scythe use this.
    args:      Args        // See /wiki/items
}

Args

SelectionBlock

Perhaps the most common type, which appears to include blocks which don't even use Selections and blocks that don't use Inversion.
They follow the data pattern

{
    id:       "block",
    block:    "event" | "player_action" | "entity_event" | "entity_action" | "set_var" | "game_action" | "repeat" | "control" | "select_obj",
    action:   string,
    target:   "" | "AllPlayers" | "Victim" | "Shooter" | "Damager" | "Killer" | "Default" | "Selection" | "Projectile" | "LastEntity",
    // The selection of the block, not all encompassed by this type use it. DF doesn't care what is in this.
    attribute: "" | "LS-CANCEL" | "NOT", 
    args:     Args // See /wiki/items
}

Args

SubActionBlock

Found on a few select by condition blocks, and repeat while. It just takes the action from a condition and puts it onto subAction.
Clashing can happen and IF PLAYER seems to take priority. Source for this line

{
    id:        "block",
    block:     "if_entity" | "if_game" | "if_player" | "if_var",
    action:    string,
    subAction: string, // The sub action used for condition on a block. DF doesn't care what is in this.
    attribute: "" | "LS-CANCEL" | "NOT",
    args:     Args     // See /wiki/items
}

Args

DataBlock

These blocks all can be set via a text value in-game. They take their information from the action dump action "dynamic".

{
    id:    "block",
    block: "func" | "call_func" | "process" | "start_process",
    data:  string, // The name of function/process being called/created
    args:     Args // See /wiki/items
}

Args
There appear to be no limits on the value in data, so colour codes with § work, they can be made unreasonably long, and contain impossible characters, like any other field which df doesn't care about.