Mod duplication bug

[66BA9Q-ME49]

Is there an existing issue for this?

• [X] I have searched the existing issues

Launcher Version

v0.45.1

Operating System

Windows

Architecture

x64

Current Behavior

Sometimes, I end up with multiple versions of a same mod. The problem seems to come from dependency management. I encountered this issue when installing many mods while transferring everything from another launcher as I prefer installing the mods using XMCL rather than copy/pasting the jar files from the old launcher to XMCL.

Expected Behavior

There should be only one version of a same mod.

Steps To Reproduce

As I'm installing a large number of mods, I can't really notice when and why it goes wrong. There are 2 scenarios: One scenario results in two different enabled versions of the same mod (still trying to reproduce it). The other scenario (which I've been able to reproduce) results in an enabled and a disabled version of the same mod:

• Install a mod with its dependencies.
• Disable that mod and its dependencies.
• Install another mod that shares at least one of the dependencies of the first mod.
• You'll end up with two versions of the shared dependencies (one disabled and one enabled).

Anything else?

Here's an example of the second scenario with Oh The Biomes You'll Go and Biomes O' Plenty:

https://github.com/user-attachments/assets/75cbc5cf-8413-4c1d-acbe-d9ff593d0eb0

[ShadowAndNitrix]

Ok I Can Probly Explain It. So The Difference Between .jar And .jar.disabled Is That The Diabled Jar Files Changes And Does Nothing But The .jar File Is The One That Is Active. Need A More Detailed Explanation?

[66BA9Q-ME49]

Yes, I know. When I disable a mod the .jar file is renamed .jar.disabled. Then, when I re-enable the mod, the .jar.disabled file is renamed back to .jar.

The problem is that XMCL's dependency management system treats disabled mods as uninstalled mods. The correct behavior would be to enable the disabled dependencies when a mod is installed, not installing them again alongside their disabled version.

[66BA9Q-ME49]

One scenario results in two different enabled versions of the same mod (still trying to reproduce it).

I still don't know what to do to reproduce the first scenario. It occurs, but I don't know when or why. All I know is that when I clear the search box and scroll the installed mods list, I see this: Inside the list:

When clicking on the "settings" icon:

And when I try to delete one of the jar files using XMCL, it deletes both. I need to go in the mods folder and delete the unwanted jar manually

Again, I've not been able to reproduce this error, but I'll keep trying. I just create this comment in case someone could guess what happens and how to fix it. I'll inform you as soon as I've been able to reproduce the error.

[66BA9Q-ME49]

I've finally managed to reproduce the error! It seems that XMCL treats the Modrinth and Curseforge version of some mods as different mods. It doesn't occur for all mods, though. For example, XMCL treats the Curseforge and Modrinth version of Oh The Biomes You'll Go (BYG) as a same mod. But for some mods like Just Enough Items (JEI), it doesn't. I think it's because the version names are different:		Modrinth	Curseforge
BYG	Oh_The_Biomes_You'll_Go-forge-1.19.2-[version]	Oh_The_Biomes_You'll_Go-forge-1.19.2-[version]
JEI	[version] for Forge 1.20.1	jei-1.20.1-forge-[version]

Steps:

• Install a mod from Modrinth.
• Install a different version of the same mod from Curseforge.
• Two different versions of the same mod are installed.

Same for dependencies:

• Install from Modrinth a mod which requires a dependency.
• Install from Curseforge a mod which requires a different version of the dependency.
• Two different versions of the same dependency are installed.

Video:

https://github.com/user-attachments/assets/73b7d191-78b2-4474-b80b-aef00d20fa2b

[66BA9Q-ME49]

It seems the first problem is solved. There are 2 issues in this issue, so I'll close this one and open a new one for the second problem.