Empire Mod Architecture Primer

[JeromeGrasdyke]

Hi All,

Since the mod community seems to be moving full speed ahead and you've already got some basic mods up and running I thought I’d explain the way the Empire modding system is intended to work. This should enable you to work with it, not against it, and hopefully avoid breaking things released by CA in the future.

First of all, the ETW data is meant to stay packed. The pack file system and the virtual file system that it builds internally within the game are central to the patching and modding systems, so please don’t ask users to unpack their data in order to run with your mods.

So how should you mod the game? Well, it works like this. Empire loads –all– files of type .pack in the data directory in a certain order determined by the pack’s type. There are three basic types – release, patch and mod. The fifth byte in the pack file header is an numerical id which tells the game what a pack is, release packs are 0 or 1, patch packs are 2, mod packs are 3. The game then loads release packs first, then patch packs, then mod packs.

At game startup, the file entries in all of these packs are mounted into a virtual file system, and if the game finds an entry in a later pack which has the same name and location as an already existing entry, the new entry replaces the old. This means that a mod pack can replace any file in the vfs and add new ones as well, without asking the person who downloaded the mod to overwrite files on disk and destroy data.

So basically, a mod is intended to be a single “mod pack” file, and installing a mod is just placing that pack inside the game’s data directory, and uninstalling it is removing it. There’s a little bit more to it than that, for example there is a mechanisms to control mod pack load order, but that’s it in a nutshell.

Now, a note on how to work with the databases. You’ll have noticed that each table in the databases (inside the db folder) is both a folder and a binary file. When the game instantiates the databases, which happens after the virtual file system is built, it scans each directory and parses –all– of the binary files it finds. This means that a mod pack can add a new binary data fragment inside the db/unit_stats_land_table folder which adds several new units, and the game will add them to its land units database. The fragments are processed in the same order as the pack files, and any new database records with the same name as an old record will cause the new to replace the old. This means that you can replace any record within the database without touching the rest of the data or modifying the CA-supplied files on disk.

For example, say the CA packs contain a unit record for ‘french_dragoons’, which is one entry out of hundreds inside the shipped unit_stats_land_table data fragment, which is used to build the unit table that was available at launch. Now say you create a mod pack which places a new data fragment, say called my_mods_unit_stats_land inside db/ unit_stats_land_table, which contains just one data record for ‘french_dragoons’. What will happen is your new record will end up replacing the current record for that unit in the game data, and the rest will stay as it was originally.

So… hopefully you’ll now have a good idea of how the modding system was architected, and how you should build tools to work with it. There’s also another interesting consequence of how the system works, which is that it opens the door for mods built on top of other mods…

One more thing to keep in mind is that we've not yet finished testing the mod support fully - that's part of what's happening here before the mod dev package gets released. Also we’re aware that there is currently an upper bound of about 6000 files in a single pack. And you should know that there is some overhead associated with mounting a pack, and a data directory filled with scores of them will make the game startup time significantly longer.

The other thing I should mention – since you’re going to be experimenting with this – is that the game checks the final database integrity after loading mods. So if you add a pack file which includes a new unit record which doesn’t include a display model or is invalid in some other way, the game will unload that mod pack (though it keeps the rest). This isn’t the main error checking mechanism in the ETW data pipeline, that’s done elsewhere, but as modders you should be aware of it. Unfortunately there currently isn’t any log output on the reasons why the mod failed to load, we’re looking into adding that when the modding dev kit is released.

Armed with this info you’ll at least be able to work with the system as it was intended, without having to wait for the mod dev package. I have to say it's great seeing you guys making headway so quickly. The pack and database inspection tool was a great start, I think, and really bodes well for the future of the Empire modding scene.

Good luck!

[l33tl4m3r]

Thanks for the info!

Makes me all warm and fuzzy to see this kind of support from a developer.

[Aldgarkalaughskel]

Thanks, this is really useful.

First of all, the ETW data is meant to stay packed.

Just a small correction: the game flawlessly runs with unpacked files as well. Which means you don't have to repack everything to a .pack file. Actually it's quite useful to keep everything unpacked, so that you don't have to mess with repacking after changing a single file.

edit: just a quick question, will we receive an importer for 3ds Max (most likely an maxscript) to import the model files? And then, of course and we'd need an exporter created by CA to re-export the models back into the game. Thanks for the answer in advance.

[Björneborgs regemente]

Thank you!

[Abel12512]

Thanks for the info

[izanagi11]

Cool beans! Great info on the header data and any logging would be great. Spent a few hours trying to figure out how to turn that on, I feel better now...

[Takeda Shingen]

Thanks from me too.

Very good that you CA's keep a focus on all these talented guys around.
And even better that you provide useful hints!

Thank you!!!

[Mooncabbage]

Yay, thanks for the support

[Iaius Statius Laurentius]

Hah, this is beautiful. The information about how mod packs work is very useful, and puts my mind at ease. Once the pack editor implements the use of mod packs, I'll be able to restore all the CA packs as they were and (more importantly) we can all free ourselves from the fear that a sudden patch will eat all our mods. The ability to add single-entry database files is absolutely wonderful, too.

And I'm very excited about the upcoming mod dev package!

Thanks so much for letting us know. I am now much at ease.

[Björneborgs regemente]

Hah, this is beautiful. The information about how mod packs work is very useful, and puts my mind at ease. Once the pack editor implements the use of mod packs, I'll be able to restore all the CA packs as they were and (more importantly) we can all free ourselves from the fear that a sudden patch will eat all our mods. The ability to add single-entry database files is absolutely wonderful, too.

