So as we all know the abilitybonuses in this game have a weird structure, as such
<AbilityBonus InternalName="expandedfactions_petbringer_drota">
<AbilityBonusOption InternalName = "expandedfactions_drota_petbringer">
**various tags**
</AbilityBonusOption>
</AbilityBonus>
I used to think this didn't have a purpose, but now I see that it does.
In fact, the AbilityBonus container is used to define what abilities are exclusive to units and what aren't. A quick example:
<AbilityBonus InternalName="expandedfactions_petbringer_drota">
<AbilityBonusOption InternalName = "exclusiveability_1">
**various tags**
</AbilityBonusOption>
<AbilityBonusOption InternalName = "exclusiveability_2">
**various tags**
</AbilityBonusOption>
</AbilityBonus>
<AbilityBonus InternalName="expandedfactions_petbringer_drota_newcontainer">
<AbilityBonusOption InternalName = "newability">
**various tags**
</AbilityBonusOption>
</AbilityBonus>
In this example, a unit may have EITHER 'exclusiveability_1' OR 'exclusiveability_2'. Regardless of this, the unit may also have 'newability'.
This extends fully to
1) the use of these tags in unittypes: <SelectedAbilityBonusOption>*</SelectedAbilityBonusOption>. In this case, if the unittype is given two conflicting abilitybonusoptions, it will only take one (the first one, it appears).
2) the choice players have when designing custom sovereigns. When selecting conflicting abilities, the previously selected ability will automatically be unselected. This can be used to make the player choose between one of several choices - for example, it could be designed so the player can choose to spawn ONE shard as a bonusabilityoption, but he can't spawn multiple types.
In addition, the AbilityBonus container has a unique functionality in the sense that we can define it twice, and it adds instead of replaces the previous contained tags. Consider the following example:
<AbilityBonus InternalName="SovereignHistories2222">
<DisplayName>Core Sovereign Histories</DisplayName>
<AbilityBonusType>Champion_History</AbilityBonusType>
<AbilityBonusOption InternalName = "History_Miner2222">
<DisplayName>Miner</DisplayName>
<Description>Increase the production of metal mines by 20%.</Description>
<Icon>Profession_Miner.png</Icon>
<GameModifier>
<ModType>Player</ModType>
<Attribute>AbilityBonus</Attribute>
<StrVal>A_Metal</StrVal>
<Value>20</Value>
</GameModifier>
</AbilityBonusOption>
</AbilityBonus>
<AbilityBonus InternalName="SovereignHistories2222">
<DisplayName>Core Sovereign Histories</DisplayName>
<AbilityBonusType>Champion_History</AbilityBonusType>
<AbilityBonusOption InternalName = "History_Miner22223">
<DisplayName>Miner</DisplayName>
<Description>Increase the production of metal mines by 20%.</Description>
<Icon>Profession_Miner.png</Icon>
<GameModifier>
<ModType>Player</ModType>
<Attribute>AbilityBonus</Attribute>
<StrVal>A_Metal</StrVal>
<Value>20</Value>
</GameModifier>
</AbilityBonusOption>
</AbilityBonus>
This will provide the group known as SovereignHistories2222 with two options, which are mutually exclusive. This is great, since it allows modders to add new abilities to other peoples abilitybonus groups.
In fact, looking through the Sovereignhistories.xml core file, they used the abilitybonus container to make sure the player could only choose one "history" for custom sovereigns.
NOTE: This does in no way apply to making custom factions, nor is there any limit on using two <SelAbilityBonusOption>*/SelAbilityBonusOption> from the same AbilityBonus group for raceconfigs.