As a user, I want to apply changes to my loadout

[Greg-Nexus]

User story

As a user

I want to apply changes to my loadout

So that I can launch my game with the loadout applied

Requirements

Implement the GUI for applying loadout changes.

For the purposes of this issue, a simple 'Apply' button on the UI will suffice.

Design

Design issue: #994

DOD

Scenario 1

Given I am using the App to manage a game (e.g. Skyrim)

When I make changes to the mods for the game\ And use the 'Apply' button on the UI

Then those changes are saved

Epic:

• [ ] #994
• [x] Apply loadout first draft implementation #973
• [ ] #995

[Al12rs]

@Greg-Nexus milestone 1 mentions applying mod and running the game. There is currently no way to trigger the apply from the UI. So this issue probably needs adding there. (Running the game is also missing btw).

I would suggest for milestone 1 a simple apply button under the Run button. UI/UX to be improved for future milestones. Automatic apply would both require more effort and be quite inconvenient for developers during everyday app development/testing.

[Greg-Nexus]

@captainsandypants Would you be able to update this issue with a design?

[Al12rs]

Some more context for how the App works following up on meeting, with timing information:

General data

Mod DL archives sizes:

Can be from 1kb to ~3GB. These aren't terribly uncommon for popular games, especially older ones (Textures).

Disk speeds:

• Hard Disk drives: from 80MB/s to 160MB/s read/write.
• SSD: From 500MB/s for SATA ones (usually larger, for storage), to ~2-3GB/s for NVMe ones (more expensive, often Operating System drives and high end PCs).
• RAM Memory speed: from ~15GB/s (old DDR3) to ~50GB/s (new DDR5)

App architecture

This is how a mod gets managed by the app:

• User presses DL with Manager on Site
• Download shows up on the App.
• Download completes (connection limited, disk limited)
• App unpacks the DL archive (Anywhere from 20MB/s to 200MB/s worse cases, CPU limited, Disk limited)
• App repacks all the files in the DL into our custom High Access speed .NX internal archive format (from 20/MB/s to 1+GB/s depending on compression level, Disk limited)
• App has a reference to all the files that where packed into .NX format in a database.
• The mod Installer is run (e.g. FOMOD installer), the user makes choices.
• The installer only tells the App which files should be included in the mod, it doesn't actually touch the disk in any way.
• A mod for the App is simply a collection of file references.
• The mod is added to the Loadout (by creating a new Loadout revision)
• A loadout for the App is simply a collection of Mod references. This is kept in Memory, backed by a database, very lightweight and fast.
• When a mod is added, the App makes a copy of the current loadout (just some object in memory), with the new version having the added mod.
• This new loadout is just a virtual representation in memory of how the game folder should look like. The game disk hasn't been touched yet in any way.
• If a user Enables, Disables, changes order or uninstalls a mod, this just creates new Loadout revisions in memory (backed up to DB).
• When the user tries to run the game, the App needs to actually Apply the Loadout to the Disk.
• Internally we have a LoadoutSynchronizer that is responsible for this operation.
• It tries to match the game folder state to that described in the Loadout. Here we might encounter issues with new files being detected in the game folder, and we must decide what to do with them.
• Assuming no external changes, the Apply operation speed is limited by the amount of new data that needs to be copied over to the game folder, from 1kb to 1GB adding a single mod to 10-60GB when switching large loadouts or purging entire folder. Speed is mainly limited by Disk speed.
• Apply is finished after matching the Disk to desired Loadout revision.

Apply considerations

Since the disk isn't touched until an Apply operation is completed, users could get confused by not seeing the mod files in the game folder after a mod was installed and enabled. UI should make the need for Apply operation evident.

There are two main ways Apply operation could be performed:

• Dedicated Apply button. User decides when to apply. Could be after every change, or only after they are sure they have finished their changes. This allows batching of operations, skips user fiddling around, allows user discretion on when to best use it.
• Automatic After every operation that requires changes on disk. This doesn't mean triggering Apply on Launch, but rather after every mod install, mod enable/disable etc. This could mean lots of extra apply when they are not needed, but could mean lower time to GameReady than manual Apply.

We want to support both ways, through a user setting.

In both cases, during Apply operation the UI should remain unlocked. Users should be able to continue making new changes. This is possible since the changes are applied to new versions of the Loadout in memory, not the Old Loadout that is still Applying.

Apply operations should be cancellable.

Users should be able to queue multiple Apply operations. The maximum queue length is 2, in progress and next. After the second one is queued, subsequent applies simply replace the second queued item since they would overrule it anyways.

While cancelling the first one might seem like a good idea, this isn't likely to actually be useful as rollback of all changes already made to the disk is likely take as much time as it took to apply them. Also cancel of Apply is likely to be more error prone than most operations.

Importance of good Apply design:

The fact that the App requires this long Apply operation could be considered the main weakness of the App when compared to other mod managers.

Vortex Deployment phase just writes some links, which is much faster than copying over files, vortex could honestly be faster than it is doing this. MO2 doesn't have any kind of deployment whatsoever and all operations are pretty instant, there is just a small indexing delay when starting the game, which is only noticeable for larger setups.

This big Apply overhead is the main downside of installing files directly to the game folder instead of using links or Virtual File System solutions. The constant delay and loading could put people off using the App, especially if they come from other managers that don't have this issue. This is why having a good UI solution for this is important.

Operations that require an apply before changes are visible to the game:

• Adding/removing mod to loadout Speed without apply: Adding is slow due to extraction and repackaging. Removal can be instant, or take a bit to delete superfluous files. ApplySpeed: depends on number of mods, size of mods, speed of disk)
• Enable/disable mod Speed without apply: instant ApplySpeed: same as Add/Remove.
• Mod conflict rules/priority changes Speed w/o Apply: instant. ApplySpeed: Depends on how many files where conflicting, since those need to be replaced with version from other mod. Speed of Disk.
• Switching Loadout W/o Apply: time to refresh UI, should be instant or pretty fast (~<500ms). ApplySpeed: potentially very slow depending on number of mod changes from the previous loadout, speed of disk.
• Changing game plugins order and enabled state (we don't have this yet) Pretty instant in both cases.

[Al12rs]

@captainsandypants @Greg-Nexus See above for some details on Apply operations after our meeting yesterday.

[Al12rs]

Possible states for apply button on a loadout are a combination of these:

• [ ] There are changes to apply
• [ ] Setting up loadout (managing the game for the first time)
• [ ] Applying
  • [ ] Another loadout
• [ ] There are outside changes (or just Ingesting?)
  • [ ] Outside changes for another loadout
• [ ] Ingesting

We will also want in the future:

• [ ] Queues
• [ ] Cancel button