When using mods, one fundamental thing that players usually want is to use a lot of mods at the same time. Making the work of various modders work together, especially when they mod the same files (like database tables), can be problematic. Thankfully, Patron has a system to handle this well. Let's dive into dynamic database tables.
Databases and what are they used for[]
Basically anything you want to do, change or add in Patron, is almost certainly linked in a database table. The game uses these tables to fetch stats, parameters, model file paths etc. The only way to bypass editing a database table if you're only interested in changing some asset already existing in the game. But don't worry, editing tables is not a problem.
Editing a database table[]
All database tables reside in the Data\Base folder. Which table you'll have to edit depends on what you're adding to the game. Database tables are saved as plain text files with the .wdt extension, which means you can easily open it up in a program as simple as the Windows Notepad. We suggest using Notepad++ however. A good practice for editing tables is the following:
- Open the .wdt in Notepad++
- Copy the entire contents of the file to clipboard
- Open a new spreadsheet in Microsoft Excel, OpenOffice Calc or Google Sheets.
- Make sure to set all fields to Text to prevent any automatic formatting into dates or currencies or whatever.
- Paste the data from the clipboard into the spreadsheet
- Modify the values to your heart's desire.
As a side note, adding columns is pointless, since the game won't use them and can only get confused, so please don't even try doing that ;).
Setting up a modded database properly[]
The following bit is IMPORTANT. The modded tables should ONLY contain the new or changed entries, the difference. This means that if you're, for example adding a single building into the game, your modded Buildings.wdt needs only to contain that ONE entry. When the game loads up your mod, it cross-references your database table with the default table (or however many other mod tables). If the entry is new it adds your new entry to the dynamic database existing in-memory. If it already has this entry, then it overrides it with your new parameters.
But how does the game know what is new and what exists?[]
That's a very good question and the answer is Keyname. Be very careful with this column in database tables. Keynames in the same table MUST BE UNIQUE. The game cross-references the keynames! Also a good practice is to think of a keyname naming convention that will be your very own, to reduce the chance of other mods colliding with yours. It can always happen. It simply cannot be avoided entirely.
This seems shady. What's the load-up process exactly?[]
This is what happens when the game starts:
- The game loads up all the default content.
- Then it checks for any DLC content, and if any is found, it is added to the already loaded content. Some things can be overwritten, some things can be added as completely new. If the same database table exists in both the base game and the DLC, the table is merged in-memory.
- Then the game goes over all the activated mods and does the same thing as for DLCs.
And that's it! Nothing magical going on here. In theory, an unlimited number of mods can work together, but as always, if two or more mods are changing the exact same file, only one can be used (database tables are excluded from this as noted previously).
Databases[]
All of the above explains how database tables function, what they are used for in general and how they can be modified etc. Useful stuff, but it doesn't go into much detail on what each table does exactly, so let's dive into that:
|
|
|
|
|
|
|