This guide was written because quite a lot of people have asked me about details regarding my
Province Capital Building Slot Overhaul and Crynsos' Faction Unlocker+ PCBSO Addon mods.

Zingertits from Team Radious[www.patreon.com] compiled a useful list of other nicely working building slot mods and wrote his own guide to modding them. Taking a look may be worth it[docs.google.com]


Library -> Tools



Installation



Pack File Manager[sourceforge.net]. It does not need to be placed in your Total War: Warhammer directory.
This is a great tool which we will need later on.



>>>>>>>>>>>>>>>>>>>>>>>>>>>>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<

In my experience, this prevents certain issues when reprocessing the startpos.esf file using BOB. More on that later.
Close the launcher afterwards.

(Yes, they called their tools Bob, Dave and Terry)

You should now see a very long, scrollable list of database tables. Notice the useful filter bar at the top.





A table with many different columns and 251 (0 to 250) entries should appear. It contains all the different regions available in the grand campaign and both DLC campaigns, even if you don't own the required DLC.


Note the differentiation between provinces, regions and settlements:

- A province almost always spans multiple regions (the Oak of Ages' province is an exception). As you know from the game, holding a province with all of its settlements allows you to select a province edict.

- A region is the area around a single settlement. Regions do not directly contain any buildings, but the settlements within them do. With its slot_cap value, a region determines how many buildings the settlement within it can construct.

- A settlement is the town itself. Very straight-forward.

Filtering the entries will greatly help you find what you want. Filters can be added by clicking on the + symbol on the right side. This can help you navigate through almost all tables available in the Database Visual Editor.



Before you are able to properly search through the table, we need to specify which column our filter should be applied to. If we wanted to search for every region within the Reikland province, we'd have to do this:



We could now use a second filter to narrow down the results to regions only from the main campaign like so:



The filter also supports regular expressions and wildcards, these aren't important to us right now, though.

Okay okay, enough filtering for now! The good news is: Regions containing province capitals can easily receive additional building slots.
To do this, pick a region belonging to a province capital (Altdorf, Karaz-a-Karak, Drakenhof, Barak Varr... any of these) and change the value in the slot_cap column to something higher. Removing slots works the same way.



Now we've increased the region's maximum amount of slots, but the settlement still can't use them.
Why? Because the primary settlement building responsible for unlocking the slots hasn't been modified yet.

Click Apply and Close in the top right corner of the start_pos_regions window

Back to our Table Launcher, we're now looking for a table called campaign_building_chain_slot_unlocks

This table contains two different columns which can be explained quickly.

The first one is building_chain and refers to the vertical lines of buildings seen in the campaign when constructing buildings or looking at the settlement construction options.
A building_chain is not the same as a single building, it is an ordered list of one or multiple buildings.

Example: The Empire's province capital primary building building chain (phew) is wh_main_EMPIRE_settlement_major .
The coastal equivalent is wh_main_EMPIRE_settlement_major_coast.
Some settlements like Altdorf use a very special primary building chain, Altdorf uses wh_main_special_city_altdorf.

Can building chains other than primary ones be used to unlock building slots in a settlement?
I think not. I have tested it multiple times and it just did not work. Only primary building chains used in major and minor settlements seem to be able to unlock building slots. Minor settlement primary building chains have some special rules addressed at the end of this section

The second column is secondary_building_slot_unlock_count and tells the game how many slots the corresponding building_chain unlocks per tier. Unlocks per tier may not exceed the corresponding region's slot_cap defined in start_pos_regions!


As you know from the campaign, most province capitals follow this pattern:

T1: primary building + 1 slot
T2: primary building + 2 slots
T3: primary building + 3 slots
T4: primary building + 4 slots
T5: primary building + 5 slots (slot_cap of 6 is reached)

This suggests that most building_chains use a secondary_building_slot_unlock_count value of 1, but why aren't they in here?
For the same reason only the Wood Elves have an entry here per default.
Primary building chains default their secondary_building_slot_unlock_count value to 1 when not set manually in this table.
So any primary building_chainnot listed in the table such as wh_main_EMPIRE_settlement_major or wh_main_DWARFS_settlement_major will unlock just one building slot per tier.

Here I've increased the number of slots per tier to 2 for some primary building_chains available to the Empire.
Note that Kislev, Tilea, Estalia and the Border Prince have their own primary building chains and will not be affected by the changes shown in the picture.
wh_main_special_city_altdorf is missing too, it's a special building_chain
The Vampire Counts won't be affected either, as they use vampire versions of these building_chains



The one and only pre-existing entry here is wh_dlc05_wef_settlement_major_main (not shown in the picture as I used a filter).
This building_chain refers to the primary settlement buildings found in King's Glade, Crag Halls of Findol, Waterfall Palace and Vaul's Anvil on the grand campaign map.
Remember from your campaigns that all four of these aforementioned provinces have acess to 10 building slots in total per default, 2 out of these 10 slots are unlocked witch each settlement primary building tier because it is defined so within the campaign_building_chain_slot_unlocks table and the default value of 1 is overwritten.

So Creative Assembly increased it only for wh_dlc05_wef_settlement_major_main to allow the Wood Elves to progress their settlements as follows:

T1: primary building + 2 buildings slots
T2: primary building + 4 building slots
T3: primary building + 6 building slots
T4: primary building + 8 building slots
T5: primary building + 9 building slots (1 + 2 + 2 + 2 + 2 + 1, slot_cap of 10 is reached)

By the way, dlc05 is the internal term for the "Realm of the Wood Elves" DLC and "wef" is Creative Assembly's abbreviation for things belonging to the Wood Elves.
See the guide section Abbreviation definitions for help with that.

The bad news is: Even when building slots are correctly added to regions containing minor settlements and unlocks per settlement tier are entered correctly, minor settlements can't use them by default. They need to be upgraded into province capitals. And one province can't have more than one capital. This requires creating new campaign map provinces, making it much more difficult to do than this.

To add a new province to the game, open up the table called provinces and then click Add Record in the top right corner of the new window.

This table features two columns: key and onscreen.
The onscreen column just tells the game how the province with the corresponding key will be called in-game. You can change the name of the provinces in the game if there is one you do not like.

Province keys on the other hand are primary keys which follow the naming pattern:
[gameAbbreviation]_[campaignAbbreviation]_[provinceName]

Examples:

• The Empire's starting province is called wh_main_reikland. Warhammer game, main campaign and Reikland is the name.
  
• The Gloomy Woods province in the Eye for an Eye mini-campaign is called wh_dlc03_gloomy_woods. Warhammer game, dlc03 campaign and Gloomy Woods name.
  
• Argwylon's starting province in the Season of Revelation mini-campaign is called wh_dlc05_argwylon. Warhammer game, dlc05 campaign and Argwylon name.

You don't need to follow this particular pattern, buf if you're going to create multiple new provinces, you ought to follow a systematic approach in my opinion.

For my own mods, I usually use "zor" as a campaign abbreviation, as this helps me with sorting my database entries. Here I created the new province wh_zor_reikwald with the on-screen name Reikwald, which is supposed to be west of Reikland.



Now that we have a new province, we need to make sure our province is part of the correct region group.

For this, we open up the provinces_to_region_groups_junctions table.
This table's two columns are: region_group and province.
Here you can see that each province in the main campaign has a wom_region_group_[orientation] assigned to it. "wom" stands for Winds of Magic. [orientation] can either be north, east, south, west or central.

Mini-campaign provinces don't have region groups assigned via this table and I personally do not know why this is the case. Is it intentional? Did Creative Assembly forget to do this? Did they just do it differently for the mini-campaigns?

Anyway, to know in which region_group our new province should be, we best look at its neighbouring provinces. As my new Reikwald province is supposed to be just west of Reikland, wom_region_group_central is the correct choice for me here.



Now our province needs a mercenary set, so that local mercenaries can be recruited there. Luckily, only one province-bound mercenary set exists in vanilla Total War: Warhammer: wh_main_vmp_province_pool.
However, modders potentially have the possibility to add new mercenary sets to the game and assign them to special provinces.
Regional recruitment mods often do this. For now, adding wh_main_vmp_province_pool will be enough. This allows undead factions to animate dead in our new province, so basic undead units can be now be hired there.



This is most likely what you actually wanted to do when you first created your new province.
Open up the region_to_province_junctions table and take a look at the three columns available: region, province and is_capital.

The region column shows all regions currently assigned to a province via the province column.
is_capital is what IT people would call a boolean, so it can only be true or false. A region either is a province capital, or it is not.
Provinces can only have one capital, multiple capitals cause problems.
A region can not be part of multiple provinces at the same time.

As of April 2017, Creative Assembly has not yet given us the ability to place regions with custom borders and settlements on the actual campaign map, so we will have to make due with the ones already in the game.

So I want the Eilhart and Helmgart regions to be in my new Reikwald province. Eilhart will be the capital, so I'll just add two new records to region_to_province_junctions and assign both of these regions to wh_zor_reikwald, then everything will be fine, right? Nope.

This is the first table where we will need to delete entries to make our changes work.
Eilhart and Helmgart are already part of the wh_main_reikland province by default, so we need to find the corresponding entries and delete them from the table.



Remember: A province needs a capital. If you re-assigned a region which previously served as another province's capital, declare another region as this province's capital.

Reikland has now been split up into Reikwald, consisting of Eilhart and Helmgart, and Reikland, which now only consists of Altdorf and Grunburg.
Eilhart has been made capital of Reikwald, but it is still just another minor settlement, so how do we change that? On to the next chapter!

Open up the start_pos_settlements table. This one offers multiple interesting entries. It also contains many columns. Here are some important ones:

start_pos_settlements

• settlement_id is the internal name of the settlement.
  
  
• region refers to the region this settlement is located in. (This also defines a settlement's cultural_originator, e.g. Empire/Bretonnia/Dwarfs etc. but this value is controlled via the start_pos_regions table.)
  
  
• building1 up to building5 allow additional secondary buildings to be added to the settlement which will be present there right from the beginning of a campaign
  
  
• port_building defines which port is present here from the beginning. Can go horribly wrong if your settlement's slot_template doesn't allow for a port.
  
  
• primary_building defines with which primary building (the building responsible for the settlement tier level) this settlement starts out with
  
  
• onscreen_name is again just the name your settlement will have ingame

To make Eilhart's T1 primary settlement building a major one, we have to replace wh_main_emp_settlement_minor_1 with wh_main_emp_settlement_major_1 as shown below:



For coastal settlements, we would have needed the respective coastal primary building version.
But this alone is not enough to convert a settlement. There is more to it.


By now, you should know what a region is and that tables starting with start_pos are the databases in which the data about TW:W's campaign maps is stored. But what exactly is a slot template?
It's something Crynsos could probably write a whole book about by now.

No seriously, a slot template is something really cool. All regions in the game are built out of at least two components:

• a primary slot template (slot_type: primary)
  and
  
• a secondary slot template (slot_type: secondary)
  optionally, there may also be
  
• a port slot template (slot_type: port)

These templates define which buildings and resources will be available in the corresponding region's settlement during a campaign playthrough, and they are defined in the slot_templates table, something not yet covered by this guide.

There are generic as well as unique slot templates.
Let's take Altdorf for example. Altdorf uses both a unique primary slot template, a unique secondary slot template as well as a generic port slot template. If you ever had Altdorf in your posession while playing as an Empire or Vampire Counts faction, you clearly must've noticed that Altdorf has:

• a unique primary settlement building (wh_main_special_altdorf_primary)
  and
  
• one or more unique secondary settlement buildings (wh_main_special_altdorf_secondary)
  as well as
  
• a generic port building (wh_main_port)

You may want to take your time to look around a little in the start_pos_region_slot_templates table.

Let's focus on a generic settlement such as Eilhart, our minor settlement from the example which we still want to convert into a major one. To get a better overview of the situation, filter the table so that only Eilhart is shown.



We immediately notice that Eilhart still uses the minor versions of both the pimary as well as the secondary human settlement slot templates: wh_main_human_minor_primary and wh_main_human_minor_secondary. A port is something Eilhart does not have.
But we already made the settlement start out with a primary major settlement building using the start_pos_settlements table, so this way, it can only go wrong. The slot templates need to be changed for the Eilhart region.

While we're on it, let's add the timber resource to Eilhart. It's the capital of our new Reikwald region and "Wald" is just the German is the official Games Workshop licensed Reikspiel™ language word for "forest", or "wood", so I find this very fitting.

Resources can easily be added via a region's secondary component, for example through wh_main_dwarf_orc_major_secondary_gems or wh_main_human_minor_secondary_pottery.

Solving this problem is very easy too, here's how the result would need to look:



This completes Eilhart's conversion into a major settlement and thereby this section of my tutorial. More about slot templates coming right your way.

This section assumes you're already familiar with the following section of the guide:

Zorander lähetti viestin:

Settlement conversion and editing

2. A look into the start_pos_region_slot_templates table

[...]

As editing settlements and assigning different slot templates to them has already been covered earlier in this guide, we will focus on slot templates themselves now.

A quick reminder what a slot template is: Every region on the campaign map uses at least two slot templates to determine which building (super-)chains are available for construction in the settlement within the region, often depending on the owner's culture (Empire, Vampire Counts, Bretonnia ...).
It will get clearer down the line.


Now, on to the slot_templates table. Pretty compact with just two columns: The key column contains a slot template's internal name and the resource table determines which icons are displayed next to a settlement's name when using this particular template. Yup, the resource column just maps an icon to the slot template. The real work may be done elsewhere, but at least new slot templates can be defined right here.

res_location_x indicates the corresponding slot template has one or more special building(s) available for culture x, where x is either dwf, emp, brt, vmp, grn, teb, vmp or even a combination like res_location_emp_brt. These cultures will then get a little castle-like icon next to the city name, like for example Altdorf or Middenheim have when playing as an Empire faction.
Can a region have multiple resources? Yes, easily. Can the settlement info show multiple resource icons? Not without a little workaround.
I've listed all the existing common resources in the underlying table.



This table is 100% correct, even if some things might seem really weird. Yes, glass indicates Dwarfs can brew good beer here and the pastures icon is only shown if your region has oil. Also, pottery and textiles are exactly the same thing, just as salt and lead are one single element. Whatever.
Remember: These things just have a purely aesthetical impact on the game and can even be left blank.

Before we can proceed, we need to be aware of how building chains work. I'm assuming you already know what building levels and building chains are and how they look like from playing the game.
Every building chain in the game is listed in the building_chains table and consists of one or more building levels, which can be found in the building_levels table.

Building chains are assigned to so-called building superchains, found in the building_superchains table. These aren't clearly visible ingame. Their main purpose is to have multiple building chains governed by a single superchain, which is then assigned to a slot template.

Enlarge or view the picture below in your browser to see an illustration using the wine chains as an example.
Notice how the wh_main_sch_human_resource_wine superchain governs both the Vampire Counts and the Empire faction wine building chains to ensure each faction can construct their wine buildings exactly where the other one(s) can.




With the slot_template_to_building_superchain_junctions table, we have another very compact table at our disposal.
As you know already from the Settlement conversion and editing section, minor, major and special settlements use different primary and secondary slot templates and can optionally have access to port slot templates. Make sure you're still aware of what the differences between primary, secondary and port slot templates are.

If we want to add/remove building superchains to/from a slot template, we always have to keep all the regions in mind that will be affected by our changes. Altdorf, Middenheim, Nuln and Talabheim are good examples for easy-to-edit Empire regions due to their unique slot templates.
Averheim or Salzenmund would be examples for difficult to edit regions with impractical slot templates,
as they use very generic templates such as wh_main_human_major_primary, wh_main_human_major_secondary or wh_main_human_major_secondary_timber.
These generic templates are shared with many other regions in the game, so everytime we add/remove superchains to/from them, every region in the game using one of these templates will be affected.

Should we desire to add a building superchain to Nuln, we can do so just by adding a new entry to wh_main_special_nuln_secondary.
In the picture below, I made both the "Conclave of Battle Wizards" (T4) as well as the "Colleges of Magic" (T5) buildings available in Nuln, and solely in Nuln. This is the power of a unique slot template; no startpos edits are necessary.



Here are Averheim and Salzenmund, examples for regions using generic slot templates




In the following picture, I made the "Conclave of Battle Wizards" (T4) as well as the "Colleges of Magic" (T5) buildings available in every region using the wh_main_human_major_secondary slot template. On the right side, you can see how many different regions across all available campaigns will now have access to these buildings:



21 different regions across all three campaigns! This is going to lead to some very awkward results. We should only consider making edits like these if we are absolutely sure that all of the affected regions genuinely need the correlating building superchain(s).

To sum it up:

• regions with unique slot templates are easy to edit without the necessity for startpos tweaks
  
• regions with generic slot tempates a rarely easy to edit and usually, multiple regions will be affected by just one tweak

Clearly, this situation demands more precise edits.

Let's start with the bad news: Upgrading campaign map regions with impractical generic slot templates to properly configurable ones requires startpos edits. There's just no other way to tell these regions: "You're now a special snowflake in your very own way" without touching the campaign map. Meh.

As I've covered all three relevant tables for slot templates (2 in this section, 1 in a previous one) now and sections actually have character limits, (thanks Obama Gabe), I'll leave you here with a to-do list and some pictures:

1. Make yourself clear what your slot template should be based on. A unique human major settlement perhaps?
   
2. slot_templates table: Define both a primary as well as a secondary slot template. Remember what the resource column is good for. Is the region going to be a strategic location?
   
3. slot_template_to_building_superchain_junctions table: Assign all relevant building superchains. Who is the region's cultural originator? Empire? So brt, vmp, ksl, teb and wef cultures could capture the region too. Think about them. Does your template have access to resource related buildings?
   
4. start_pos_region_slot_templates table: Assign your slot templates to the campaign map regions. Primary template in the primary slot, secondary template in the secondary slot. Optional: port templates in port slots

Make sure you've applied all of your changes and no errors appear. Then click on Export in the bottom left corner and click Export Changes to Binary



This isn't necessary if you've only modified tables belonging to the start_pos_<table name> group. Since we've modified campaign_building_chain_slot_unlocks, this step is required.

Before processing the startpos.esf, a quick reminder from the beginning of the guide:

>>>>>>>>>>>>>>>>>>>>>>>>>>>>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<

a) Either exit the Database Editor completely, open up the Assembly Kit again via Steam and launch the Exporter called "Bob".
Or...
b) Manually browse to ...\steamapps\common\Total War WARHAMMER\assembly_kit\binaries and open up BOB.AssemblyKit.exe.
The second way will allow you to have them both open at the same time.


