Mod confusion with mods using dashes in naming scheme

[SnazzyPanda]

Describe the bug

When adding similarly named mod archives that contain a "-" character as part of the naming scheme, previous mods are overwritten in the mod list. This results in the last mod added being the only mod displayed.

Error message

N/A

To Reproduce

Steps to reproduce the behavior:

1. Get mod archives using this format:
   1. An example of a mod using this format is: https://www.nexusmods.com/cyberpunk2077/mods/10909?tab=description
      • As of writing this, that mod has the main mod as A.G.I.S. - PUBLICNET-10909-1-0-0-1699731371.zip with an optional/addon mod named A.G.I.S. - BLACKWALL-10909-1-0-0-1699731426.zip
   2. Alternatively, for testing you can create empty .zip files named something like:
      • test mod - BASE.zip
      • test mod - Addon 1-2987-1-1-0-1698336549.zip
      • test mod - Addon 2-2987-1-2-0-1698336549.zip
2. Try to add each mod file, either one at a time or all at once.
3. See that only 1 of the mods files uploaded is visible in the mod list

Expected behaviour

I would expect that each of the added mods shows up.

Personally, I would probably prefer that each file that doesn't exactly match a file already added to the mod manager, also be added. This would also allow users to have multiple versions of a mod in the manager, in case they are switching between versions of a mod for some reason (debugging mod issues/compatibility for example).

System Info (please complete the following information):

• Linux Flavour: N/A
• Window Manager: N/A
• Lamp Version: Current commit: a50bc1cc1b4a63ebbe0f705fa2d6607aeb7f18c5, it should also affect 1.0.11 and 1.1.0.

Additional context

It looks like this issue (or at least something similar) was previously discussed in #36. That issue was marked as fixed, but I still encounter it in the interface for Cyberpunk 2077 (as well as the interface for Baldurs Gate 3 when testing with empty mod archives). That discussion mentions that #31 would resolve this issue, but based on the title, it doesn't sound like it would fix the issue I am experiencing.

Locally, I "fixed" this (for Cyberpunk at least) with this patch, but I don't think that lines up with what you are trying to accomplish.

As a quick fix, I think it may still be worth considering doing a strict filename check instead of trying to determine the mod's version from the filename until/unless someone has a better fix to put in place.

[CHollingworth]

For now ill take the approach to disable the check altogether, it was meant to be a way to easily update mod listings but it does cause confusion as stated above

[SnazzyPanda]

That sounds fine to me. Hopefully with the basic drag and drop implementation, that will be a bit less of a concern.

Something that could also be done in the future is prompting the user when you think a mod is an update. In my mind, I think this could be a simple confirmation/choice that notes the existing mod name, the uploaded mod name, and asks if you would like to update the existing mod or add the new mod as a separate entry. The main issue I could see here is finding a nice way to handle multiple conflicting mods added at the same time (I am not sure if there is a nice way to handle queuing these confirmation/choices, but that can likely be discussed at a later time).

I took a quick look at the change you made in 6b5a8f233a00ee5ccfb2f77c4208a4d60d1279eb, and I would note that we may still want some part of the check. With the change you made, it allows you to add the same file/mod multiple times, which might cause some weirdness as you get multiple mod entries (with the same name) pointing to the same file. I am not sure if any other such confusion issues might pop up with how mods are handled internally/at deploy.

How I had it patched locally, if the mod filename matched one we already had I basically skipped over adding it to the mod list, which I think may be an okay way to handle things for now.

[CHollingworth]

In most cases it should overwrite.