Support Windows Store versions of games

[lojack5]

The Windows Store version of Skyrim Special Edition doesn't play nice right now. It's installed to the Program Files\ModifiableWindowsApps location, which has some special write permissions. The main folder we cannot write to (without some serious permission editing - more than just taking ownership, etc), but subfolders (ie: the Data folder) are perfectly writable.

MSStore apps function very differently than we're used to:

1. The actual data files for the program are stored in a virtual file system, called a PackageVolume, which are stored in single files per volume under WindowsApps\MSIXVC. You can query the registry to see what Package Volumes exist, they're listed in the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Appx\PackageVolumes. Subkeys and nodes there give information about where the volume shows up as a directory in the file system.
2. We can query the InstallLocation for these apps with some Powershell commands:
   • Get-AppxPackage | Where-Object {$_.publisherid -eq "3275kfvn8vcwc" } | Select Name, InstallLocation queries for all apps from Bethesda (3275kfvn8vcwc is their PublisherID).
   • Get-AppxPackage | Where-Object {$_.name -Like "*SkyrimSE*" } |Select Name, InstallLocation queries for all apps with a name containing "SkyrimSE" in it. We can use logical operators to combine this with the above if there are problems with non-Bethesda apps that have the game name in them (maybe mods on the windows store?).
   • In the registry under, well, many locations: HKEY_CLASSES_ROOT\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppModel\PackageRepository\Packages\BethesdaSoftworks.SkyrimSE-PC_1.11.0.0_x64__3275kfvn8vcwc for example.
3. The location that is writable is the ModifiableWindowsApps\{game folder} location. This again points into the virtual file system, so takes up no actual space in the real file system. However, editing/writing files will create actual files there (which override the ones in the virtual filesystem).
4. We can find the Modifiable folder by determining the InstallLocation, then "going up" one directory and looking for a ModifiableWindowsApp directory, then finding the game directory in there. This actually doesn't work in all cases. See the wiki for the updated method.
5. Load order is stll in a plugins.txt, but this edition looks for it in two locations:
   • %LOCALAPPDATA%\Skyrim Special Edition MS\Plugins.txt
   • %LOCALAPPDATA%\Packages\BethesdaSoftworks.SkryimSE-PC_3275kfvn8vcwc\LocalCache\Local\Skyrim Special Edition MS It seem that if the Packages one is not present, then the first is read in for Load Order, but then deleted/moved to the Packages directory. So we need to handle this case.

Wiki Page

Other changes:

• The My Games folder is My Games\Skyrim Special Edition MS
• The Game folder is Skyrim Special Edition (PC) Note: different names, so we can't use GameInfo.fsName for both of these.

There are file permission issues involved: it's very hard to get write access to the top level of ModifiableWindowsApps, as well as WindowsApps (all of it). So we have to use (currently) as bash.ini to move the Skyrim Special Edition Mods folder out of those protected areas. The relavent ini entries are sOblivionMods, sBashModData, and sInstallersData.

OK, action items:

• [x] Write the code that parses the registry to finds the installed
• [x] Write the code that parses the registry to find the games' mutable locations
• [x] Split GameInfo.fsName into two attributes, one for the game folder, one for the my games folder
• [x] Write code to handle two possible plugins.txt location: Read from Packages location first, fallback to the usual location. Always write to the Packages location.
• [x] Deal with Morrowind and Oblivion language variations: each language has a seperate install as a subfolder of the main install.
• [x] Figure out if we can use IFileOperation only for changing modification time Maybe...IFileOperation seems a non-starter. We could instead move the file to a location on the same drive outside of the protected locations, modify the times, then move them back. This would be the most efficient IO wise, but is not atomic. The safer "atomic-like" operation would be to copy the file to a non-protected location, modify it, then move it into the game directory. I'm marking this one as a "put off til later" issue. We don't have a good non-admin way to modify times, and admin mode works.
• [x] The vanilla files need updating, SSE, FO4, Morrowind, and Oblivion ship all the files for all languages now (we should have done that before, poor non-English users :P)
• [x] Implement a method to determine game version that does not rely on reading the EXE for the game (EXE files are non-accessible even for the mutable location). The easiest way will probably be to modify WinStoreFinder to read in all possible information about a windows store app, the version is accessible in the registry.
• [x] Use the above version detection to implement CompareGameVersion in Wizard scripts.
• [x] Use the above version detection to implement version detection in FOMOD scripts.
• [x] Update the Readme with applicable information, and common errors/issues that can pop up when managing a WS game.

