Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Mod conflicts if same mod in many modpacks #4183
I have two modpacks, my own one
Now I've created my world, in settings I'm enabling my own modpack ONLY (double click on it), save, trying to run and I see this error:
In world.mt I see lots of completely wrong load_mod_ entries with entries I have not selected, like mesecons, I don't have mesecons in my modpack.
This is irritating and confusing.
Minetest 0.4.14-5699980-5699980-dirty (Windows)
Afaics modpacks are just a way to put multiple mods in a single directory? Seems fine and dandy to me, but you can select what to install from a mod, then the parts you dont install shouldnt count..?
Note that it should be possible to give mods different global-variable tables. Although they'd still potentially clash in cdata objects.(they'd try operate on the same node names etc) If you need this, probably things are overcomplicated?
I currently have the following in ~/.minetest/mods:
All items not marked as "modpack" above are singular mods, some of which are newer than their Dreambuilder (DB) counterparts. That's deliberate, as they supply new functionality that I wanted to test in an otherwise stock minetest_game environment, and a copy of DB just happens to also be stored in ~/.minetest/mods, for use with a different world than the one I am using for the test.
If I clear all
The engine throws the previously-mentioned override warnings and then proceeds to load some of the mods I asked for from places I explicitly avoided asking for, and breaks the dependency resolver, as it fails to load some mods (inconsistently warning me of dependency failures in the process). Close Minetest and go back into the world configuration, and only
If I delete DB from ~/.minetest/mods, purge world.mt of load_* entries, and enable those mods again, everything works as expected. This is NOT a modpack bug, this is an engine bug, it's frankly being stupid and naive about loading mods.
You're seriously going to argue about the validity of this bug and legitimacy of the years-old modpack feature, and then leave the feature just plain broken for two months? WTF? Ok, fine, I get it. Let's make it simple:
Effectively, this breakage makes the whole ~/.minetest/mods/* -> load_mod_foo business utterly useless except in the simplest setups.
Alternatively, you could add backwards compatibility and not break worlds by adding a flag that indicates the the new mod enable method is used, and then convert old worlds.
So the old world.mt:
Get converted to on load:
What valid characters can keys in world.mt take?
or like this:
Mod name should be kept in the configuration file so that in the case of mod absence for whatever reason, MT would have some hint.
referenced this issue
Nov 29, 2017
referenced this issue
Jan 7, 2018
I am very interested in having this fixed, and I've been taking a first look at the code. One crucial constraint is that mod names must remain unique: you can't activate two mods with the same name no matter whether they are part of separate modpacks. The question is what to do in case of a conflict. Here's how I see things.
VanessaE's suggestion of allowing a whole modpack to be loaded with a single setting is a separate feature that can be implemented after the rewrite, not before, and it has ambiguity issues on its own that need to be thought of (a particular mod can appear more than once in the configuration, one explicitly and one implicitly as part of a modpack, and care must be taken to avoid or resolve conflicts).
Edit: As for backwards compatibility, sofar said:
My proposed solution won't break all existing worlds: it will break only those having multiple mods with the same name, one of them in a modpack. That should be announced as a breaking change in release notes. Perhaps a flag like rubenwardy proposed, and an automatic conversion for those worlds that don't have the flag active, could be performed. An alternative, non-breaking solution would be to have