Consider the best way to visualise SMAPI mods with multiple modules

[Pickysaurus]

Spike

Proposal

When a SMAPI mod contains multiple sub-mods. The current logic of the app will split this into x entries in the loadout, which is technically correct but could have the side effect of confusing users as they install 1 mod and it "explodes" into several entries. We should talk to design/product to see if this is the right approach. The other thing to consider is what happens when we come to update these mods as all of the entries need to change.

As I see it there are a few options (this is not an exhaustive list):

1. Continue to show all SMAPI sub-mods as separate entries
2. Show the mod as a single entry according to the archive the user installed
3. Allow sub-mods to be "nested" under a single header (aka show both).

Impact

Core UX for Stardew Valley modders.

Supporting Information

(Include any supporting screenshots etc to support the above)

[Sewer56]

Disk:

Mods
├── FlatOut
│   ├── flatout2.packs.goofyahhmod
│   ├── flatout2.utils.modloader
│   ├── flatout2.utils.mpnamechange
│   ├── flatout2.utils.richpresence
│   └── flatout2.utils.zpatch
├── <other unrelated mod 1>
├── <other unrelated mod 2>
└── <other unrelated mod 3>

UI:

Reloaded-II for reference. Since it's similar to SMAPI in terms of how things are laid out.

I don't show the mods grouped, because the intent with the design of the modding framework was always to have mods show in a flat list. However as people prefer to manually group mods (perhaps they're used to it, due to games like SDV), I show the folder 'prefix' to distinguish groups.

[halgari]

I like the nesting approach. The code already has the concept of "mod groups". This sort of feature may also be useful for FOMODs in the future, where we could install multiple fomod options, but then keep the files from the options in separate sub-mods.

I wonder why most mode managers only display mods at a single level, instead of allowing mods to be nested, much like files are:

flowchart LR

    Loadout --> Mod_1
    Loadout --> ModGroup_2
    Loadout --> Mod_3
    Mod_1 --> File_1
    Mod_1 --> File_2
    ModGroup_2 --> Mod_4
    ModGroup_2 --> Mod_5
    Mod_3 --> File_3
    Mod_3 --> File_4
    Mod_4 --> File_6
    Mod_4 --> File_7
    Mod_5 --> File_8

[Sewer56]

wonder why most mode managers only display mods at a single level

If you were to ask me, I think it's probably a combination of:

• Combining Trees with DataGrid(s) is non-trivial in some UI frameworks.
• Not having an expectation of user juggling 100+ mods.

I find that most non-mainstream games will usually have users run somewhere in the range of 20-50 mods.

[Pickysaurus]

I don't know if we want to think more about the definition of a "Mod" in this case. For quite a few games there can be a lot of "Mods" per downloaded archive. Think of Bethesda mods with lots of plugins or Unreal Engine 4 mods with lots of PAKs

[Continous]

It's also worth noting that mod distribution seems to very much prefer the nesting approach where basically all mods utilize folder structure as a grouping method. IE a mod will have a root folder with all the necessary components, then subfolders with things like options and patches. And this is more and more true as expected user interaction with the actual files increases.

[Pickysaurus]

I'm looking for real-world examples of Stardew Valley mods where displaying all the modules would be a benefit to the user.

I briefly discussed this topic with FlashShifter (author of the biggest SDV mod) on Discord and in his case (and every other case I've seen so far) disabling one "submodule" of his mod would just break it.

[Pickysaurus]

Example use case for disabling parts of a mod when using this mod and translation together:

• https://www.nexusmods.com/stardewvalley/mods/5305
• https://www.nexusmods.com/stardewvalley/mods/9394

The base mod has 3 parts:

• RaisedGardenBeds: a C# SMAPI Mod
• [CP] RaisedGardenBeds: a Content Pack for the Content Patcher that adds English Translations for the C# SMAPI Mod
• [RGB] RaisedGardenBeds: a Content Pack for the C# SMAPI Mod. The C# SMAPI Mod also acts as a Content Pack Framework

The translation has a single part:

• [CP] RaisedGardenBeds - German: German text for the mod.

If you install the translation then you don't need to have [CP] RaisedGardenBeds active since that provides English translations.

This doesn't appear to cause any problems to have the English and German text loaded, so disabling the unused mod is just a "housekeeping" task.