Bob shows only a few collapsed folders after opening. Within these folders we can usually find other collapsed folders or some files. Currently, it is not necessary to expand anything else besides
campaigns and then main_warhammer

There is a button in the bottom left corner called Select all which you definitely should not use.
It just marks everything for export and Creative Assembly probably uses it when shipping major game updates. Unselect all can come in handy, though.




Click the checkbox to the left of startpos.esf once. A small window should open up.
In our case, we need to tick Campaign / Process start pos (main_warhammer) as well as Pack / Create pack file (mod.pack)




As already mentioned twice, ensure that you've unticked all mods in your game launcher before clicking Start.
I've already had issues with my mods when not doing this, but I don't know how often/rare they are.
The Assembly Kit will now launch your Total War: Warhammer game to process the startpos.esf file. The game will not respond to your input and only show the loading screen and closes automatically when finished.

If everything has worked out, your mod has now been exported to a file called mod.pack located in ...\steamapps\common\Total War WARHAMMER\assembly_kit\retail\data

Let's copy mod.pack to ...\steamapps\common\Total War WARHAMMER\data and open it using iamdaniu's Pack File Manager[sourceforge.net] (PFM) you downloaded earlier.

You can either set the PFM as default application for files ending on .pack or open it up manually by clicking PackFileManager.exe.
It will probably ask you to point it to your Total War: Warhammer installation directory.