[Infernio]

Do we even have registry keys for detecting this version? Edit: There apparently aren't any, but the path might be fixed?

The SKSE team also isn't sure if they'll be able to make SKSE (and the other xSEs, while we're at it) work for this version. Apparently the main EXE is very locked down, so the way that xSE usually injects itself doesn't work.

[Infernio]

%LOCALAPPDATA%\Packages\BethesdaSoftworks.SkyrimSE-PC_3275kfvn8vcwc\LocalCache\Local\Skyrim Special Edition MS\Plugins.txt

Regarding this, can we trust that to stay in the same place? If not, we should have it list the %LOCALAPPDATA%\Packages directory and look for ones starting with BethesdaSoftworks.SkyrimSE-PC.

[Infernio]

Apparently it also has a different My Games subfolder? Shadow said it creates a Skyrim Special Edition MS folder in there. Not sure how we should handle this, probably we need a new game constant and need to make SSE MS an entirely different game in WB?

[Infernio]

Overall, this isn't quite as bad as I expected this to be, but it's still godawful. Thanks MS.

Edit: what about the other Bethesda games that were supposed to be released on game pass? Are those not out yet? see below

[Infernio]

OK, the other games look to be out as well. That would mean adding five new games (Morrowind MS, Oblivion MS, Fallout NV MS, Skyrim SE MS and Fallout 4 MS). Do we want to do that, or do we want to rethink this approach? But I honestly think this is the only way to do it, with how much paths have changed for these versions. Plus we'd need some way to feed the load order path to load_order, which probably has to be a game constant too.

[Utumno]

It all looks like game handling has the focus now - #584 landed just on time :)

Seems we need new games yes, while working on reducing files/overrides. Another alternative that might pay in the long run is adding logic for detecting "flavours" of the game - so logic in GameInfo - detect based on keys and scanning the ModifiableWindowsApps?

[Infernio]

This also makes #572 relevant, since even once we do support this people will still have to edit the INI. But I'm not sure the code is anywhere close to ready to support that issue yet.

[lojack5]

Yeah, everything you discovered looks about right Infernio. I wasn't aware that ALL of the games got released, ugh.

I wonder if there's a non-UWP API to the microsoft store app that would help in detecting these. Otherwise we'll have to fall back to scanning, and then that might be the ONLY way to tell the difference between windows store and non-windows store versions.

[lojack5]

Had another thought, we might be able to detect via running a powershell command if the game is a windows store version, investigating that now.

[lojack5]

Ok, we can detect game installs from MS store:

PS C:\Windows\System32\WindowsPowerShell\v1.0> Get-AppxPackage | Where-Object {$_.name -Like "*Skyrim*"}

Name              : BethesdaSoftworks.SkyrimSE-PC
Publisher         : CN=21E520D9-F467-4438-A16E-79ADDBE4ECB1
Architecture      : X64
ResourceId        :
Version           : 1.11.0.0
PackageFullName   : BethesdaSoftworks.SkyrimSE-PC_1.11.0.0_x64__3275kfvn8vcwc
InstallLocation   : C:\Program Files\WindowsApps\BethesdaSoftworks.SkyrimSE-PC_1.11.0.0_x64__3275kfvn8vcwc
IsFramework       : False
PackageFamilyName : BethesdaSoftworks.SkyrimSE-PC_3275kfvn8vcwc
PublisherId       : 3275kfvn8vcwc
IsResourcePackage : False
IsBundle          : False
IsDevelopmentMode : False
NonRemovable      : False
Dependencies      : {Microsoft.VCLibs.140.00.UWPDesktop_14.0.29231.0_x64__8wekyb3d8bbwe,
                    Microsoft.DirectXRuntime_9.29.952.0_x64__8wekyb3d8bbwe}
IsPartiallyStaged : False
SignatureKind     : Store
Status            : Ok

And a command with shorter output, better for parsing with python:

PS C:\Windows\System32\WindowsPowerShell\v1.0> Get-AppxPackage | Where-Object {$_.name -Like "*Skyrim*"} | Select Name, InstallLocation

Name                          InstallLocation
----                          ---------------
BethesdaSoftworks.SkyrimSE-PC C:\Program Files\WindowsApps\BethesdaSoftworks.SkyrimSE-PC_1.11.0.0_x64__3275kfvn8vcwc

[lojack5]

Note, this has to be done with the base powershell (python subprocess, use "powershell.exe" as the command), not the MS updated powershell, as that doesn't work with Get-AppxPackage, there's a whole issue tracker open about it.

So it looks like 3275kfvn8vcwc is the Publisher ID, so this should be unique across all users thankfully.

[lojack5]

We can detect MS versions by looking for appxmanifest.xml in the root folder of the game install, among other things.

[Utumno]

Good thing is we have a package now for this rather specific windoz stuff - I meant windoz specific

[lojack5]

And here we go, this is probably what we'll want to use in the long run to not call into powershell multiple times: Lists all apps installed by Bethesda

PS C:\Windows\System32\WindowsPowerShell\v1.0> Get-AppxPackage | Where-Object { $_.publisherid -eq "3275kfvn8vcwc" } | Select Name, InstallLocation

Name                          InstallLocation
----                          ---------------
BethesdaSoftworks.SkyrimSE-PC C:\Program Files\WindowsApps\BethesdaSoftworks.SkyrimSE-PC_1.11.0.0_x64__3275kfvn8vcwc

Although I just now realized that gives a location, but not the actual location we want 😢 . We actually want C:\ProgramFiles\ModifiableWindowsApps\Skyrim Special Edition (PC). UGH

EDIT: Things get weirder, the files exist both in the "Install Location" and in the ModifiableWindowsApps location. I'll check if these are hard/soft links.

[lojack5]

OK, this is annoying, we won't have a nice programatic way of finding the actual folders we want to write to for the MS versions, at least as far as I can tell.

MS is using a virtual file system located inside WindowsApps: These files are then linked to by the "Install Location": And by the ModifiableWindowsApps folder, which is where we should be reading/writing mods to: This isn't using the usual hard links, soft links, or even NTFS junctions.

The problem is, from Powershell we can only get the InstallLocation, I haven't been able to find a way to gather the modifiable location. So it looks like we can use Powershell to detect that the game is installed, but the best bet we have to determine the write location is using %PROGRAMFILES%\ModifiableWindowsApps\{game folder}.

[lojack5]

There is a little bit of info in the registry:

This indicates that the package volume 1 is located at C:\Program Files\WindowsApps, which is a parent directory of the InstallLocation for my SSE. It has a sub-node MutablePackagesOnline which indicates that there is also a ModifiableWindowsApps folder associated with it, but again doesn't give the location. M$ why you make this so complicated?

EDIT: So at this point I'm seeing:

1. Detect game installs via powershell
2. Parse the registry for possible WindowsApps volumes, find the one that's a parent of the InstallLocation for the game Scratch that, just look at the parent directory of the InstallLocation, look for a ModifiableWindowsApps folder, and the game directory within that.

I guess the only other option is to tell users they have to specify the install location via command line, or install WB into the ModifiableWindowsApps{game} folder for auto-detection there. In this last case, we'll have to use one of the unique files from the MS store to differentiate between non-MSStore and MSStore versions.

[Infernio]

Can we rely on the drive letter of the InstallLocation matching the drive letter of the ModifiableWindowsApps folder?

If so, I say we modify bush's game detection to call that powershell command, extract the drive letter, then ask each supported game if it has a Windows Store version (maybe abstract here - see @Utumno's remark about 'flavors') and check if [Drive letter]:\Program Files\ModifiableWindowsApps[MS version name specified as a game constant for the we're checking for] exists.

Then for each game that we find such a path for, we add it to _allGames and store the path in a dict similar to _registryGames (or rename _registryGames and use it for both? Probably separate is better, will let us deprint them separately too). Then bush can take the games and paths, do its regular game detection/selection and hand off back to bash.py.

Throw some logic into bash.py/initialization.py to change the [Game] Mods default paths when a Windows Store game has been selected (bass var?) and we should be able to handle everything.

That would leave only the plugins.txt path, not sure if it's hardcoded yet or how to retrieve it otherwise.

On 13. Mar 2021, at 23:38, Lojack @.***> wrote:

 There is a little bit of info in the registry:

This indicates that the package volume 1 is located at C:\Program Files\Windows Apps, which is a parent directory of the InstallLocation for my SSE. It has a sub-node MutablePackagesOnline which indicates that there is also a ModifiableWindowsApps folder associated with it, but again doesn't give the location. M$ why you make this so complicated?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[lojack5]

I think we can rely on that, but no idea for sure. I'd say use the powershell command to get {some path here}\WindowsApps\BethesdaSoftworks.SkyrimSE-PC_1.11.0.0_x64__3275kfvn8vcwc, then extract the {some path here} from that, tack on the ModifiableWindowsApps and then the applicable game folder. So something like install_location.head.head.join('ModifiableWindowsApps', '{game_specific_directory}').

[lojack5]

Ok, did some digging with Process Monitor: SSE-MS looks for a plugins.txt in two locations:

• The usual AppData\Local\Skyrim Special Edition MS\Plugins.txt
• The new AppData\Local\Packages\BethesdaSoftworks.SkyrimSE-PC_3275kfvn8vcwc\LocalCache\Local\Skyrim Special Edition MS

From some initial testing it seems the one in the Packages directory is used always if present. If not present, then the one from the "usual" location is read for initial information, but then moved/deleted/recreated in the Packages directory.

I still need to test if modification times on these affect which one "wins".

[Infernio]

Started working on it in inf-585-windows-store.

Edit: and I'm sure we'll need new games now: you can have both the Steam version and the Windows Store version installed, so we'd otherwise have to decide which to prefer.

[Infernio]

windows.py  661 get_win_store_game_path: _find_win_store_games took 0.421000s

It's cached, but still... ouch. 0.4s penalty to boot, just to call the powershell command.

[Infernio]

I'm speechless:

This is the output I get from the PS command with the MS Store version of Morrowind installed. It truncates the path 🙃

Edit: Adding | Format-Table -AutoSize | Out-String -Width 4096 at the end of the command works - ref https://stackoverflow.com/a/45978593

[Infernio]

@lojack5 Our method doesn't work. I chose to install a game (Morrowind) to my E: drive. It's indeed there:

But the PS command returns:

Name                              InstallLocation
----                              ---------------
BethesdaSoftworks.TESMorrowind-PC C:\Program Files\WindowsApps\BethesdaSoftworks.TESMorrowind-PC_1.0.0.0_x86__3275kfvn8vcwc

Meanwhile the C:\Program Files\ModifiableWindowsApps folder is empty.

[Infernio]

That's not everything either: note the Morrowind GOTY {English,French,German} folders above. Each one is its own entirely separate Morrowind installation, which includes a separate Data Files folder. So we also need a way to determine which language version of the game to use at each given moment.

[lojack5]

Haven't fully woken up, was gonna work on this later today (nice to see you're already started). Try reading from the registry instead, looks like this key might work, dunno if you'll hit the same problem though:

HKEY_CLASSES_ROOT\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppModel\PackageRepository\Packages\BethesdaSoftworks.SkyrimSE-PC_1.11.0.0_x64__3275kfvn8vcwc\Path

Modifying of course for the applicable game.

[Infernio]

Also resolves to C:\Program Files\WindowsApps\BethesdaSoftworks.TESMorrowind-PC_1.0.0.0_x86__3275kfvn8vcwc.

[lojack5]

If that doesn't work, then it really sucks, but I think we can get away with reading

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Appx\PackageVolumes

And enumerating the volumes listed there, that should give all possible "WindowsApps" locations. Will probably destroy startup times, but I'm not sure if there's any other way to get the location except force the users to specify it.

EDIT: Just saw that reply, ew.

[Infernio]

It must somehow be possible to retrieve it if the MS Store can 'Open Mods Folder' just fine.

[Infernio]

I'm searching through my registry now, will edit this comment with everything I find.

• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModel\StateRepository\Cache\Package\Data\9a9\MutableLocation has it.
• One path in the compatibility assistant.
• One path in the 'last typed' paths in Windows Explorer.

So, where does 9a9 come from? Is that stable?

[lojack5]

I'll check back later this afternoon, yeah keep digging. MutableLocation sounds promissing as long as we can figure out where that 9a9 came from. I just looked at that last key I linked, it doesn't give the mutable location, and it's not "next to" the WindowsApps folder on my computer (on my D: drive).

