Improve Mod Organizer integration #10

focustense · 2021-06-16T20:39:07Z

Certain quirks of the app are due to using Mod Organizer's mod directory, but not knowing all of the things that Mod Organizer knows, especially the order of mods and whether or not they are enabled. This leads to some false-positive warnings, such as flagging backups or disabled mods as duplicates. It also means some false negatives - for example, it can't report that a mod is not really enabled when selecting a mugshot for that mod, even though there is no matching plugin. It doesn't know if an NPC or resource mod is supposed to have its textures overridden by some other mod; and so on.

Although it is slightly cumbersome to navigate, Mod Organizer's configuration can be entirely traversed using just the root .ini, including the mod directory, selected profile, and so on. We can discover everything about the current mod-list state by pointing to that .ini, and solve a number of these problems.

This is mainly a QoL feature, not essential core functionality.

This isn't being used yet, but eventually we are going to start keeping track of which mods are actually installed, both for Mod Organizer (#10) and Vortex (#9). This supports the Vortex half.

MO2 "deep" support relies on the assumption that the main MO2 INI is in the same directory as the executable - so if EasyNPC is being launched from MO2 then there is no need to explicitly ask for this info, it can be detected via the parent process info. Currently there is nothing special to do for mod-file mapping, since the assumptions were designed around MO2 in the first place. What it does do is detect the Mod Directory by default, using the INIs, so it actually uses the configured directory rather than making naive assumptions, and potentially saves a lot of clicks and confusion on the first run. Detection of startup environment is now also less hacky - specifically doing detection of mod managers rather than slapping together a lot of arbitrary conditionals. Some of the first-time messaging has also been improvement. Text descriptions of documentation have been replaced with hyperlinks, a new paragraph was added for when defaults were detected, and the "I'm Done" button now more clearly indicates if there are still problems to fix, although it will still allow ignoring those problems. Improves, but is not a full implementation of, feature #10.

Includes abstractions and a filesystem-based implementation for indexing (i.e. for very fast lookups) all of the files in a particular location. This is going to be used in a variety of places including the new mugshot implementation, mod-manager support, and indirect dependency-aware builds. Archive indexing will likely use the same interface (`IFileIndex`) but will be a separate implementation because archives are read-only - don't need the watcher or bucketing, except if the latter is used to bucket e.g. by archive name. #10 #26 #27 and probably more.

Supports using a set of BSAs as a bucketed index, and pre-warms the cache as archives are added so that access is always fast. The bucket name is always the *full* archive path - callers must maintain their own map in order to associate archive files with mods. #10 #26 #27

Needed in order to correctly keep an `ArchiveIndex` up to date when its archive paths come from the `FileSystemIndex`, or any other index. #10

This wasn't needed for very simple index-based code, but is very important for when they are used by mod manager interfaces. "Bucket names" are equivalent to mod/component names, and frequently we need to check something about a specific bucket without incurring a whole search. #10

These interfaces will replace the earlier, and much more simplistic, `IModResolver`, to provide a fully-scoped view of mods and components ("files" in Nexus land, "directories" in practice). Notably, this starts to add support for disabled mod detection/handling, facegen-only mods, and a much more sophisticated mod location/targeting system that can potentially recover from mod/component names being changed, and other previously profile-breaking occurrences. Part 1 of this is just the abstraction: interfaces and DTO classes they return providing mod and component metadata. #10 #22 #26 #72

Accepts an existing file index (so e.g. it can be completely destroyed and recreated if the target directory changes) and automatically manages archives and tracks additions/deletions to the file system. Component resolution is handled by a dependency, so that this should be able to work for any mod manager. For Vortex, this comes from the bootstrap file (metadata "DB"), and for MO2, it is read from various INI files. #10 #22 #26 #27

And by "handle", this means "toss". This came up with a mod - Apachii Divine Elegance Store - where the main part of it was for SSE, but there was another mod installed (UUNP bodyslides) for Oldrim, which had the same name. Only logical thing to do here seems to be to index both mods, but pick a winner (the first one) when searching explicitly by mod name. The "dupe" can still be found using any other search method. #10

New classes are intended to be used with an `IndexedModRepository`, using the `ModOrganizerComponentResolver`. This pulls in data from many important sources including the main MO2 config, the mod meta file, and even the download meta file in order to pick up the Nexus mod name. #10

Gives us a modest improvement in worst-case startup time. Best-case scenario is to do the indexing at the same time as load order selection/record analysis is happening, and have it finish before any user-visible wait. This still helps for that scenario because it makes the indexing more likely to finish by that time. #10

Although using `Parallel` here made some sense due to the operation being relatively slow, it was not a good choice because all of the blocking I/O was causing thread pool exhaustion on startup. This led to some slowdowns or even apparent deadlocking especially when debugging. Resolution is now async so that the I/O can be async. This allows much more real work to be done in the same amount of time, and avoids tying up all the threads. #10

Turns out that the `ReadData` method isn't actually thread-safe, and this was causing random mods (different on each start) to fail to parse and lead to spurious "mod not installed" / "plugin not installed" in the profile. #10

focustense added enhancement New feature or request easynpc Issues/requests relating the EasyNPC app labels Jun 16, 2021

focustense added this to the v1.0 milestone Jun 16, 2021

focustense mentioned this issue Jun 30, 2021

Pride of Skyrim not being detected #21

Closed

focustense added a commit that referenced this issue Aug 9, 2021

Add notifications to FileSystemIndex.

c090f8f

Needed in order to correctly keep an `ArchiveIndex` up to date when its archive paths come from the `FileSystemIndex`, or any other index. #10

focustense modified the milestones: v1.0, v0.9-beta2 Aug 20, 2021

focustense closed this as completed in 8a34153 Aug 22, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Improve Mod Organizer integration #10

Improve Mod Organizer integration #10

focustense commented Jun 16, 2021

Improve Mod Organizer integration #10

Improve Mod Organizer integration #10

Comments

focustense commented Jun 16, 2021