Discrepency when installing a collection in the app vs Vortex

[Pickysaurus]

Bug Report

Summary

I have installed a variant of the most popular Stardew Valley collection into the app with both Vortex and the app, then compared the resulting list of files in the game folder.

In this test, I've excluded the _folder_managed_by_vortex and vortex.deployment.json files as they aren't relevant to the end result.

Observations

• We still rename the StardewValley.exe file (did we agree to stop doing that?) so StardewModdingAPI.exe is absent.
• The folder Mods\East Scarp (1.6)\[CP] East Scarp\NPCs is missing, including all contents. This is concerning as this is a sizable chunk of the mod.
• The file Mods\Portraits for Vendors\[CP] Portraits for Vendors\assets\Credits.xlsx is missing. Are we being too opinionated about file extensions? Removing this file won't break the modding setup, but we also have no reason not to install it.

Steps to reproduce

1. Install this collection via Vortex.
2. Note all files in the game folder (excluding known Vortex meta files). - I used dir /s /b /o:gn > App_Files.txt in cmd
3. Remove the mods in Vortex (or just purge)
4. Install the same collection with the Nexus Mods app.
5. Note of all files in the game folder.
6. Compare the results (I used WinMerge).

Note: I did not hash the files, you can do this for a more detailed comparison.

What is the expected behaviour?

The install of the collection produces the same files in both Vortex and the app.

Other information

nexusmods.app.main.current.log
nexusmods.app.slim.current.log
App_Files.txt
Vortex_Files.txt

[Pickysaurus]

The discrepancy seems to be related to #2194

[LukeNexusMods]

Need to use Vortex logic for "Prefer exact"

• Collections: change "Prefer Exact" mod version selection logic  #2329

Vortex also adds some files that dont appear in the loadout.

East Scarp mod gets missed out and the file is not included.

[LukeNexusMods]

Did we say that this had been resolved? Or did it need more investigation?

[Al12rs]

I can go over the various things to make sure when I have some time this sprint

[Al12rs]

I investigated this, installing the collection both in Vortex and the app and found 3 main differences:

• Installed config files were different:
  Likely caused by the presence of a Config override mod in the collection, and the fact that the app doesn't have any conflict sorting, so the winner is random (depends on install order I think).
  To solve this we need to have file conflicts resolution system and a way to sort collection mods based on the collections rules info.
• East Scarp mod was installed differently in vortex, with the [CP] East Scarp/NPCs folder being copied from the [CP] East Scarp NPCs module:
  This seems to be a Vortex bug, with the check of the folder accepting even partial folder names.
• Last difference is the presence of a Credits.xlsx file in the Portraits for Vendors:
  File is present in the archive, but apparently not deployed by the app. Not sure why yet.

[erri120]

I think Credits.xlsx isn't put into the mod because it's an archive. xlsx are just ZIP files.

[Al12rs]

Why would it be excluded in that case? Does it trigger the nested mod installer?

[erri120]

Why would it be excluded in that case? Does it trigger the nested mod installer?

I'm not sure, the SMAPIModInstaller should put every nested file into output loadout item. This needs a test and a debugging session to better understand.

[Al12rs]

I did debug it and it did in fact add the file to the mod and applying deployed the file as expected. I don't know why it worked while debugging single mod install and not during the collection install

[LukeNexusMods]

Is there further work to do on this or can it be considered complete?

[Al12rs]

I could try looking into the Credits.xlsx file discrepancy more, the rest is either resolved or out of scope (missing file conflict sorting)

[Al12rs]

I think Credits.xlsx isn't put into the mod because it's an archive. xlsx are just ZIP files.

After some debugging this seems to be the case. We call AnalyzeOne() recursively files we detect to be archives.

This means that any file detected to be an archive will be extracted and the archive itself not backed up. This can be problematic for any mod format that contains files that can be recognized as archives from our code.
I'll look into options

[erri120]

This will likely pop up again for BSA/BA2 files. We should make a new issue just for that.

[Al12rs]

• See Files recognized as archives inside mods are extracted and not properly added to the mod #2367 for Credits.xlsx issue

For this ticket the remaining discrepancy is for the Config files, which is caused by the fact that the Collection contains a mod with a bunch of config file overrides, that needs to win conflicts with the other mods.
We don't have a system to do this at the moment. This would require:

• A system for defining and handling file conflict priority in the backend
• A system to import file conflict Rules from a Collection into whatever system the app uses

[halgari]

I think the best way to fix this for now, and perhaps forever, is to have a specific list of archives we descend into. We should do this analysis for .zip, .rar, .7z, etc but not for .xslx files.

[Al12rs]

Created a ticket from the Collection feature list to cover the Config discrepancy part:

• Collections: Apply rules for mod asset conflict priority. (mod level and file level) #2368

@LukeNexusMods closing this issue in favour of

• Files recognized as archives inside mods are extracted and not properly added to the mod #2367
• Collections: Apply rules for mod asset conflict priority. (mod level and file level) #2368