compatibility assistant and last typed won't be reliable unfortunately.

EDIT: Just looked at mine, mine has b7 instead, I think thats just a index (in hex) that gets incremented with each app install. Hopefully there's somewhere else that can connect those to app names. Anyway, off for real for now.

[Infernio]

Pushed my code for now, probably won't be able to do much more today.

[Infernio]

I think I found a map to those package indices. @lojack5 Could you check HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModel\StateRepository\Cache\Package\Index\PackageFullName? It should have a subkey for the game (in my case BethesdaSoftworks.TESMorrowind-PC_1.0.0.0_x86__3275kfvn8vcwc), and that has a subkey with the package index (9a9 in my case).

[Infernio]

I still think there has to be a higher-level API for this. This is absurdly hacky, there's no way MS does this for their store.

Edit: https://docs.microsoft.com/en-us/uwp/api/windows.applicationmodel.package.mutablelocation?view=winrt-19041 !!! Edit 2: It looks like we'd be doing exactly what that API is doing, but that's a UWP API. So we probably can't use it :/

[Infernio]

bush.py   88 _supportedGames: Wrye Bash looked for games in the following places:
bush.py   89 _supportedGames:  1. Windows Registry:
bush.py   91 _supportedGames:   The following installed games were found via the registry:
bush.py   94 _supportedGames:    Enderal: G:\steam\steamapps\common\Enderal
bush.py   94 _supportedGames:    Fallout 3: G:\steam\steamapps\common\Fallout 3 goty
bush.py   94 _supportedGames:    Fallout 4: G:\steam\steamapps\common\Fallout 4
bush.py   94 _supportedGames:    Fallout New Vegas: G:\steam\steamapps\common\Fallout New Vegas
bush.py   94 _supportedGames:    Oblivion: G:\steam\steamapps\common\Oblivion
bush.py   94 _supportedGames:    Skyrim: G:\steam\steamapps\common\Skyrim
bush.py   94 _supportedGames:    Skyrim Special Edition: G:\steam\steamapps\common\Skyrim Special Edition
bush.py  100 _supportedGames:   Make sure to run the launcher of each game you installed through Steam
bush.py  100 _supportedGames:   once, otherwise Wrye Bash will not be able to find it.
bush.py  101 _supportedGames:  2. Windows Store:
bush.py  103 _supportedGames:   The following installed games with modding enabled were found via the Windows Store:
bush.py  106 _supportedGames:    Morrowind: E:\Program Files\ModifiableWindowsApps\Morrowind GOTY (PC)
bush.py  113 _supportedGames:   Make sure to enable mods for each Windows Store game you have
bush.py  113 _supportedGames:   installed, otherwise Wrye Bash will not be able to find it.

