-
Notifications
You must be signed in to change notification settings - Fork 3
Search
Moves an xml element to a specific location, allows operations on it and then moves it back where it came from.
Xpath searching is slow. By placing the element in a location you can write the path to without searching, each patch operation will be much faster. There is a setup overhead for this, meaning it's a tool for when you need to patch the same Def more than two times. With 3 patch operations, this is a little faster than vanilla. With 4 patch operations, this is a little faster than vanilla does 3 patch operations. The more you need to do to the same one, the more it increase the speed.
| Tag | Mandatory | Type | Default | Description |
|---|---|---|---|---|
| patchName | no | string | Name of patch for log/profiling | |
| xpath | yes | string | The element (Def) to work on | |
| stopOnFail | no | bool | true | If true, operations stops if one fails |
| tag | no | string | SearchResult | Sets where the temporal location should be |
| operations | yes | list | List of operations. Acts like Sequence | |
| Log writing | no |
Xpath is found, operations contains at least one operation. If stopOnFail is true, a pass also requires none of the operations fail.
<li Class="ModCheck.Search">
<xpath>Defs/ThingDef[defName="WatermillGenerator"]</xpath>
<operations>
<li Class="PatchOperationReplace">
<xpath>Defs/SearchResult/ThingDef/costList/WoodLog</xpath>
<!-- more patching code here -->
</operations>
</li>In this case the operations can use Defs/SearchResult/ThingDef instead of Defs/ThingDef[defName="WatermillGenerator"]. Since there is only one Defs/SearchResult and one Defs/SearchResult/ThingDef, the need for the slow [defName="WatermillGenerator"] is gone.