[Investigate] Discuss and investigate if we want both Profiles and Loadouts

[Al12rs]

Spike

This is basically an ADR template to discuss loadouts and how to overcome their limitations

Details:

So far we have been considering loadouts, but should we dismiss the idea of profiles?

What is the difference between loadout and profile:

• Loadouts have separate sets of mods, if a change is made to the contents of a mod, it isn't reflected in the other loadouts. It is important to note that if two loadouts have mods that contain the same exact files, the data in those files is not actually duplicated in our FileStore.
• Profiles on the other hand all have the same mods and contents of mods, what changes is the Priority order and the enabled state of the mods. They can be thought of as lightweight versions of loadouts.

Use cases for Profiles and Loadouts:

What problem are they trying to solve?

• Testing a different configuration of mods without breaking their existing setup
• Having different modded setups for different playthroughs of the game
• Having different modded setups for separate multiplayer playthroughs (need to have exact same mods as other players)
• Having a vanilla or close to vanilla setup playing the game without mods (e.g. check if a bug is caused by mods or by the game)
• Having different configurations for playing at high visual fidelity or higher framerates
• Trying a completely different modded setup using Collections or type of bulk sharing of curated modlist (e.g. wabbajack modlists)
• Debugging broken setup by disabling mods
• Creating "snapshots" of current setup, to fallback to before installing a bunch of more mods.

Loadouts:

Advantages:

• Cleaner and more isolated design, no chance of breaking other loadouts by apporting a change to one of them.
• Configuration changes made to one loadout don't interfere with the other loadouts, avoiding breaking them
• Updating a mod doesn't break other loadouts that still need the old version
• Possible to maintain completely separate game versions as separate loadouts, useful if e.g. multiplayer requires latest version, but none of the mods work on the latest version.

Disadvantages:

• Maintaining multiple loadouts up to date becomes more involved and time consuming, as each loadout needs to be updated.
• Common data like SaveGames is not shared between loadouts, this might be ok for some of the use cases, but extremely annoying for others. Need to move over this data.
• Game settings and configuration is not shared either, could also be desired behavior or be really annoying, if you have to update your button mappings on all 10 of your loadouts.
• Game updates would need to be applied to every loadout that the user doesn't intend to keep outdated.
• Adding a mod to one loadout does not add it to the other loadouts.
• Uninstalling a mod from one loadout doesn't uninstall it from all of them. If a user wants to completely remove the mod they have to do it from every loadout.
• Updating a mod in one loadout doesn't update it in all the others. This might be desired or not desired

To sum up, loadouts are great if you want isolation, as soon as you want to share something or update multiple loadouts, they become unwieldy and cumbersome. This could be solved with ui, but it would be a complicated problem to solve.

As a note for game updates, in some communities (e.g. bethesda games) not updating the game can some times be preferrable to updating it, to avoid mods breaking. But this should not be assumed as the preferred or desired behavior for most games, and even then at some point those users will still want to update as newer mods no longer support the old version of the game.

If the game developers release an update, there are usually good things in there such as bug fixes or new game features that the users want to have. Some games simply can't be played on older versions due to online components as well. So in either case users will want to update the majority of their loadouts/profiles to the new game version, and with that also update all the mods to match support for that game version. This is where loadouts are the weakest I feel.

Profiles:

Advantages:

• Data such as game settings and SaveGames are shared by default between profiles
• Updating a mod can be done once for all profiles
• Updating the game can be done once for all profiles
• It is still possible to keep Saves and game settings separate per profile, by using separate mods and enabling different ones in different profiles
• Potentially this could apply to the game version as well, you could have two GameFiles mods, with different versions, and having different ones enabled in different profiles
• In theory it is possible to do everything that loadouts do, simply by duplicating mods
• Adding a mod to multiple profiles is automatic
• Removing a mod from multiple profiles is automatic
• Updating a mod on multiple profiles is automatic

  Disadvantages:

• Less isolation means that it is much easier to break profiles than loadouts, by making changes to a different profile
• Spam of disabled mods that are being used in other profile but not in the current one
• Updating a mod by default updates it on all profiles, otherwise you need to install the new version as a new mod and disable the old one manually on all profiles or have a custom solution like Vortex (which is also quite bad).
• Managing all the different versions for each profile can become tiring.
• Vanilla profiles can still have hundreds of disabled mods in them
• Can only disable a mod from a profile, not remove it without potentially breaking other profiles. (Could be solved by allowing hiding mods)

To sum up, profiles have the advantage over loadouts that allow sharing data, while still allowing isolation through the creation of separate mods and having them disabled/enabled. This though causes other inconveniences such as spam of disabled mods, while still making it simple for users to break their profiles by changing one of them. Some of the problems of Profiles could be alleviated by allowing users to hide mods from specific profiles (disabled mods that are specific to other profiles).

Other mod managers:

• Vortex only supports Profiles. When updating mods, Vortex actually creates a new mod for the new version and disables the old version, allowing multiple profiles to keep different versions of the mod. It also annoyingly asks every single time whether you want to update the mod on all profiles or just the current one, which is the most annoying thing in the world.

• MO2 supports profiles as the primary solution, but allows users to create multiple "instances" for the same game. Each instance has a completely separate set of downloads and mods. Advanced users may have two instances use the same Downloads folder for example, but there aren't many more supported operations between instances. Profiles are much more used than instances for the disk space implications. Instances are generally used to handle completely separate modlists (e.g. wabbajack modlists). Loadouts can be much more disk space efficient than instances due to how we use a single FileStore.

Proposed Approaches:

Loadouts are very restrictive due the the fact that they don't allow sharing anything between them, so keeping them up to date becomes very hard. While they solve a lot of the classical issues that profiles have, they come with their own set of limitations.

There are three options here I feel:

• 1: Implement both Loadouts and Profiles. A loadout can have multiple profiles. Loadouts offer the isolation, profiles offer the sharing. Would mean yet another level and having to explain to the users the difference, which might be hard, but might be a simple design apart from that, no multiple choices (e.g. remove from all loadouts or not) and consistent behavior.
• 2: Add optional sharing functionality between loadouts, this relaxes the idea that loadouts are completely isolated by allowing users to define what is shared between them. This creates the ui problem of showing which mods are shared and potential user confusion and inconsistent behavior between different mods of the same loadout. This could also increase code and behavior complexity.
• 3: Add functionalities and utilities to manually update and keep loadouts in sync, e.g. Install mod in all loadouts, uninstall from all loadouts, update mod on all loadouts, update game on all loadouts. Also needs a way to synch mod contents to multiple loadouts for Savegames, or game settings. These are all extra functionalities that need to be bolted on a model that works the opposite way, and it is a UI problem to present them to the user without swamping them with options and choices every time they take an action. The model would also still be that of isolation, so we are doing a lot of extra work in code to add these functionality instead of just adopting a shared model that would support the desired behavior directly and more efficiently.

Personally I like option 1. as it would offer a consistent behavior that is matched by how the model behaves underneath it and choices of Update on all loadouts etc are done by the user at the moment of using a loadout over a profile or the other way around.

[MattSturgeon]

I wonder if option 1 will add unnecessary confusion for users. Immutable/reproducible loadouts are already a big leap from what most modders are used too...

I feel like option 3 would actually serve to reinforce users understanding of the system.

Option 2 probably isn't inherently confusing, but I think it could add additional user-facing complexity, particularly to the UI. No strong opinions here.

[erri120]

Profiles are a concept borrowed from other mod managers. The term isn't even all that great because every other application treats profiles as completely separate sets of data. You can have multiple profiles in your browser, all with separate extensions, bookmarks, and settings. You can have multiple discord profiles, all with separate usernames, servers, and chats.