[waronmars]

YAY!

Just when I needed info about load order

[alpaca]

I hate to be a party pooper but Jerome, this doesn't work as you say. The mod packs are not read at all instead of updating the patch packs. I tested this with an export_triggers.lua file that works (tested on the filesystem first) and with a trait levels effects db that I tested in patch.pack; last but not least I also tried adding a new binary piece to the trait levels effects table but none of the three worked.

I already tried creating a pack with 3 as a flag a week ago but they're simply ignored by the game

[Aradiel]

Great, i go under the shower, come back and read this

Now my skin will hate me for that but if i go again will there be mod tools when i come back ?

Thanks for the info, it looks pretty much like the nwn architecture exept that data fragments which i did not quite understand

[MrThib]

Thanks a lot, that's very helpfull indeed !!!

.... last but not least I also tried adding a new binary piece to the trait levels effects table but none of the three worked.

I've actually add a new binarie in a custom patch file wich add new battle personalities and it work in game (I've put it in the DB\battle_personalities_table\ but gave it an other name like My_personalities and just put in the new rows).

[JeromeGrasdyke]

I hate to be a party pooper but Jerome, this doesn't work as you say. The mod packs are not read at all.

Ok, it looks like I will need to go into a bit more detail about declaring mod packs to the game. You currently do need to tell the game which mod packs you want to have active. You do this by passing the game a script command for each mod you want to have active.

Here's a step-by-step guide:

- find your preferences.empire_script.txt file (in Application Data on an XP machine)
- create a new text file next to it called user.empire_script.txt
- inside there, list your mods like this, one line per mod:
mod my_pack.pack;

The user script gets processed on load, and will tell the game to load your mods in that order. There are a whole bunch of other commands that can be used from there, including dependency definitions and so on, but we'll leave those for now. As I said, this is a quick preview of mechanisms that will be properly documented in the mod dev package.

So, about running 'unpacked'. Yes, the game currently will run unpacked, but doing that will alter the way in which the data precedence works in some cases, which means that as we add more patches it's not guaranteed to keep working. It may be convenient to work that way while tinkering with a mod, and that's fine, it's exactly why the feature exists, but I'd strongly recommend against giving other people mods which work like that. One last note - LtChambers is actually correct when he's seperating the released packs by CA into 'boot' and 'release' categories, but it's a minor distinction which has no real practical value from your point of view - for a modder, the two might as well be identical

[Björneborgs regemente]

[Takeda Shingen]

Hi Jerome,

sorry for asking this here, but can you estimate, just ruffly, when you are planning to release this tool? Or at least a guess

Or is this confidential?

And again....
A lot of

[Birdofilo]

Here's a "step-by-step" :

- find your preferences.empire_script.txt file (in Application Data on an XP machine)
- create a new text file next to it called user.empire_script.txt
- inside there, list your mods like this, one line per mod:
mod my_pack.pack;

This is not enough for me. I'm not an expert modder. Could someone write a more detailed "step-by-step" tutorial?

[l33tl4m3r]

This is not enough for me. I'm not an expert modder. Could someone write a more detailed "step-by-step" tutorial?

Creating a user.empire_script.txt.
The folder you seek does reside at the address given but it is a hidden system folder and you need to be logged on as an administrator and have set the view properties to show system files/folders.
This is done by opening My Computer >> Tools menu >> Folder Options >> View tab >> select Show Hidden Files and Folders and deselect Hide Protected Operating System Files.

Click on the Apply button then click on the OK button, and close the window in use. When you reopen the My Computer window and follow the path this should enable you to see the folder.

C:\Users\YOURUSERNAME\AppData\Roaming\The Creative Assembly\Empire\scripts
for Vista
C:\Documents and Settings\YOURUSERNAME\Application Data\The Creative Assembly\Empire\scripts
for XP

Inside one of these folders you should find preferences.empire_script.txt.

Once you find this file, right click and select "New" then "Text Document".

name this new file user.empire_script.txt.

---

Once you have created this file, edit it and add whatever mods you have inside your Empire data folder.

---

Hope this helps!

[♔Dignan♔]

Ok, it looks like I will need to go into a bit more detail about declaring mod packs to the game. You currently do need to tell the game which mod packs you want to have active. You do this by passing the game a script command for each mod you want to have active.

Here's a step-by-step guide:

- find your preferences.empire_script.txt file (in Application Data on an XP machine)
- create a new text file next to it called user.empire_script.txt
- inside there, list your mods like this, one line per mod:
mod my_pack.pack;

The user script gets processed on load, and will tell the game to load your mods in that order. There are a whole bunch of other commands that can be used from there, including dependency definitions and so on, but we'll leave those for now. As I said, this is a quick preview of mechanisms that will be properly documented in the mod dev package.

So, about running 'unpacked'. Yes, the game currently will run unpacked, but doing that will alter the way in which the data precedence works in some cases, which means that as we add more patches it's not guaranteed to keep working. It may be convenient to work that way while tinkering with a mod, and that's fine, it's exactly why the feature exists, but I'd strongly recommend against giving other people mods which work like that. One last note - LtChambers is actually correct when he's seperating the released packs by CA into 'boot' and 'release' categories, but it's a minor distinction which has no real practical value from your point of view - for a modder, the two might as well be identical

How do we do this with mods that don't have .pack on the end? For instance, the projectiletrail mod that goes in the FX subfolder...how do we create a patch compatible mod pack for these kind of files as described above?