Progress 🎉

[Infernio]

Calling it a day for now, code is pushed. Next step is figuring out how to tell which language we should use (see my screenshot in https://github.com/wrye-bash/wrye-bash/issues/585#issuecomment-798893530) so that we can pass the right Data folder back to bash. If that turns out to be too hard/impossible, we can always show a popup/offer a CLI switch too.

[Utumno]

Amazing work @lojack5 @Infernio - from my part I am finalizing the parsers stuff to clean nightly as much as possible

[lojack5]

Nice, that's what I just discovered looking at it too just now. I'll see if I can crack the language problem (doesn't happen on the Skyrim MS Store version), downloading Morrowind now to do testing.

[lojack5]

I found a slight improvement to finding the mutable location, we can get the package full name (which includes architecture and version) using just the common name of the game and publisher ID by enumerating HKEY_CLASSES_ROOT\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppModel\Repository\Families\{common_name}_{publisher_id}. The common name and Publisher ID should be constant, so that will help in case any updates are ever put out, instead of having to enumerate through the package full names. Probably not an issue for any of the current games installed, but when TES6 comes out I'm betting they'll push updates and those PackageFullName's will change with each.

I'm currently writing all this up in a wiki page, then I'll push that improvement.

For the language....I haven't been able to find anything in the registry or root mutable location to help. It seems the Windows Store uses the system default language to choose which version to launch (only applicable to Morrowind, and maybe Oblivion - checking that one now), since they had different binaries and everything per version. Not applicable to Skryim+ since those handle language on an application level so they only ever had one release version.

So at this point I'm thinking hard code a language->directory map, then use the system language to choose which to look for. User's might want to mod different languages though, so we might instead just want to show all three versions.

Speaking of, the number of game installs now is getting out of hand, we probably want to change the boot popup to a combobox with icons, otherwise that will get out of control.

EDIT: wiki page: Microsoft Store Games

[Infernio]

I found a slight improvement to finding the mutable location

Nice, thanks! And yeah, we should really start a wiki page for all this.

we probably want to change the boot popup to a combobox with icons

Agreed. I'll hash up a prototype for this tomorrow. Plus the dynamic sizing of that thing has always annoyed me.

On 14. Mar 2021, at 22:57, Lojack @.***> wrote:

 I found a slight improvement to finding the mutable location, we can get the package full name (which includes architecture and version) using just the common name of the game and publisher ID by enumerating HKEY_CLASSES_ROOT\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppModel\Repository\Families{commonname}{publisher_id}. The common name and Publisher ID should be constant, so that will help in case any updates are ever put out, instead of having to enumerate through the package full names. Probably not an issue for any of the current games installed, but when TES6 comes out I'm betting they'll push updates and those PackageFullName's will change with each.

I'm currently writing all this up in a wiki page, then I'll push that improvement.

For the language....I haven't been able to find anything in the registry or root mutable location to help. It seems the Windows Store uses the system default language to choose which version to launch (only applicable to Morrowind, and maybe Oblivion - checking that one now), since they had different binaries and everything per version. Not applicable to Skryim+ since those handle language on an application level so they only ever had one release version.

So at this point I'm thinking hard code a language->directory map, then use the system language to choose which to look for. User's might want to mod different languages though, so we might instead just want to show all three versions.

Speaking of, the number of game installs now is getting out of hand, we probably want to change the boot popup to a combobox with icons, otherwise that will get out of control.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[Infernio]

One more thing, the wiki page should be titled '[dev] Microsoft Store Games' since it's intended for developers.

On 14. Mar 2021, at 23:01, Nikolas Hanstein @.***> wrote:



I found a slight improvement to finding the mutable location

Nice, thanks! And yeah, we should really start a wiki page for all this.

we probably want to change the boot popup to a combobox with icons

Agreed. I'll hash up a prototype for this tomorrow. Plus the dynamic sizing of that thing has always annoyed me.

On 14. Mar 2021, at 22:57, Lojack @.***> wrote:

 I found a slight improvement to finding the mutable location, we can get the package full name (which includes architecture and version) using just the common name of the game and publisher ID by enumerating HKEY_CLASSES_ROOT\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppModel\Repository\Families{commonname}{publisher_id}. The common name and Publisher ID should be constant, so that will help in case any updates are ever put out, instead of having to enumerate through the package full names. Probably not an issue for any of the current games installed, but when TES6 comes out I'm betting they'll push updates and those PackageFullName's will change with each.

I'm currently writing all this up in a wiki page, then I'll push that improvement.

For the language....I haven't been able to find anything in the registry or root mutable location to help. It seems the Windows Store uses the system default language to choose which version to launch (only applicable to Morrowind, and maybe Oblivion - checking that one now), since they had different binaries and everything per version. Not applicable to Skryim+ since those handle language on an application level so they only ever had one release version.

So at this point I'm thinking hard code a language->directory map, then use the system language to choose which to look for. User's might want to mod different languages though, so we might instead just want to show all three versions.

Speaking of, the number of game installs now is getting out of hand, we probably want to change the boot popup to a combobox with icons, otherwise that will get out of control.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[lojack5]

Got it, Oblivion is still downloading, after I tinker with that I'll get on that code push.

EDIT: Oblivion is the same as Morrowind, 4 language subfolders for English, French, German, and Italian.

[lojack5]

Ok, looks like we got game detection hammered out (minus the issue of dealing with both a steam install and a WS install of a game), and the new game select popup looks really good (minus the button icons).

Next issue I see is we need to rework where the {game} Mods folder and such are stored. The current workaround is to use a bash.ini and change sOblivionMods, sBashModData, and sInstallersData. I really don't like this, since the INI is a per-install of Wrye Bash, but then changing these make us use the same paths no matter which game we're managing. This is not an issue if the user installs WB inside the game folder, but it'd be nice to Just Work(TM) out of the box. So we need those paths configurable on a per-game basis, and we should think about using better defaults for them. Ideally long term, we don't create those directories at all until the first time the Installers Tab is selected, then show a popup asking for where that data should be stored.

Still thinking on the language issue for Morrowind and Oblivion.

[Infernio]

I've renamed inf-585-windows-store to 585-windows-store so that you can push to it as well. Also added the separate GameInfo overrides for WS games, so you should no longer run into the problem of Skyrim VR/Enderal SE/etc. conflicting.

[lojack5]

Sounds good, when I've got time today I'll work more on it.

[Infernio]

Fixed the WS games getting detected via registry as well and went back to the previous quit button icon. Couldn't find a good one for the Launch button among the standards though (most standard icons look terrible on Windows :/), so I just used the WB icon:

Edit: I do still want to add more to the Game Details section, but I'm not entirely sure what to put there yet.

[Infernio]

Also, heads up: I'm gonna force-push the branch once to fix up commit order.

[lojack5]

Ok, was just working on the registry stuff myself (it was detecting my WS and my Steam SkyrimSE as the same location). I'll check it out 👍 EDIT: works good now.

[lojack5]

Potential hickup from Discord: It might be that a purchased install of the game vs a Game Pass sub install of the game use a different AppData location. Investigating, but I'm not about to drop 30$ to purchase another copy of SSE. It may also just have been updated to use that so who knows. If that's the case I don't think it's Bethesda that did it, but rather Microsoft maps file system request from the game to actual locations in the file system.

[lojack5]

Ok, the whole write protected folders is kinda forcing the issue (bash.ini is not a good solution for a "single Bash to manage all games" approach). I'm really failing to decide where a good default location to store mods archives for games is though. Right now my initial thoughts are:

• Change the default location for most metadata we generate to %LOCALAPPDATA%\Wrye Bash\{game_name}\metadata (or similar). This would be:
  • Things that end up in dirs[u'modsBash']: stuff like the mtime, size, crc for plugins, etc. Currently overridden by sBashModData in the ini.
  • Things that end up in dirs[u'bainData']: so all of the installer state info, crc, etc and bsa cached data. Currently overridden by sInstallersData in the ini.
• Change the default location where the actual mod installers are stored. This one I don't know the best option. Maybe default to %LOCALAPPDATA%\Wrye Bash\{game_name}\Installers. Currently overriden by sOblivionMods in the ini. What are other good locations for these?
  • Disadvantages are users will want to easily navigate to this folder, this is much more hidden.
  • Advantages are bypassing the whole file permission issues on windows store, and helping somewhat with the Program Files permission issues.
• Since we're at it, move the Saves data and Load Order and Settings dicts to LocalAppData as well? At least the settings dict.

This is probably (?) a fair balance between just working out of the box, but still having enough options to say, manage two different installs of the steam version of SkyrimSE. We can tell users in that case they need to install bash locally to the game folder, and use a bash.ini to configure their locations.

It'd be nice to swich ALL games over to this, but we'd have to provide backwards compatibility for the old locations (at least for a few versions). Another option is to special case just the Windows Store games to these locations, with plans to migrate other games to these locations in the future. Also long term provide a nice in-app GUI for setting these locations. We could even give a first time popup for the installers location for the first time the Installers Tab is selected to configure it.

I don't want to go too deeply into this, since that's encroaching on #572 and #178 territory.

Thoughts?

[Infernio]

I don't think using AppData is a good idea, because most guides/tutorials suggest people navigate to the Bash Installers folders manually and drop packages in there that way. Plus if you launch WB with admin rights you can't even drop packages onto the Installers tab, because Windows does not allow an admin-elevated application and a non-admin-elevated application to communicate. So I think we have to keep all our settings/packages/etc. in a location that's easy for people to navigate to, and AppData is not that since it's hidden by default and so needs the magic %AppData% to be entered into Explorer.

I was thinking of moving the default locations for only the WS games to something like My Documents\Wrye Bash\{game name}.

Also ref #250.