Modpack Overhauls

[Lunaretic]

Parts of this enhancement are dependent upon TexTools/xivModdingFramework#4 and TexTools/xivModdingFramework#5 being completed first.

The Modpack system should be reworked into four types, that match the four use cases users actually use them for.

1. Backup Modpacks
   • Target Use Case - User or System initiated backup or restores.
   • These should automatically back up all active mods, and in their modpack data should maintain/store the original modpack names/structures the items came from, so that data is not lost on re-import.
   • Filenames should be automatically generated/dated, and the backups placed in a /Modpacks/Backups/ folder. Should have a simple 'Backups Browser' interface that shows the date/time the modpack was made, and maybe a note & # of mods in it.
2. Standard Modpacks
   • Target Use Case - Novice/Mid Level Mod Authors wishing to create mods for an item without having to understand the entire item tree. Should guarantee everything looks the same on an end user's machine as it does on the author's.
   • These modpacks should walk the dependency tree to include all the files necessary to ensure a given item ends up appearing in exactly the same way on the destination system. This should include dummy [UseDefault] entries that ensure the various parts on the client system are reverted back to Default files if they are currently modified during install.
   • Selection at the user level would be as simple as just Selecting the item they want, then a dialog displaying all the other "items" that will be pulled along with it.
   • Possibly include an end user toggle that lets them disable the [Use Default] flag triggers, if they wish to intentionally compose mods together.
3. Basic Modpacks
   • Target Use Case - Simple modifications to lay ontop of the existing item, regardless of its modded or unmodded state, such as Normal Map edits to things.
   • Should present the user with the full list of modified files & injections (either in a tree view or full list view or whatever), and let them piecewise select only the ones they want.
   • Most non-equipment modifications such as Skin and UI modifications would fall in this category.
4. Advanced Modpacks
   • Target Use Case - Advanced modders wishing to create customized installers.
   • Uses the existing Modpack Wizard format, but interface for selecting files gets updated.
   • Allow for a [UseDefault] flag to forcefully disable mods in a slot.
   • Change current file browser to be a smarter tree structure for understanding dependencies.
     • Add a [Add with all child files] button that tree-walks down to include all dependent files.
   • Allow for blank group entries with no files in them.
   • Allow group entries to specify a specific page number they should then direct to, if selected.
     • This would allow for creating proper installer trees.

All modpack installs should end in a standardized screen showing total # and size of files to be installed, with option to expand the view and selectively disable individual files if desired for advanced users.

[Lunaretic]

Actual UI process for Complete Modpacks should look like:

-> Open Item selection dialog -> Select item -> Show "Mod Level" dialog -> Show choice of Meta/Model/Material/Texture with small description of each. -> Upon selecting one, will show the list of shared items that will be affected. -> Show the dialog for selecting the actual sub-item. -> META - Changes the top level metadata for the item. Includes everything.

• No selection, all encompassing. -> MODEL - Changes one (or more) models of the item. Include all the materials/textures used.
• Show check-box list of Models for the item by race. -> MATERIAL - Changes one (or more) materials of the item. Includes all the textures used.
• Show check-box list of Materials for the item, and Races that use them. -> TEXTURE - Only changes the textures. Include nothing else.
• Show check-box list of Textures for the item, and Races that use them. (or materials that use them?) After they select one, add it to a list and return to the initial dialog selection, where they can select more items. -> Selecting the same item again is an overwrite action - mixing various levels of the same item not allowed.

Even if something doesn't have metadata, the option should still be Selectable as an 'include everything' one-button option.

• Only thing that might lack that choice is player skins.

[Lunaretic]

Under the hood ultimately this is just a UI way of getting the user to select the top level file paths of what they want. After that, we climb the file paths recursively downward and include all hit files.

Initial item selection decides dependency root. Next selection pulls all files from that root to select from at the appropriate level (GetModels()/GetMaterials()/GetTextures()), save used paths.

Ezpz lemon squeezy

[Lunaretic]

Standard Modpacks are done (at least in basic form), but the BackupModpacks will take a bit.

[Lunaretic]

In light of DAT size limit removal, and improved modpack size calculations, [UseDefault] features can simply be replaced with including the original files in the Modpack as per normal.