I got my scripts working. They're not pretty, and I'd need to make more changes before I'd release them - but I very well may do so, as you should be able to handle arbitrary campaigns with it with some additional tweaking.

Here's what I've learned so far in my adventures programmatically modding TW:
* It's best to copy the assmbly_kit elsewhere, so you can easily get back to a fresh slate.
* You can use the raw_data/*.xml files as inputs for generating various tables and pieces of information.
* If you write your changes back to raw_data, you can use BOB to export your changes. (DAVE, unfortunately, does not show these changes.)
* It's best to generate only the parts you can separate into a table at a time, as PFM has limited to no support for slicing up tables inside it.
* BOB cannot export the dlc03 startpos file for unknown reasons; I'm guessing CA will never fix this.

Here's what I've accomplished:
* I have succesfully generated modular_settlements{_ports, _primary ,_secondary} tables for slot_templates and slot_templates_to_building_superchain_junctions for dlc03 and dlc05.
* Special settlements - like Carroburg, Marienburg, or Middenheim in dlc03 - have distinct slot templates but are synced up to the main campaign version in terms of allowed building superchains.
* I've also generated the conquer_everywhere tables (including the chaos/beastmen versions) for each mini-campaign as well.
* Following the lead of the Wood Elves occupation mod, you should also be able to conquer Wood Elf settlements as other races in dlc05 - you'll still need the Wood Elves occupation mod on top of it.
* I've updated the startpos region slots for each dlc, and done some testing to make sure everything is set appropriately.
* I did not break up another table for unique_faction_superchains - my code handled this automatically in the other tables.

Here's what I don't know:
* What is the zzcrynsos_compatability_fixes table I see in some mods? Do I need to do something with this?
* What's conquer_anywhere_override for? I think it's for adding template-to-superchain mappings for resource buildings for races that don't normally have a building superchain for the resource associated with that template?

May I ask how you handle startpos changes? For this sort of work, where all I'm doing is updating an existing slot template field, I've been going through PFM and updating the fields by hand. I'd like to generate the appropriate XML instead (I already can) and force BOB to export them for me. However, I don't have a version of the XML with your changes, so I'd mostly end up overriding any of your other changes to those startpos files.

I'll probably upload it as a private mod sometime tomorrow, including my updated startpos files for the mini-campaigns - they'll conflict with and override your startpos files for the mini-campaigns, but that's fine because they're the same files except for the region-to-slot mappings changed.

Well, I can certainly customize the slot templates for the Mini Campaigns as that is not too much work, although I hope that you actually make good use of them to make it worth it.

If you really want to edit my startpos files, then it's a good idea to document what you changed where as the structures of those can be quite obscure and I will need to change them to include those new slot templates and other things. There are also many changes that can be done via scripts or other means with sufficient knowledge, so if I know what you want to do, then I might be able to better help with it.

Though quite honestly, I wouldn't put too much work into the Mini Campaigns for the time being, as I doubt many people will really bother with them anymore now that Warhammer 2 is about to come out and many will probably completely uninstall the first game as they won't play the Mini Campaigns anymore and can save SSD space by just playing the combined map instead of the game 1 main campaign.

Thus of course I will also focus my limited time on modding Warhammer 2 primarily.


I always back up my assembly kit raw files every so often and after significant changes, alongside with the occasional full assembly kit backup for data comparison between versions, especially for importing data from old game versions into newer ones. I also back up every single one of my mod updates.

DAVE does accept pretty much everything you enter into XMLs, as long as it is properly structured, but you may have to disconnect and reconnect to the database for it to accept the new data. Though generally, editing this way only makes sense if you want to enter stuff like fixed IDs for certain things, as it is too crude and prone to problems otherwise.

All the table editing I do in PFM is manual, so you can do as much as you can think of in regards to slicing up tables, most of what I do is simply copypasting.

The Beastmen Campaign export seems to be broken since somewhen this year, which is why I have not really much interest in dealing with it again, aside from that it was always a very unpopular DLC anyways. Fixing that would require going back many versions, which is problematic as that can't be natively done with the Assembly Kit.

I actively avoid any settlement slots that have been customized already, for less work, future compatibility issues and general compactness of my already oversized tables.

I have no idea what you mean with "Wood Elves occupation mod", but other races settling in the Wood Elves settlements was never loreful nor balanced, so I never bothered with it.

Regarding the compatibility fixes, that depends on what mod you are referring to of course. I do have various support data for other mods in mine and of course vice versa.

Conquer Anywhere Overrides are a small set of changes that I made myself, concerning only Wine, Beer and Gemstone buildings, of which I made new versions for the appropriate factions, so that humans can for example also build Breweries in Dwarfen settlements with the Beer resource.

All of my startpos stuff is either copypasting from past versions of my tables or manual editing of tables in DAVE, I don't really bother doing any automation or editing XMLs outside of that to avoid potential errors or missing data.

> Though quite honestly, I wouldn't put too much work into the Mini Campaigns for the time being, as I doubt many people will really bother with them anymore now that Warhammer 2 is about to come out and many will probably completely uninstall the first game as they won't play the Mini Campaigns anymore and can save SSD space by just playing the combined map instead of the game 1 main campaign.

<sigh> Between that and the broken Beastmen startpos exporter, I think you've convinced me to shelve this. I'd like to contribute somehow, but this probably isn't the right thing.

> I actively avoid any settlement slots that have been customized already, for less work, future compatibility issues and general compactness of my already oversized tables.
That's probably best for the main campaign, but the mini-campaigns are extremely inconsistent in whether or not special cities even have the correct special slots assigned. For example, Marienburg and Carroburg are missing most of their special slots - Marienburg was only give its port slots by default.

You should keep the special slot names for the reasons you stated, but you'll also need to add some of them in the first place for the mini-campaigns.

> I have no idea what you mean with "Wood Elves occupation mod", but other races settling in the Wood Elves settlements was never loreful nor balanced, so I never bothered with it.

I didn't say I liked the mod, just that it's around and part of the 'Conquer Anywhere' family of mods. I was mostly looking at it to make sure I didn't break it.

> All of my startpos stuff is either copypasting from past versions of my tables or manual editing of tables in DAVE, I don't really bother doing any automation or editing XMLs outside of that to avoid potential errors or missing data.
Avoiding errors is actually why automation is useful, but only if you can make it smart enough beforehand. It'd be nice to run scripts to accomplish creating various things off the bat instead of needing to manually remember a large set of tables and all the interlocking values.

PFM does some of the understanding of foreign keys, but it's not a thing you can interact with easily from code.

Originally posted by wtchappell:

That's probably best for the main campaign, but the mini-campaigns are extremely inconsistent in whether or not special cities even have the correct special slots assigned. For example, Marienburg and Carroburg are missing most of their special slots - Marienburg was only give its port slots by default.

Makes sense from CA's perspective, as the two races that the Mini Campaigns are all about either destroying all cities by default or bringing their totally own building trees alongside them to overwrite pretty much any others by default.

Marienburg never had anything special to it anyways other than the port and the only reason why they even have a unique primary slot template is because they are the only human major city with the dyes resource.

As for Carroburg, it is meant to die off too quickly in the Mini Campaign for anyone to care about their special building (and human factions in that campaign can't even resettle by default), so it makes sense for them to leave out those details.

You should keep the special slot names for the reasons you stated, but you'll also need to add some of them in the first place for the mini-campaigns.

As I said, I never got any real feedback in how much people used the unlocked Mini Campaign factions at all, so I never saw much of a point to invest more time into them than I already did.

I mean I did invest a lot of time into the Beastmen campaign and even customized the buildings around many of their settlements to make them more of a challenge against Beastmen and did give Middenland their own slot template and the associated great temple of ulric, but it just never seemed to pay off as I never got any real feedback from it.

The Wood Elf Mini Campaign never really had any unique settlements anyways, which weren't already handled by CA.

Avoiding errors is actually why automation is useful, but only if you can make it smart enough beforehand. It'd be nice to run scripts to accomplish creating various things off the bat instead of needing to manually remember a large set of tables and all the interlocking values.

PFM does some of the understanding of foreign keys, but it's not a thing you can interact with easily from code.

Of course I'm aware of that and I realize my own lack of knowledge in that department, hence the only real automation I use is search & replace functions, although that is usually all I need anyways.