Patch Auto-Merging Approach

To further reduce the programming effort required when modding, automod supports the dynamic loading of the patch files described above. All patch files should be placed inside the patches directory of the script working directory. They can be organized in a hierarchy of tree-structured folders.

The script loads them in a depth-first, orderly manner to provide a systematic, convention-based patch merging method. That is, patch files/directories at the same level are loaded/traversed based on the lexicographic ordering of their names, and patch files at lower levels will be loaded after their ancestors.

Note that files/folders whose name starts with a dot (.) are ignored to conveniently enable/disable patch files.

For example, for the following patches folder/file structure:

The loading and patch application ordering is as follows:

1. patches\EffectTable.toml

2. patches\1\EffectTable.toml

3. patches\2\EffectTable.toml

with patches\3\.EffectTable.toml ignored.

Patching Semantics

Patches are applied in load order, each on top of the state left by the preceding ones, so a later patch can override an earlier patch by patching the same property. Whether a patch overrides or accumulates depends on how its value is computed:

• using v.orig (or v.orig() for non-Scala) reads the original game value, unaffected by the preceding patches, so the result overrides any earlier patches on that property;
• using v.current/v.currentOpt (or v.current() for non-Scala) reads the value after the preceding patches have been applied, enabling incremental (cumulative) patching.

See the TOML Patch File Schema section for the patchlet API.