Gawdl3y
Allow recognition of installed mods with different filenames than the manifest specifies
Looks like any file that contains dll is located and listed, notably .dll.old and .dll.disabled. These will add additional 'Unrecognized' entries.
When updating, the .dll.old file will also be picked up and show as another entry, even if the hash matches an existing hash of a known mod
These two entries are for the same mod, one of which is ending in '.dll.old' but they have the same hash
Resolute will actually list any file type as unrecognized, not just files containing dll in their filename. This is intended, however, since it's possible (I assume, correct me if I'm wrong) for mods to have non-dll artifacts that get loaded when needed by their assembly.
It would probably be logical to disable triggering discovery while a mod installation/update is in progress... The alternative would be to just keep a list of suffixes to ignore, but that's more error-prone in that it would cause discovery to miss actual unrecognized artifacts put there manually if they have those suffixes. Maybe that's not a big deal, but I'd like it to retain the ability to reliably list everything that shows up in rml_mods and rml_libs so its list can basically be considered authoritative.
Once Resolute has a concept of disabled mods, the behaviour around the .disabled suffix will definitely change, at least. It'll likely just strip that suffix when comparing to known mods/artifacts.
I was mainly noticing it as resolute will make '.old' copies when updating a mod and then it'll end up in the unrecognized category. (atleast while the game is running)
Mods could have additional artifacts of whatever type although it is up to the mod to handle loading other data. For things that are from the manifest, you do have all of their hashes so you could identify old/disabled mods that are otherwise on the manifest. At the moment these show up as unrecognized despite matching hashes.
When comparing know mods/artifacts, just also take into account the hash to see if that matches. It is somewhat common for manually added files to have other things as part of the name such as numbers being added because of same naming Mod (2).dll or for the name to be prefixed to force it's load order to be different like 0Mod.dll
The conceptually conflicting part (in my mind) about detecting files with the incorrect name as a specific mod version just going by hashes is that it's not obeying the manifest. Since the manifest dictates the exact name and placement of files, it seems almost wrong to me to say that a dll file is definitely a specific mod/mod version when only its hash (and not name or location) matches. Is that mod/version truly installed if it's in a different folder than it's supposed to be or has a different name? It removes the predictability.
From a technological side, it definitely would complicate the implementation of installed mod tracking since the manager would have to keep track of a separate list of files and what mod/version/artifact they actually are being matched to (since otherwise it wouldn't be able to update/uninstall them properly). At the moment, Resolute literally just stores a copy of the mod entry from the manifest in its database for installed mods, plus a single additional field marking the installed version. Unrecognized versions are just an ad-hoc version entry for the mod that it creates and places in the mod's version map with the "0.0.0-unknown" semver. Unrecognized mods are the same thing but with an entirely generated mod entry.
A file matching the hash should be plenty confidence in that it is a given mods' file. The actual filename of a given mod could vary especially when first using/starting to manage a previously manual mod setup. If the location differs then it could be a bit tricky but could be shown as some warning for a 'mod appearing to be installed incorrectly' if a mod dll matching a hash was found in say rml_libs but the manifest shows it should be in the mods folder.
Separating away from reliance on filename in terms of keeping track would be to keep track of the fileinfo/file handle (although might not be something persistent and should probably be re-found for each run). The main usage from the filename portion of the manifest is for if/when the name can't be derived from the url. (Mostly for non-github hosted mods) or if the name needed to be adjusted from the actual artifact name. Up to you if you want to enforce that name actively or just use it when that mod gets updated. ie examplemod (2).dll is matching a mod hash on the manifest, then when that mod has an update, the updated version uses the filename from the manifest (or derived from url)