Known Master Listings

[Noggog]

Starfield needs its master files around for determining their master style. However, when running spriggit CI or other environments, the other mod files and Data folder in general might not be present.

It would be good to have some sort of system/file that users could define that took its place. For example, some file might be called spriggit-masters.json and might contain:

[
   {
       Master: "SomeMaster.esm",
       Style: Light  
    }
]

The systems could pick this up, similar to .spriggit files, and use this information instead of needing the Data folder. It would of course error out if some master was used and could not be located.

---

Additionally, some base game masters can be hardcoded and assumed

[rux616]

This would be a welcome feature indeed! I was just thinking about how I to was going to go about using Mod Organizer 2's VFS via CLI to get a proper data folder constructed, but this would obviate that need very nicely.

It would also be useful to be able to specify the location of this file via CLI as well, maybe with a -m | --MasterFiles <path_to_appropriate_json> parameter or something similar.

[Noggog]

Well, the current "design" for .spriggit files right now is it's a folder inheritance idea. So when converting via the CLI or UI, it looks around for a .spriggit file next door. It then looks farther up the directory structure for a file.

The idea is a repo could have 10 mods, and the dev could put one .spriggit file on the top level repo that set the target spriggit translation package version for all in one nice spot.

I was thinking of adding the master listings to the .spriggit file, where the dev could put known masters and whether they're full/medium/light in there as well. When any mod is being translated, it would find the file and know the package to use, version to use, and look to it for master info it might be missing.

Is that decent enough of a design for your use case? Or is the explicit ability to specify a different config important as well?

[rux616]

If I have to define known master plugins in a <repo_root>/spriggit/.spriggit file, I'd be perfectly fine with that. I'm just hoping to avoid too many "config" type files in the repo root if possible.

The way I currently use Spriggit (repo where I use this pattern) is purely via the CLI, with no .spriggit file at all, via a build task in <repo_root>/.vscode/tasks.json (and accompanying powershell script that does some extra stuff like cache plugin hashes to avoid re-serializing plugins that haven't changed - important when you have like 20 different patch plugins, resulting in 40 total additional plugins!), which would probably mesh fairly well with your proposed method.

[Noggog]

Very cool stuff! If you're looking for some work, we'll definitely need some CI experts to flesh out some of the official spriggit CI templates sometime soon 😉

I'm pretty poor at doing CI/bash/powershell, so I usually have to slog through it, haha