The App is fundamentally different from other mod managers, we shouldn't try to replicate features that made sense for other mod managers that don't apply to ours. This issue shouldn't be asking if we want "Profiles and/or Loadouts", this issue should be asking whether we want to share some data between Loadouts and how that's going to work.

[Al12rs]

I used the term Profiles for lack of a better alternative and because people would be familiar with how those work from Vortex and MO2.

I personally don't think sharing things between loadouts is going to be nice for users or for us developers, so my proposal is that of adding another concept on top of loadouts (profiles or whatever we want to call them) that allow having multiple "views" of the same loadout by mostly sharing things in it. The two level system would work best because it has a better mapping in the model of the two different user requirements of isolation and convenience that I detailed above.

[Sewer56]

Here's something that came to mind

Uninstalling a mod from one loadout doesn't uninstall it from all of them. If a user wants to completely remove the mod they have to do it from every loadout.

This would normally be functionality of the Mod Library, however currently the Library exists, UX wise, at the loadout level, so it shouldn't manage stuff from other loadouts.

(Note: Unless we are going with actually moving this to a top level item, I may be a bit out of date here)

---

Anyway I don't have much to say, however I've thought about some of these things a bunch before.

When it comes to the terminology though, I imagine we'd have to be more careful. (Yes I did read the previous comment saying it's a placeholder)

The term Profile is often all encompassing, and sometimes associated with multiple users. There's a real risk induced that the user may also expect the App settings to change when switching a profile.

Some suggestions I can think of though are Classes (a.k.a. Create-A-Class), and Presets.

There exist some earlier App designs from last year that included things like collections on the left sidebar. These could just become the Presets or Classes within a loadout. That's a potential way to handle it.

