[1.0/B18] Combat Extended Compatibility Patches

[Sig]

Hello Saebbi, I paste here this comment that I got in the Mantodean mod workshop, in case it is useful:

CE patch has a borked XML line in it, causing it to not work. Error given is 'XML error: Duplicate XML node name statBases in this XML block', the offending line is:

<Operation Class="PatchOperationReplace">
<success>Always</success>
<xpath>*/AlienRace.ThingDef_AlienRace[defName="Alien_Mantodean"]/comps</xpath>
<value>
<statBases>
<CarryWeight>200</CarryWeight>
<PainShockThreshold>1.20</PainShockThreshold>
</statBases>
</value>
</Operation>

I don't know how to actually fix it, but plinking the line out entirely does at least let the patch work again.

[Saebbi]

Hello Saebbi, I paste here this comment that I got in the Mantodean mod workshop, in case it is useful:

CE patch has a borked XML line in it, causing it to not work. Error given is 'XML error: Duplicate XML node name statBases in this XML block', the offending line is:

<Operation Class="PatchOperationReplace">
<success>Always</success>
<xpath>*/AlienRace.ThingDef_AlienRace[defName="Alien_Mantodean"]/comps</xpath>
<value>
<statBases>
<CarryWeight>200</CarryWeight>
<PainShockThreshold>1.20</PainShockThreshold>
</statBases>
</value>
</Operation>

I don't know how to actually fix it, but plinking the line out entirely does at least let the patch work again.

Oh i'm sorry, i forgot to delete this. (It was originally intended to make them stronger and more durable, but i found out that increasing the PainShockTreshold over 100 just makes them fight to death. (It also modifies the wrong adress, thus crushing the patch.))
I deleted it, so it should work now again.
Thank you for pointing it out.

[Kori]

Saebbi, have you considered the mods Biomes! or Advanced Biomes yet?

[Saebbi]

Added Lord of the Rims patch.

[Nightinggale]

I looked at the Animal Collab Project patch mod and started playing around inside it. Specifically I looked into the trigger conditions and started to profile different solutions.

Code Select Expand

<li Class="CombatExtended.PatchOperationFindMod">
<modName>AnimalCollabProj</modName>
</li>
This is your version. It takes 10.5 ms to patch.

Code Select Expand

<li Class="ModCheck.FindFile">
<modName>AnimalCollabProj</modName>
<file>Races_Animal_Angora.xml</file>
</li>
<li Class="ModCheck.IsModLoaded">
<modName>Combat Extended</modName>
</li>
I replaced it with this and it patches in around 0.4 ms.

The difference is that CombatExtended.PatchOperationFindMod will search through the list of loaded mods each time it's called and it's always true (providing the mod is loaded). This will make the game try to patch all files, though it will only find one.

The ModCheck approach will check against the mod and file currently being patched. This is information, which is available without searching and is virtually instant. It is only true when the right file is hit, meaning the game will only try to patch one file.

ModCheck will use nearly the same time regardless of how many mods are loaded while CombatExtended.PatchOperationFindMod will take twice as long when the number of xml files doubles. In other words my example with just a few mods will not show the difference people get from loading 100+ mods.

Remember this is for just one patch. You need to multiply this with the number of patches you add. It quickly adds up. The worst I have seen in released patches was 2 seconds for each patch while I loaded 300 mods to stress test. Considering the number of patches in all those mods, RimWorld took ages to start.

ModCheck.IsModLoaded is an extra check I added. It will make sure the patch will only be applied if CE is actually loaded. This makes it safe to add this patch file to Animal Collab Project. Because IsModLoaded makes use of caching as well, in this specific case it's instant. It's so fast that it takes less time than the randomness in the digits while speed testing.

As for xpath searching read A warning to modders: xpath performance. According to my test results back then, you add 6.4% to the time spend searching the xml files for where to patch.

Code Select Expand