If PFM is the default application for .pack files, just open mod.pack by double clicking it.
Otherwise, go to Files -> Open... in the top left corner and select your mod.pack

You should see something similar to this:


If a folder is highlighted in blue, this means there is at least on empty table in there.
If a table is highlighted in blue, it's completely empty.
I usually delete empty tables or rename them in a unique way because I am somewhat afraid they might conflict or even overwrite other tables with the same name. Maybe they're harmless, but I usally remove or at least rename them.
Empty folders on the other hand shouldn't cause issues if they're really empty.

If you've got two folders called terrain and text in there, it is usually safe to delete them and all of their content in case you did neither edit text nor terrain.
If you've changed a province's name, the presence of provinces.loc and provinces.txt would be justified. Same goes for name changes regarding buildings, units etc.

I've never edited any terrain, so I always remove terrain folders from my mods

Why are these folders in there even if we haven't changed any terrain/text? I'm not actually sure. How do I know they can be deleted safely? I always test it beforehand.
Leaving them be could potentially cause compatibility issues with mods that actually change terrain or text!

One table that should definitely not be highlighted in blue for you is the data__core table within campaign_building_chain_slot_unlocks_tables.


>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

There is only one situation where a table named data__core should not be renamed:
Keep the name if you intentionally want to remove content from the game!
Tables with default names will overwrite the game's original tables and if the overwriting tables lack entries the original ones had, the corresponding content will disappear from the game!
Keeping default table names is an easy way to make your mod highly incompatible with other modding projects.

