ModCheck 1.8 has been released. The main change is B19 support and dropped support for B18.
Vanilla made a complete rewrite of xml loading from mods, meaning ModCheck had to be partially rewritten too. Now all files are read, merged into one giant xml file and then patched. This is a great move because it's much faster, even faster than ModCheck could make B18. However since there is no longer an owner of the file being patched, FindFile is dead. I did work on preserving it, but it didn't turn out well and actually slowed down patching. You will have to rewrite FindFile to either not use it at all or use the other operations to test for presence of other mods.
I added a search operation. It's used like this:
What it does is whatever it finds will be moved to Defs/SearchResult/ThingDef and then back once operations are done. This mean xpaths can use "Defs/SearchResult/ThingDef" instead of "Defs/ThingDef[defName="WatermillGenerator"]". It has an overhead in setting up, which is around 2.5-2.7 xpath searches (at least if only vanilla is loaded). However if you need to do 3 modifications it will be faster because "Defs/SearchResult/ThingDef" is following a path, not a search. If you need to do 4 operations, it's still faster than 3 vanilla operations with a searching xpath. In other words it's a performance boosting tool for the cases where you need to do a bunch of operations to the same item.
I also added the Move operation.
This will make use of the fact that it's now one big xml file. What is does is that it will find xpath and then it will take whatever is in followers (it's a list of unlimited size) and move the elements to be right after the xpath element. In this specific case it will move AdvancedSolarGenerator to be next to SolarGenerator. If multiple followers are added, they will be added in the order they are written. This should allow placing the buildings in useful groupings rather than the vanilla approach, which is semi random based on load order.
Vanilla made a complete rewrite of xml loading from mods, meaning ModCheck had to be partially rewritten too. Now all files are read, merged into one giant xml file and then patched. This is a great move because it's much faster, even faster than ModCheck could make B18. However since there is no longer an owner of the file being patched, FindFile is dead. I did work on preserving it, but it didn't turn out well and actually slowed down patching. You will have to rewrite FindFile to either not use it at all or use the other operations to test for presence of other mods.
I added a search operation. It's used like this:
Code Select
<li Class="ModCheck.Search">
<xpath>Defs/ThingDef[defName="WatermillGenerator"]</xpath>
<operations>
same code as a sequence
</operations>
What it does is whatever it finds will be moved to Defs/SearchResult/ThingDef and then back once operations are done. This mean xpaths can use "Defs/SearchResult/ThingDef" instead of "Defs/ThingDef[defName="WatermillGenerator"]". It has an overhead in setting up, which is around 2.5-2.7 xpath searches (at least if only vanilla is loaded). However if you need to do 3 modifications it will be faster because "Defs/SearchResult/ThingDef" is following a path, not a search. If you need to do 4 operations, it's still faster than 3 vanilla operations with a searching xpath. In other words it's a performance boosting tool for the cases where you need to do a bunch of operations to the same item.
I also added the Move operation.
Code Select
<Operation Class="ModCheck.Move">
<xpath>Defs/ThingDef[defName="SolarGenerator"]</xpath>
<followers>
<li>Defs/ThingDef[defName="AdvancedSolarGenerator"]</li>
</followers>
</Operation>
This will make use of the fact that it's now one big xml file. What is does is that it will find xpath and then it will take whatever is in followers (it's a list of unlimited size) and move the elements to be right after the xpath element. In this specific case it will move AdvancedSolarGenerator to be next to SolarGenerator. If multiple followers are added, they will be added in the order they are written. This should allow placing the buildings in useful groupings rather than the vanilla approach, which is semi random based on load order.