Configs
Configs are a way of having universally accessible configuration for your patches, available at patch time, this can be useful for like if you have a constant that you want other mods to be able to change, or if you want mods to be able to provide overrides to your defaults for specific parts.
Defining Configs
Defining configs is quite simple, you do @define-config "config-label", "config-name": [config data as a value];
For a few examples of defining configs:
Updating Configs
To update a preexisting config, you do @update-config update-priority, "config-label", ["config-name"]: [update-expression];
The update priority means that in the case of multiple updates on the same config, the ones with the lower priority will be run first. This is an expression.
The update expression has $value
set as the current value of the config pointed to by the label and name, or the current value of the dictionary of configurations pointed to by config-label if only that is selected. And the update expression also allows prefix expressions.
A few examples of updating configurations
Using Configs
To use configs, you can grab them using 2 different methods, get-config
, and get-configs
. These are available in the builtin:config
library.
get-config($label,$name)
This allows you to get the value of a single config object with its label and name, or if that config object does not exist it returns null
(allowing for you to do easy checking).
Here is an example of using this:
get-configs($label)
This gets a dictionary of all configs that are defined under the passed label, with the keys being the names of the configs, if there are no such configs, it will return an empty dictionary.
Specific Examples of Config Usage
The following are a few specific examples as to what configs can be used for.
Allowing Overrides for Specific Parts
Say for the sake of example, that you are writing a life support mod that adds its resources in a small amount to every single command pod, but, you wanted to allow other mods to be able to override this amount. There are a few ways that you could go about this.
The mod author could just add its resources to the pod and you could check for this.
This falls flat because this make the mods parts depend on your mod, when they may want to have an optional dependency
The mod author could do a patch after yours on its parts to update the values
This also falls flat, because it requires making use of the staging system which can be a bit complex and can have pitfalls
You could set up your mod to be moddable itself with configs for part overrides
This requires more work from you, but makes your mod as easily moddable as possible for other modders
For an example of how you could set this up, assuming you have 3 resources you want to add to parts food
, water
, and oxygen
.
First make a library called _configs.patch
for your mod or similar, this will contain a function for generating an override config dictionary. The reason this is a function is such that if you add stuff to your mod for stuff you want to add, or change what gets added, then it won't break old patches. And also it allows you to set up default arguments.
And then in your main patch for adding these resources to the parts, you can set it up like follows, grabbing the config values at the start.
And then any other modders can add override configs for their parts like the following for example:
Creating Overridable Constants
Say now, you want the length of a day to be configurable inside your life support mod (for example if you are using some form of different solar system), then, you can use the config system to create modifiable constants.
To start, you should move the constants for your mod you want to be mutable into a file under the configs directory with any name, lets go with constants.patch
for this, in there you would define your constants as configs as follows
Then in your patches where you use these constants, you instead grab the value of the constant at patch time, for example using the previous patch:
And then, other mods can easily change the day length for your mod using the @update-config
statement, like the following for example: