Skip to content

DataModel Triggers

Introduction

There are several places where games and tools would like to hook into the model framework this document describes the various use cases in an attempt to find a common solution.

Use Cases

(Skyrim/Fallout) Generate Plugin.txt

The game needs to generate a plugin.txt file based on the sorting information on the plugin files.

  • Inputs: Flattened List
  • Needs Rerun: Whenever the Plugins or their metadata changes
  • Phase: During list application
  • Conflicting stats: We need to update the metadata for the file so on the next run we know if we need to re-create the plugin.txt file. Also the differ may need to know a hash/size so it can properly detect changes.

(Cyberpunk 2077) Run Redmod

The app needs to run Redmod whenever files in certain folders change, and before the game is run, this creates new files in the game folder.

  • Inputs: Flattened List
  • Needs Rerun: Whenever files in the "mods" folder change
  • Phase: After list application, before the game is run
  • Conflicting stats: The files generated by Redmod need not be tracked as we can recreate them when needed by re-running Redmod

(Skyrim/Fallout) Merge ini files

Skyrim has several INI files and mods will often ship with "patches" for these files

  • Inputs: Flattened List
  • Needs Rerun: Whenever the inputs change
  • Phase: During list application
  • Complicating Factors: The files are never written to disk except as part of a larger whole the app needs to track the changes and remerge them. Unlike Generate Plugin.txt the source file itself is never extracted to disk, only the merged file.

(Bannerlord) Set mod sort data

Bannerlord needs to set the mod sort data, but for that to work it needs to resolve mods with specific traits down to ModIds.

  • Inputs: Flattened List
  • Needs Rerun: Whenever the inputs change
  • Phase: Before mod sorting
  • Complicating Factors: If the app doesn't want to run the extension on every run (and we don't) we need some way to write the results back to the list so we can use them on the next run.

Common Requirements

Rerun on change of inputs

Most of the above cases require a change when certain inputs change. This means we need a way of feeding the code a list of strings/ids/etc. and somehow knowing if they have changed from the previous run.

Files that exist in the loadout but don't have a To

Right now, all files in a modlist must have a To folder. But in several of the above cases we need files to be accessable by the loadout but they do not end up directly in the game folder so they will never have a To.

Files that should not be backed-up

Some files should not be backed up as they can be recreated on demand. Redmod output, logs, and plugin.txt are examples of this.

Redesign of the Model

Model

Firstly we will need to update our ModFile objects so that they are much more abstract, allowing for games to create file types that mix and match features from our existing model.

  • IToFile: This is the interface that specifies the To location, and will be implemented by all files that are to be copied to the game folder.
  • IFromArchive: This is the interface that specifies the Hash of the file that will be located from within the ArchiveManager
  • IGeneratedFile: This is the interface that specifies that the file is generated by the app and should not be backed up.