<Operation Class="ModCheck.Sequence">
<success>Always</success>
<patchName>ACPAngoraRabbit</patchName>
ModCheck.Sequence is a ModCheck 1.7 addition. It works just like PatchOperationSequence, except for adding patchName (and other options we don't need here). Whatever you write here will show up in the log when profiling, meaning if you have 30 patches in a mod and one is slow, you can easily tell which one it is. The time spend on each patch will be printed to the end of the log if verbose logging is on and ModCheck is loaded, either as mod or added as DLL in a mod.


I'm writing this because I assume you aren't aware of this issue, which is not surprising since it's an often overlooked problem. Other than this, you seem to know what you are doing and is doing a great job.

[Saebbi]

I looked at the Animal Collab Project patch mod and started playing around inside it. Specifically I looked into the trigger conditions and started to profile different solutions.

Code Select Expand

<li Class="CombatExtended.PatchOperationFindMod">
<modName>AnimalCollabProj</modName>
</li>
This is your version. It takes 10.5 ms to patch.

Code Select Expand

<li Class="ModCheck.FindFile">
<modName>AnimalCollabProj</modName>
<file>Races_Animal_Angora.xml</file>
</li>
<li Class="ModCheck.IsModLoaded">
<modName>Combat Extended</modName>
</li>
I replaced it with this and it patches in around 0.4 ms.

The difference is that CombatExtended.PatchOperationFindMod will search through the list of loaded mods each time it's called and it's always true (providing the mod is loaded). This will make the game try to patch all files, though it will only find one.

The ModCheck approach will check against the mod and file currently being patched. This is information, which is available without searching and is virtually instant. It is only true when the right file is hit, meaning the game will only try to patch one file.

ModCheck will use nearly the same time regardless of how many mods are loaded while CombatExtended.PatchOperationFindMod will take twice as long when the number of xml files doubles. In other words my example with just a few mods will not show the difference people get from loading 100+ mods.

Remember this is for just one patch. You need to multiply this with the number of patches you add. It quickly adds up. The worst I have seen in released patches was 2 seconds for each patch while I loaded 300 mods to stress test. Considering the number of patches in all those mods, RimWorld took ages to start.

ModCheck.IsModLoaded is an extra check I added. It will make sure the patch will only be applied if CE is actually loaded. This makes it safe to add this patch file to Animal Collab Project. Because IsModLoaded makes use of caching as well, in this specific case it's instant. It's so fast that it takes less time than the randomness in the digits while speed testing.

As for xpath searching read A warning to modders: xpath performance. According to my test results back then, you add 6.4% to the time spend searching the xml files for where to patch.

Code Select Expand

<Operation Class="ModCheck.Sequence">
<success>Always</success>
<patchName>ACPAngoraRabbit</patchName>
ModCheck.Sequence is a ModCheck 1.7 addition. It works just like PatchOperationSequence, except for adding patchName (and other options we don't need here). Whatever you write here will show up in the log when profiling, meaning if you have 30 patches in a mod and one is slow, you can easily tell which one it is. The time spend on each patch will be printed to the end of the log if verbose logging is on and ModCheck is loaded, either as mod or added as DLL in a mod.


I'm writing this because I assume you aren't aware of this issue, which is not surprising since it's an often overlooked problem. Other than this, you seem to know what you are doing and is doing a great job.

Thanks a lot, i'm definitely going to incorporate this.
I've used ModCheck before, but i didn't know the difference was that huge.
Btw. you did a great job with this and i really appreciate your help.

[Vanlou]

Hi, first of all, thanks for your work !
But do you think that you can patch Rimmu nation? The only one patch on steam is now outdated

[Nightinggale]

I've used ModCheck before, but i didn't know the difference was that huge.

The core of the speed boost in this specific case comes from ModCheck.FindFile, which was added in 1.6. ModCheck was further optimized in 1.7, which I released yesterday. Regardless of what you once did, just the fact that I used 1.7 and you didn't would give me a better result.

[BattleSausage]

Is there a recommended load order? I'm running the patches for medieval times, misc core and the astra militarium mod. (+ a shitload of random other mods that dont need CE patches) and my load order is
CE
Hugslib
jetsec tools
random mods
mod that needs CE patch
CE patch for that mod
random mods.

Including the various astra militarum mods (core, core patch, factions, factions patch, turrets, turret patch) and the astra militarum guns dont work (no projectiles leave the guns when fired, tested by spawning a bunch of lasguns and some ammo).

Should it be all the Astra militarum mods together before any of their patches?

Thank you for these patches by the way. Letting other great mods play together isnt brings far more joy then another great mod that wont play together with the others.

[Saebbi]

Is there a recommended load order? I'm running the patches for medieval times, misc core and the astra militarium mod. (+ a shitload of random other mods that dont need CE patches) and my load order is
CE
Hugslib
jetsec tools
random mods
mod that needs CE patch
CE patch for that mod
random mods.

Including the various astra militarum mods (core, core patch, factions, factions patch, turrets, turret patch) and the astra militarum guns dont work (no projectiles leave the guns when fired, tested by spawning a bunch of lasguns and some ammo).

Should it be all the Astra militarum mods together before any of their patches?

Thank you for these patches by the way. Letting other great mods play together isnt brings far more joy then another great mod that wont play together with the others.

Most importantly load HugsLib and JecsTools before everything else.
For the rest it doesn't really matter, but best is main mod -> CE -> CE Patch

[BattleSausage]

That worked, thanks (havent had time to test it but the startup dialog went from a million errors talking about armour penetartion to one talking about the m72 LAW reminding me that I forgot to drag CE guns to below CE.

[Nightinggale]

For the rest it doesn't really matter, but best is main mod -> CE -> CE Patch

The game loops the mods several times at startup and each time it reads one part of them. The patches are actually loaded before the xml files. The list of patches is then applied to each xml file right after it has been loaded, but before they are merged into one big database.

Related to load order, the result is this:

• Animal Collab Project
• CE
• Animal Collab Project CE patch

The patch file will trigger on ACP, meaning the patch is applied in step 1, not 3. In other words the patch is "loaded" before CE despite being after CE in the mod list. In other words the order of the patch mod doesn't matter at all. The only exception is if you want to control the order of which two patch mods applies changes to the same file, but I can't really think of a case where this would make a difference without the mods downright overwriting each other (like two mods changing the power usage of the same building), in which case the last one will be used.

The question is if the CE patch requires CE to be loaded. If it does then CE needs to be first. The patch seems to rely on the CE DLL and the DLL files are loaded at the very first thing, meaning this should not cause a load order issue either. If it relies on something in the CE xml files, the error log will tell you something went wrong.

[Saebbi]

For the rest it doesn't really matter, but best is main mod -> CE -> CE Patch

The game loops the mods several times at startup and each time it reads one part of them. The patches are actually loaded before the xml files. The list of patches is then applied to each xml file right after it has been loaded, but before they are merged into one big database.

Related to load order, the result is this:

• Animal Collab Project
• CE
• Animal Collab Project CE patch

The patch file will trigger on ACP, meaning the patch is applied in step 1, not 3. In other words the patch is "loaded" before CE despite being after CE in the mod list. In other words the order of the patch mod doesn't matter at all. The only exception is if you want to control the order of which two patch mods applies changes to the same file, but I can't really think of a case where this would make a difference without the mods downright overwriting each other (like two mods changing the power usage of the same building), in which case the last one will be used.

The question is if the CE patch requires CE to be loaded. If it does then CE needs to be first. The patch seems to rely on the CE DLL and the DLL files are loaded at the very first thing, meaning this should not cause a load order issue either. If it relies on something in the CE xml files, the error log will tell you something went wrong.

Oh, i didn't know about this.
It was just the way i used it without throwing any errors, so i just stuck to it.
But thanks for telling me.

[WereCat88]

Could you please put the android tiers patch on here?

[Saebbi]

Could you please put the android tiers patch on here?

Added it, it's at the top of the list