Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mod Resolution fails if a JiJ mod provides the ID of a mod present at root level #65

Closed
gliscowo opened this issue Apr 20, 2022 · 3 comments
Assignees

Comments

@gliscowo
Copy link

Essentially as the title says, if a mod JiJ'd in another mod declares the ID of a root-level mod in its provides block, mod resolution fails with the following error:
org.quiltmc.loader.impl.discovery.ModSolvingError: <id> is already provided by ModCandidate{<providing mod>} - something has gone wrong internally!

For a concrete example, Numismatic Overhaul and owo-lib may be used where the error will then be
org.quiltmc.loader.impl.discovery.ModSolvingError: owo is already provided by ModCandidate{owo-sentinel@0.5.4+1.18} - something has gone wrong internally!. owo-sentinel here is JiJ'd in Numismatic Overhaul and is only supposed to be loaded when owo is not present to then offer the user the option to automatically download it.

@AlexIIL AlexIIL self-assigned this Apr 20, 2022
@AlexIIL
Copy link
Contributor

AlexIIL commented Apr 20, 2022

So loader really doesn't handle provides correctly then :p

Thanks for the report, I'll look into it soon.

AlexIIL added a commit that referenced this issue Apr 21, 2022
Previously only optional mods added a rule limiting them to only 0 or 1 mod loaded with a given mod ID,
but that doesn't handle the case of multiple (different) mods providing the same mod ID, or a single
mandatory mod ID being provided by an optional mod. Instead we now add a rule for every mod ID found,
whether provided, mandatory, or optional.
TheGlitch76 added a commit that referenced this issue Apr 22, 2022
AlexIIL added a commit that referenced this issue Apr 24, 2022
My previous commit was close, but didn't take into account that providing a mod technically
counted as a separate mod from OptionalModIdDefinition's persepective. This caused solving
to fail when a mod provided the same mod id multiple times - possibly with multiple different
groups, or the same mod id as itself. The fix is to de-duplicate those providing mods with
the real mods, which ensures that a single mod doesn't count multiple times to the "up to 1"
mod per ID limit.
@AlexIIL
Copy link
Contributor

AlexIIL commented Apr 24, 2022

This should now be fixed in 0.16.0-beta.11.

@gliscowo
Copy link
Author

From my testing it appears the issue has been resolved and sentinel loads properly now, thanks for the quick fix
I'll go ahead and close this
Cheers

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants