[bug] Overwriting a unittype does not cause it to drop <SelectedAbilityBonusOption>

in fact i wanted to ask how to make modular stuff

so in theory you are supposed to be able to rewrite only the stuff you want in the modded files and they should ofc be used instead of originals

is the rest working? like equip etc?

For unittypes yes.

There are many things that do not work right in other types, however.

AbilityBonusOptions and AbilityBonus do not clear anything inside them when overwritten. Same goes for ImprovementTypes.

Spelldefs do not clear SpellResourceCost.

Stuff found in TerrainTypes.xml and CoreEnvironmentTypes.xml and ElementalDefs.xml can be overwritten but you have to copy the entire file, not just a part of it. You cannot add anything to CoreEnvironments.xml. You cannot add anything to TerrainTypes.xml unless it is in the core file.

All tactical maps cannot be overwritten without modifying the core content. There, their internal name is the same as the filename.

TechTree can be overwritten, but TechDef cannot. For TechDefs you must again edit the installation file.

In fact the only thing that really works to overwrite is GameItemTypes.

Graphical files (.dds .png .hkb) can be overwritten completely by including a new file with the same filename in /Gfx/. This of course does not work for any other files.

These are just a few of the difficulties we must navigate when attempting to create a modular mod.

seems like its just not worth it atm

If you are modifying the core game, like seanw3 is doing with his balance mod, it is far easier to do it in the installation directory. Not just "easier" but practically required.

However, and there IS an "however", the problem with using this method is that the mod does not work with other mods. There can only be one copy of each file. The mod is not modular, it doesn't really work with other mods. Of course, if you're doing a balance mod this isn't much of an issue because the changes you make probably make it so that it wouldn't work anyway.

But consider a mod that mostly adds content, like Stormworld. Because I don't have much reason to modify core content (with a few exceptions) it becomes much more appealing to not use the installation directory. In addition, since I am balancing my mods after the real game, the mod should theoretically be compatible with other similar mods.

In addition, some of the problems I encounter can actually be turned into benefits. Imagine that I have a race that should not be able to build logging camps. All I need to do is give them a trait and add something like this:

Along comes modder X. Modder X also wants to do something with the Logging Camp. He wants to flag a city with a logging camp so the units within have a hidden unitstat. Why? Maybe to make forest monsters more dangerous when attacking the city.

The result? Our mods aren't clashing and will work side by side.

As you see, there are benefits and drawbacks from either method.

yeah the problem is this way there are bugs and sometimes unknown mechanics that make things complicated

while just overwriting worst case scenario the modder copy paste the original

its way way faster copying a text than understanding a whole compatibility system

but still its enough we know how it works in the end

Modular mods are really not possible right now or you would have to really test out what files can be modded like that. We will have to wait until the modding rapture, when the gods of development come to our forum and fix all the bugs. Until then, it's just more efficient to do a core mod. 

I found another tag that doesn't clear for gameitemtypes, although it literally has no impact because we can overwrite it, modders should nevertheless "be aware" that they need to overwrite it. <CustomizationPointCost>1</CustomizationPointCost>

With <SelectedAbilityBonusOption> is there any way to set a requirement for it? When I was modding that way before, I had to find creative ways to get things to work, some things obviously just could not be done. If you could add some kind of requirement it would work but I am sure you already thought about it (or know that wont work).

I haven't really tried it, but I think once you put it in the unittype it goes on the unit. The one exception I can think of is if you put it on a trainable unit, the trait counts as Unit_Design and it is blocked through research for your faction. In that case, the unit won't appear until you've researched the trait.