-
Notifications
You must be signed in to change notification settings - Fork 16
Updating to new game versions
This is a document for developers of tiger. Users are not expected to be able to do this.
The source code contains // LAST UPDATED ... comments, usually above tables of some kind. These help point at the things that may have to be re-checked or re-tested for new game versions. Ideally, the comment also includes which game is meant and where the information in the table came from.
The files like triggers.log and effects.log and modifiers.log are sorted alphabetically and then diffed with the previous version of those files. Anything new can be added to tiger (usually in tables modules), and anything that got removed can be changed to Removed entries or moved to REMOVED tables. (If no REMOVED option exists for a kind of table then it makes sense to create one; having warnings saying "this was removed in version V and replaced with X" is very helpful for users).
There is a tool sort-log.py in the git repo that can do the alphabetic sorting, though not for all of the log file types.
If there are new Scopes types, they need to be updated in several places: the general Scopes bitflags, the per-game scope_from_snake_case function, and the per-game display_fmt function.
There is a tool munch-data-types (under the utils crate) that can read the data_types logs and update the files under tables::include for the given game type. After running it you can check its changes and then check those in to git. Especially check that the tool didn't un-do improvements to the table, such as more specific argument types.
For ck3 you'll have to provide it a list of game concepts (including aliases). I just use some regexps to extract those from common/game_concepts.
munch-data-types doesn't work for Imperator because its format is different, but Imperator is not expected to get game updates.
I have the entire ck3, vic3, and imperator script files checked into git locally, so I can diff between the old and new versions. (I use .gitignore to avoid storing the huge graphical files).
The diffs are generally too large to study in detail, but it helps to look at any diffs to .info files to see what needs to be updated in the data modules.
I do a find common -type d to regenerate the COMMON_DIRS table, which is used to warn about files in folders that have the wrong names. I have to manually adjust it to for example remove the directories under common/decisions/, which can have multiple subdirectories.
Any new directories should be noted, because they show a need for new data modules to load and validate that type of content.