Config patches

Basic principle

For each .cfg or .cfg.bin file, the system will attempt to locate the corresponding .cfg_patch_* or .cfg.bin_patch_* files during the loading process.

For singular .cfg files, the system would look for .cfg_patch_* files in the same directory and load those as patches.

When loading binarized prototypes, the system initially attempts to load the .cfg.bin_patch_* files, which are the binarized patches. Subsequently, it retrieves the .cfg files found within the prototype folder and processes them as patches. This method is intended to ensure backward compatibility with existing .cfg modifications. As such, the .cfg_patch_* files will not be searched for in the prototype folder. Instead, users should name their patches with the .cfg extension; all patching functionalities, along with the new keywords, will continue to operate seamlessly.

Adding a node

The process of adding a new node via a patch file is pretty straightforward.

Example:

Replacing a node

By default, any node inside the .cfg_patch_* file will replace the entire node in the base .cfg file.

Example:

NOTE

All child values of the original RootB node have been removed, and values from the patch files are now utilized instead.

Patching a node – the {bpatch} keyword

The {bpatch} keyword added to the struct can add or replace child values to nodes.

Example:

NOTE
In the resulting RootB, ValueA was replaced with a patch value, ValueB remained unchanged, and ValueC was added from the patch.

Removing a node – the removenode keyword

The removenode keyword can remove the entire node from the base config. Only works with {bpatch}.

Example:

Resolving references

Changes to the reference system were made:

Patch could reference the nodes of the base .cfg without refurl.
To ensure compatibility with binarized prototypes, when referencing a non-existing .cfg file inside the prototype folder, the system would redirect to the .cfg.bin file and try to find a referenced node in there.