For renaming, you could use your Steam username (if it isn't something popular as John Cena or the like) followed by _data__core. My tables are often called zor_data__core or use an acronym formed by taking the initial letters of the words within the mod name, like pcbso.

You could now manually add entries to any of the tables using PFM if you'd happen have forgotten anything, but this is more difficult than doing it beforehand with Dave.
As an example, wh_main_GREENSKIN_settlement_major_coast could be inserted into the table even afterwards.
Editing the startpos.esf with PFM is not advisable in most cases.


Here's how my personal mod Province Capital Building Slot Overhaul looks after this cleaning process:


If your mod is positioned in ...\steamapps\common\Total War WARHAMMER\data, you are now able to activate it in the Total War launcher. Don't worry if it shows up as out-of-date, this is the case with all local mods not uploaded to the Steam Workshop.

You're done.
Thanks for reading!

Subscribing to a mod in the workshop makes Steam download a file called <mod name>.pack to your ...\steamapps\common\Total War WARHAMMER\data folder.

The game loads its mods from A to Z but adheres to the principle of "First-come, first-served", where mods loaded later down the line have their changes discarded, should they edit content that has already been modified by a mod loaded earlier.
The de facto order of importance thus goes from Z to A, where Z is the least important starting character and A is one of the most important ones.
Consequently, a mod starting with A will always 'overwrite' (figuratively speaking) content from a mod starting with Z, should both of them edit exactly the same thing.

This part previously stated that mods were loaded from Z to A, because I was trying to simplify the order of importance instead of explaining the load order mechanics. In the end, I just did not get it right. Thanks to heinous_hat for suggesting a better explanation

Two special characters which should be accessible easily via most keyboards are ! (exclamation mark) and @ (the at sign known from eMail addresses), are considered even more important than A by the game's load order mechanics.
A mod starting with @ will overwrite mods starting with A, a mod with a ! in front of it will even overwrite mods starting with @.
!! is even more important than ! [...]

While modders have the ability to influence load order for mods which only change regular database tables by renaming them, therefore allowing multiple entries added to the same table to be compatible, the startpos.esf follows a strictly defined structure.
No renaming tricks allowed here. But mods like my Province Capital Building Slot Overhaul (now referred to as PCBSO) need to edit exactly this file to add most of its changes to the game.

Suppose you have three mods activated which all edit the main campaign map by including a startpos.esf file within their respective .pack archives.

• apple_store_starting_building_for_all_capitals.pack
  
• province_capital_building_slot_overhaul.pack
  
• zoo_animal_mercenaries_for_all_regions.pack

So what happens?

1. the Apple stores for all capitals mod overwrites the default startpos.esf
   
2. the startpos.esf from my PCBSO mod is discarded, as P is less important than A
   
3. the startpos.esf from the zoo animal mercenaries mod is discarded as well, as Z is even less important than both P and A

At the end of this chain, you're now only using the campaign map tweaks from apple_store_starting_building_for_all_capitals.pack and content from the other two mods is missing. Crashes on startup are also a potential side-effect.

CA has not implemented proper load order sorting yet and Valve doesn't allow modders to change their mod's file name once it has been uploaded.

So if you wanted to increase the load order priority of my province_capital_building_slot_overhaul.pack, you'd have to manually rename my mod's pack file called province_capital_building_slot_overhaul.pack to !province_capital_building_slot_overhaul.pack and then check the one starting with a ! in the mod launcher.
Make sure the PCBSO file without a leading ! remains unchecked while the renamed one with the ! is active.

Is this a good solution? Not really. Only if the overwriting mod is specifically designed to provide compatibility for the overwritten startpos mod. Most of the time, you will lose out on some content or even get a crash on startup.

In the launcher, it would need to look like this:

Creative Assembly uses many abbreviations within the internal databases.
I've tried to assemble and explain some important ones here:

DLC abbreviations:

• main (The main game obviously. Not really DLC)
  
• dlc01 (Chaos Warriors Race Pack DLC)
  
• dlc02 (Blood Knights unit pack FLC)
  
• dlc03 (Call of the Beastmen DLC and Empire Amber Wizard FLC, maybe blood dlc as well)
  
• dlc04 (The Grim and the Grave DLC and Vlad FLC)
  
• dlc05 (Realm of the Wood Elves DLC and Jade + Grey Wizards FLC)
  
• dlc06 (The King and the Warlord DLC and Wurrzag FLC)
  
• dlc07 (New Bretonnian units and buildings not previously in the game)
  
• pro01 (Grombrindal The White Dwarf FLC)
  
• pro02 (Isabella von Carstein FLC)

Racial abbreviations:

• brt (Bretonnia)
  
• bst (Beastmen)
  
• chs (Chaos)
  
• dwf (Dwarfs
  
• emp (Empire)
  
• grn (Greenskins)
  
• ksl (Kislev)
  
• nor (Norsca)
  
• savage (Savage orc stuff used by the Skull-Takerz or the Topknotz. Wurrzag does seem to use the grn versions)
  
• special (Often used for unique buildings such as the Karak Eight Peaks building)
  
• teb (Tilea Estalia Border Princes)
  
• vmp (Vampire Counts)
  
• wef (Wood Elves)