Modding: Mod File Structure

## Game configuration file structure

All of Judgment's configuration files have a hierarchical key-value pair format. Each line in the config is a key-value pair entry, but the keys have a hierarchical structure.

Let's look for example at the bow crafting entry:

```
# Bow crafting recipe
crafting.entity.bow.amount=1
crafting.entity.bow.work=4
crafting.entity.bow.priority=1
crafting.entity.bow.costs.wood=2
crafting.entity.bow.costs.arrows=5

```

The key hierarchy is as follows:

* crafting - the root for the entire crafting configuration tree
* entity - this node contains all the crafting entries
* bow - the root node for the bow crafting entry
* amount, work, priority - values for the bow crafting entity
* costs - this node contains what it costs to craft the bow
* wood, arrows - values within the costs node that indicate the raw materials and amount

The first line that starts with "#" is a comment. Any line that starts with a hashtag will be ignored by the parser and is used only for organizing the configuration files.

## Inheritance & Overriding

Any node in the configuration hierarchy may have a parent node. The child node will inherit all the configuration nodes and values of the parent node.

A child node may override the values of the parent node, simply by adding a key of it's own.

Example:

```
items.base.tier1.value=4
items.base.tier1.mindifficulty=0

items.entity.scraps.parents=items.base.tier1
items.entity.scraps.value=2

```

The "items.base.tier1" node is a parent node for all tier 1 items. It defines a scavenge value of 4, and the items may appear in any scavenge mission with difficulty 0 or above.

The "items.entity.scraps" node contains the configuration for the "scraps" item. The first key in the scraps node defines the tier1 node as its parent, so the scraps will have a scavenge value of 4, and minimum scavenge difficulty of 0.

The second key in the scraps node defines a scavenge value of 2. This overrides the parent tier1 node's scavenge value of 4, so the "scraps" item ends up having a scavenge value of 2, but retains the minimum scavenge difficulty of 0 from the parent tier1 node.

A node may inherit from more than one parent node using comma separation. If several parents have the same key within them, the last one will be used.

```
bow1.costs.wood=5
bow2.costs.wood=10
crafting.entity.bow.parents=bow1,bow2

```

In this example both parents bow1 & bow2 have a "costs.wood" key with different values. Since bow2 is the last parent that has such a key, it's value will be the one used, so the bow will cost 10 wood.

## Removing Configuration Nodes

It is also possible to completely remove nodes that were inherited from a parent without providing alternative values, by using the "~null~" keyword.

```
crafting.entity.bow.amount=1
crafting.entity.bow.work=4
crafting.entity.bow.costs.wood=2
crafting.entity.bow.costs.arrows=5

crafting.entity.freebow.parents=crafting.entity.bow
crafting.entity.freebow.costs=~null~

```

In the example above, the "crafting.entity.freebow" node inherits all of the "crafting.entity.bow" node's keys, including the "costs" sub-node. The second key for the "freebow" overrides the "costs" sub-node with a null value, essentially deleting the entire "costs" sub-node. The result is that the "freebow" crafting recipe doesn't have any "costs" sub-node, so it can be crafted for free, but retains all the other values inherited from the bow (such as amount and work).

## Mod Files

Mod files are configuration files, just like the built-in configuration files. The only difference is that mod files automatically inherit the entire built-in configuration file.

You can add to the original configuration simply by adding new key-value pairs in the mod file.

You can modify original configuration values, simply by adding the same key-value pairs in the mod file, but giving them different values.

You can remove nodes from the original configuration files just like you would remove nodes from an inherited parent, using the "~null~" keyword.

You can also override an entire original config file. To do that, add "\_Override" to the end of the file name. For example, if you want to create your own items file and have the game ignore the original built-in items file, you can add the file "Items\_Override.txt" to your mod. This is not possible for Config.txt, however.

Let's look at this example crafting mod:

```
crafting.entity.club.costs=~null

crafting.entity.bow.costs.wood=10

crafting.entity.chair.amount=1
crafting.entity.chair.work=5
crafting.entity.chair.costs.wood=5

```

This mod deletes the club's costs, making clubs free to craft. The club recipe will retain all the other values from the built-in configuration, such as work required and amount crafted, even though those keys & values are nowhere to be seen in the mod configuration file.

The mod also overrides the amount of wood it costs to craft a bow, and bows will cost 10 wood instead of 2. Again, the bow will retain all the other built-in values, such as how many arrows it costs. So crafting a bow ends up costing 10 wood (configured in the mod) and 5 arrows (configured in the built-in configuration file) in this mod. If we'd want to remove the arrow costs as well, we'd use the following configuration, to first remove all the inherited costs, then add new ones:

```
crafting.entity.club.costs=~null~
crafting.entity.club.costs.wood=10

```

The last thing that the mod above does is add a completely new crafting recipe for "chair", that costs 5 wood, takes 5 work to make, and yields 1 chair.