Then if the Mod Library remains at the Loadout level, you can then assign mods to individual Presets from there. (Note: Do correct me if I'm incorrect on planned position of library)

In any case, the idea of having a Loadout and a Preset/Class may not be unfamiliar to end users. Here's a screenshot of Black Ops II with what I'd argue is pretty similar. Switching with LB and RB switches your loadout, and picking your Preset is effectively picking a Class here.

So what's being proposed here may already exist in the wild.

---

As for the general approach. I think there is some inherent risks in reducing isolation. When we relax those rules, there's a risk we may start straying away from that original goals (be it in behaviour or UX wise).

Our selling point after all is the user can always revert to a functioning state.

[Greg-Nexus]

I don't want to get hung up on naming, but lets not use "Profile" as a term for something that isn't a user's Nexus Mods profile. You're building the Nexus Mods App, users already have a "Profile": https://next.nexusmods.com/profile/Iluviel/about-me. It's not going to be very easy to explain to users "no we don't mean your profile, we mean your other profile that isn't about you it's about your mods".

This all sounds really very complicated. Can't we just implement something simple?

[Pickysaurus]

Seems like you've done a lot of thinking on this, but these fringe cases you mention apply to a very small minority of users. We can, of course, collect more data in Vortex to validate assumptions but the general feeling is most users have one "loadout" and it's only the more advanced players that would ever consider having several.

In my humble opinion, we should just have "Loadouts" to start (if it's even required at all for MVP?). This would be a means of isolating saves/configs/mod files to create different game states. If users want to share saves/profiles/etc across saves maybe we can look at mechanisms for that. Vortex has the ability for users to decide if saves are profile-specific or not and offers a (somewhat janky) ability to import saves from different profiles if required.

[Al12rs]

It might be that people don't use Vortex profiles a lot because their user experience isn't that great. I'm trying to avoid loadouts being a great feature in theory, but never used because they are too impractical in practice.

We want users to use features such as loadouts or profiles, to make their modding experience better, they are not going to use the features though if they are not well thought out and well implemented.

Vortex profiles are actively hidden to the users behind a setting to enable them and they are clunky to use with the annoying dialogs to update in all profiles or remove from all profiles etc. We have the opportunity to avoid those same issues

[Pickysaurus]

I still think there's no room for "Loadouts" AND "Profiles" at the same time as that's far too confusing. We should stick to one and supplement it with any extra options/features for valid use cases.

[Al12rs]

That is what Vortex did and I don't think the end result was great. MO2 has effectively both, with Instances and Profiles, where instances are inferior loadouts, but provide the isolation if wanted.

Profiles are often mentioned as one of the best points about MO2. The main criticism received there comes from users who want more isolation and Instances don't offer a solution that is quite ergonomic or disk space efficient enough

[MattSturgeon]

I'm trying to avoid loadouts being a great feature in theory, but never used because they are too impractical in practice.

I think it is more important to keep things simple, both for users and developers.

There is value in loadouts behaving consistently (entirely separated & immutable). This makes it easier for users to glean what is going on, even without reading documentation. Adding another variant of loadouts that behave differently would undermine this.

That said, I agree it'd be nice to have convenience tools that can do things like sync stuff across loadouts. This is essentially what option 3 is proposing.

These tools should probably be considered on a case-by-case basis though, as pain points are identified.

[Al12rs]

There is value in loadouts behaving consistently (entirely separated & immutable). This makes it easier for users to clean what is going on, even without reading documentation.

This is exactly why I would propose adding a separate concept like profiles, these are separate from loadouts. One loadout would have one or more profiles. There would be a hierarchy. All loadouts would behave consistently, all profiles would behave consistently.

Option 2 would undermine consistency by adding exceptions. Option 3 would mean having a model that doesn't reflect what we actually want and having to build clunky workarounds.

[Greg-Nexus]

Still sounds over-complicated and confusing to me.

Why can't loadouts be simple groups of data (i.e. mods, rules, save games, etc.)? If you change a loadout you only change that, if you want to change another loadout go change it.

That sounds like a simple implementation we can get out the door and in the hands of users, rather than debating the merits of problems we don't even have (because we haven't even shipped anything). Then we can measure usage via analytics and get real feedback from modders on their pain points, which means we can prioritise what to build next (rather than just guessing based on non-qualitative suggestions).

Talking about all this without qualitative data feels a bit like putting the cart before the horse. In other words, I don't think it is useful or possible to know how the system will work or look like in the future. That will develop naturally over time and making a decision now is almost certainly going to be a waste of time. No plan survives contact with the enemy.

[Al12rs]

Talking about all this without qualitative data feels a bit like putting the cart before the horse. In other words, I don't think it is useful or possible to know how the system will work or look like in the future. That will develop naturally over time and making a decision now is almost certainly going to be a waste of time. No plan survives contact with the enemy.

That is like closing our eyes to the past 6 or so years of Vortex, MO2 and even more years of Nexus Mod Manager and not really learning anything from them. We do have those experiences, and we should be able to use them to inform our decisions instead of having to repeat the same mistakes and let users tell us things we should already have learned. We are not starting from scratch here or throwing uninformed guesses.

The reason I think it would be worth to discuss this now is that that some of the options would change our underlying architecture and how we would approach UI/UX problems related to multiple loadouts.

There is an entire plan to create a ModLibrary that is based on the fact that loadouts don't share things so you need a central place from where we can add and remove mods. We are already dealing with limitations from loadouts, that is why it is worth discussing potential solutions or approaches

[halgari]

I agree with @Greg-Nexus here, we need to focus on delviring the base product, then move on to removing the pain points users are experiencing.

I don't agree that we're already limited by loadouts, I say that because we don't properly have loadouts built out yet, and the Mod Library isn't fully designed either, so how it portrays mods and links them to loadouts is still up in the air. Nothing is set in stone here, and we can change designs in the future, but right now I'd like to focus on getting out a product that works 100% of the time, then we can focus on reducing user pain around some of these UX experiences.