Problem: How to determine Game Vanilla state

[Al12rs]

Details

The App currently has no good way to determine the Vanilla state of the game.

This is something we need for:

• Allowing users to revert to vanilla state quickly
• Having a baseline for creating new Loadouts (see #982 )
• Knowing what to restore the game folder to when user stops managing a game (#1161 )

Problem

Currently, we assume the initial state when a game is first managed to be vanilla, which is not actually going to be true all the time. The initial state is saved in the GameFiles mod. While the plan is to prevent users from disabling or deleting this mod, they will still be able to make changes to it presumably.

Problems:

• What if initial state is not actually Vanilla
• If the game updates, how do we update the vanilla state to match
• If the game updates but the user doesn't want the update, how do we keep track of what is the desired vanilla state
• What if they want to have different loadouts with different game versions?
• How to allow users to update/modify the vanilla state in an intuitive way?

How other managers approach this?

Other mod managers don't usually have this problem because they don't directly manage the game files.

• Vortex has a manifest of files that it deploys (manages) and everything that isn't explicitly managed is assumed to be unmanaged and ignored.
• MO2: all files created through the game or tool run through MO2 are put in overwrite mod, and thus managed. Everything that changes the game folder outside MO2 is not managed and ignored.

These approaches allow both game updates and users installing mods manually if they so desire. On the flip side this means that the mod mangers can't rollback game updates that can potentially break user setups. In particular Vortex has the problem that newly created files are simply placed in the game folder and ignored instead of being manged. The MO2 approach of only considering things run through MO2 only works because of the fact it uses a VFS, and thus everything that changes the game folder outside the VFS (e.g. game updates) can be assumed to be an intended change to the vanilla layer. In the app, the game folder contains all the mods even while the App is closed, so changes to the folder can't be assumed to be done to the vanilla version.

Solutions:

[erri120]

Other mod managers don't usually have this problem because they don't directly manage the game files.

Users will still have issues with other mod managers. As you mentioned, Vortex and MO2 just ignore the issue because their design allows it. This places all the responsibility of making sure the game is vanilla and doesn't update onto the user.

Let's break this down by starting with the initial state when the user first manages a game. Currently, we assume that this initial state is the vanilla state. We assume this because there is no feasible way of knowing otherwise. I'm not saying that it's impossible, just not feasible.

The "vanilla state" can be defined as the state of the files on disk after the user has freshly installed the game. To know the vanilla state, we'd have to know how the game was installed, or install the game automatically. Both of these options require the same thing: interacting with the installer. The installer would be one of the digital stores we support, like Steam, GOG, Epic Games Stores, Xbox Game Pass aka Microsoft Store, and others. While we might be able to support one store with enough time invested, we won't be able to support all of them. If we can't support all of them, then we can't make this a "core feature". A core feature would have to work with everything. Something like "launching the game" would be a core feature that has to work with everything.

Something that was tossed around a while back was saving the information about the "vanilla state" of a game in some external database. This has many issues. Firstly, we'd only be able to save and transmit a list of file names, sizes, and their hashes. We'd be able to tell the user, "your installation isn't vanilla" which is just the same as saying "make sure your installation is vanilla" which is what we currently do. Secondly, it's not feasible to know the "vanilla state" and put that in a database. The amount of permutations is too much. You'd have to install every version, with every language, with every combination of DLCs, on every store platform, on every supported operating system, to get all possible "vanilla states".

Assuming that the initial state is the vanilla state is the easiest and most straightforward solution. Every other solution comes with too many other issues that require too much time and resources to solve.

Next, let's talk about what happens when the game updates. Let's assume that the user manages the game with the App, they've installed some mods and applied their loadout. The next day, the game updates and they run the App again. We should be able to detect when the game updated. This would definitely require having a more robust system of identifying game versions, but if we had that, we could prompt the user about the game update and how to proceed. As far as the app is concerned, this would just piggyback off the ingest feature we already have. The user could choose for each individual changed file on how to proceed. We could even work with diffs to figure out the "new vanilla state":

• old vanilla state + loadout + new files = current disk
• undo the loadout on disk (everything except the "old vanilla state"): old vanilla state + new files = current disk - loadout
• merge old vanilla state with new files where the latter takes precedence to get new vanilla state

If the user wants to upgrade the "base" of the loadout, aka the vanilla state, we could replace the game files with this new vanilla state.

Overall, we have more options when it comes to dealing with game updates. However, we should assume that the initial state is the vanilla state.

[Al12rs]

I think assuming the initial state is vanilla is fine if we allow users to update that state in some way, such are removing files from it or adding files to it.

This would help in these scenarios:

• Users managing a game while they had one or more mods installed already. They had forgotten about them or something or didn't read instructions. They can now fix the issue rather than having to reinstall everything.
• Non game files getting mixed in with game updates, e.g. running the game creates some new files while app is closed, then the game is updated, those new files get ingested as part of the game update, while they shouldn't actually be in there.
• Game update detection failed for whatever reason and user wants to update the vanilla state to reflect it
• Initial game state was missing files (e.g. user had never launched the game, so some generated or downloaded content was missing)

[halgari]

From Meeting notes on 4/8/2024:

• Brute forcing this (a known state for every language, store, game, version) is not maintainable, too many permutations
• Crowd sourcing this (allowing users to submit the versions) is also a risk
• Best approach: use the state of the game when the game is managed the first time as the base game state.
  • Store this state in the DiskStateRegistry, possibly allowing for multiple versions and for updating the game state over time
  • Going back to the vanilla state can refer to these hashes to figure out the game state or how to undo the changes of the mod manager.
  • This also requires knowing the game version, and something more stable than the Windows Version

[BellCubeDev]

Before a user adds a new game to manage, you may want a big huge warning modal beforehand explaining that the game must be in its vanilla state.