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 conflicts if same mod in many modpacks #4183

Open
Fixer-007 opened this Issue Jun 2, 2016 · 28 comments

Comments

Projects
None yet
10 participants
@Fixer-007
Copy link
Contributor

commented Jun 2, 2016

I have two modpacks, my own one etherial_modpack (yes, it has modpack.txt) and dreambuilder_modpack, they have some similar mods inside of them both, like quartz, bedrock, signs, etc

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:

2016-06-02 21:32:28: WARNING[Main]: Mod name conflict detected: "bedrock"
2016-06-02 21:32:28: WARNING[Main]: Will not load: D:\Newprog\minetest\bin\..\mods\dreambuilder_modpack\bedrock
2016-06-02 21:32:28: WARNING[Main]: Will not load: D:\Newprog\minetest\bin\..\mods\etherial_modpack\bedrock
... etc

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)
Using Irrlicht 1.8.1
Build info: VER=0.4.14-5699980-5699980-dirty BUILD_TYPE=Release RUN_IN_PLACE=1 USE_GETTEXT=1 USE_SOUND=1 USE_CURL=1 USE_FREETYPE=1 USE_LUAJIT=1 STATIC_SHAREDIR="."

@sofar

This comment has been minimized.

Copy link
Member

commented Jun 2, 2016

modpacks are a disaster, they should be removed.

Not a minetest bug. This is clearly a bug in the "modpack" and these two "modpacks" should be subgames instead, or remove bedrock so that it can be a separate mod.

@Fixer-007

This comment has been minimized.

Copy link
Contributor Author

commented Jun 2, 2016

Not a minetest bug.

It is. Minetest can't handle using modpacks if there is/are another disabled one/ones with some similar mods inside.

modpacks are a disaster

Agree, in its current form it is not usable, if you have more than 1 modpack :/

@sofar

This comment has been minimized.

Copy link
Member

commented Jun 2, 2016

You can have multiple modpacks just fine. These modpacks just conflict, still not a bug in minetest, since there is no logical way to resolve this conflict.

@Fixer-007

This comment has been minimized.

Copy link
Contributor Author

commented Jun 2, 2016

LoL, how they conflict if I use only one of them? :/ Thats just plain bad design of minetest modpack system.

@sofar

This comment has been minimized.

Copy link
Member

commented Jun 2, 2016

You've enabled "bedrock" but there's no way to tell whether it's the version from ethereal, or from homedecor.

@sofar

This comment has been minimized.

Copy link
Member

commented Jun 2, 2016

Thats just plain bad design of minetest modpack system.

I completely agree, which is why nobody should use modpacks and the modpack functionality should be removed :)

@o-jasper

This comment has been minimized.

Copy link

commented Jun 2, 2016

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?

@Fixer-007

This comment has been minimized.

Copy link
Contributor Author

commented Jun 2, 2016

modpack functionality should be removed :)

or fixed :}

@sofar

This comment has been minimized.

Copy link
Member

commented Jun 2, 2016

modpack functionality should be removed :)

or fixed :}

Any fix you'd want would break all existing worlds and be backwards incompatible

@stujones11

This comment has been minimized.

Copy link
Contributor

commented Jun 3, 2016

This is clearly a bug, disabled mods should simply be ignored regardless of their name.

@ghost

This comment has been minimized.

Copy link

commented Jun 3, 2016

When there is a mod present both within the subgame, and within the worlddir's worldmods directory, the one in the worldmods directory wins and overrides the one in the subgame, and prints a message to the log.

@Fixer-007

This comment has been minimized.

Copy link
Contributor Author

commented Jun 3, 2016

@everamzah It is not about subgames.

@ghost

This comment has been minimized.

Copy link

commented Jun 3, 2016

As an example of current behavior where overriding mods with identical namespaces takes place.

@stujones11

This comment has been minimized.

Copy link
Contributor

commented Jun 3, 2016

The namespaces would only conflict if both mods were loaded. This issue (as I read it) is that mods that are disabled in the 'configure' menu are conflicting with those that are enabled.

@infmagic2047

This comment has been minimized.

Copy link
Contributor

commented Jun 4, 2016

@stujones11 only names of enabled mods are saved in world.mt, it doesn't have information about which modpack they come from.

@ghost

This comment has been minimized.

Copy link

commented Jun 4, 2016

I take it there's no way to discern which modpack a mod belongs to in world.mt. Does it store load_mod_modname twice?

@stujones11

This comment has been minimized.

Copy link
Contributor

commented Jun 4, 2016

only names of enabled mods are saved in world.mt

So disabled mods should be ignored, I think that would be the expectation of most people.

@infmagic2047

This comment has been minimized.

Copy link
Contributor

commented Jun 4, 2016

@stujones11 I was explaining the cause of the bug.

@stujones11

This comment has been minimized.

Copy link
Contributor

commented Jun 4, 2016

I was explaining the cause of the bug.

I understand that it might not be easy to fix but I am glad we both agree this is a bug. At very least there should be a warning message when mod names conflict.

Edit: I see there already is a warning message.

@VanessaE

This comment has been minimized.

Copy link
Contributor

commented Aug 27, 2016

I currently have the following in ~/.minetest/mods:

digilines
digistuff
dreambuilder_modpack
dumpnodes
mesecons
mesecons_luacontroller
newplayer
recipes
roads [modpack]
vehicle_mash

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 load_* entries from world.mt, fire up Minetest and ask it to enable only the individual mods digilines, digistuff, mesecons, mesecons_luacontroller, roads from the top level of the mod listing, and I click Save, and then go look at the world.mt file, it's spammed with tons of entries (all set to either nil or false) for stuff I never asked for.

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 digistuff looks like it's enabled, I guess since that's the only one of those five that doesn't have a DB counterpart. If I uncheck "Hide mp content" and look at the listing of DB's contents, some of the mods I asked for got pulled from there instead of the top level, and at least one not loaded at all (luacontroller), regardless of its viability.

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:

  • load_mod_foo should always and forever refer to a single mod at the top-most level of the mods directory, and never from a modpack, no matter how badly the engine wants to look in a modpack for it. So some peoples' world configs temporarily break - what else can be done? G*d forbid people have to re-configure their worlds if some mods get temporarily disabled. If that results in a fire somewhere, grab some marshmallows, not a delete key. 😛
  • Something like load_modpack_bar should be added/referenced to enable all of modpack bar.
  • Extending that, load_modpack_bar:mod_foo_ (note the colon) should be added to load component foo explicitly from modpack _bar.

Effectively, this breakage makes the whole ~/.minetest/mods/* -> load_mod_foo business utterly useless except in the simplest setups.

@rubenwardy

This comment has been minimized.

Copy link
Member

commented Aug 27, 2016

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:

load_mod_foobar = true

Get converted to on load:

explicit_mod_paths = true
load_mod_modpack/foobar = true

What valid characters can keys in world.mt take?

@VanessaE

This comment has been minimized.

Copy link
Contributor

commented Aug 27, 2016

I don't know what characters could be used here, but the reason I suggested a colon is because I'm 100% certain that that's one that can't be part of a mod(pack) name. A slash is good, too.

@numberZero

This comment has been minimized.

Copy link
Contributor

commented Feb 20, 2017

or like this:

load_mod_foo = true
load_mod_bar = minetest-wonderful-modpack/my-version-of-bar
load_mod_hooray = ~/documents/my-in-dev-mods/new_carts

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.

@Fixer-007 Fixer-007 referenced this issue May 27, 2017

Closed

[roadmap] Minetest 0.5.0 objectives #2370

10 of 22 tasks complete
@Fixer-007

This comment has been minimized.

Copy link
Contributor Author

commented Oct 10, 2017

Nobody interested? Nobody annoyed with multiple modpack conflicts?

@lhofhansl

This comment has been minimized.

Copy link
Contributor

commented Jan 7, 2018

I just ran into this as well. Very frustrating.

@numberZero

This comment has been minimized.

Copy link
Contributor

commented Jan 7, 2018

@Fixer-007 see also: #3200 #6243.
There is a core problem, not just one tiny bug. The whole mod configuration system is very ad-hoc-ish, but sadly it appears to be not that simple to design something decent.

@ghost

This comment has been minimized.

Copy link

commented 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.

  • The modpack handling code is asking for a rewrite. But it may take quite long until someone is interested enough, or has enough time, as to get that done, so a short term solution is in order. My proposed short term solution is to expand the syntax of the setting minimally, to allow all three of these instead of just the first two:

    load_mod_modname = false
    load_mod_modname = true
    load_mod_modname = modpackname

    If the mod in that modpack is given priority over all others, and mods are searched in the mods root otherwise with no special priority to mods in modpacks as now except for the one named in the setting, that should be enough to honour the selection in the mods management screen accordingly (or in world.mt), which is the most urgent part.

    Even that simple-looking solution is going to be a pain with the current code structure. It won't address VanessaE's concern of lots of entries being added each time a modpack is installed, though. More on this later.

  • A rewrite, in my opinion, should do the following:

    • Every mod would have a path associated, depending on where it's found: game/, world/, or mods/ (here the slash is just an example).

    • The mod management screen should show all those. Modpacks would be in that screen the modpack subpath like now, just one level deeper, e.g. mods/mesecons/mesecons. The user can disable or override any, perhaps except they can't disable the ones in game/.

    • The mod management screen should resolve dependencies in real time. This needs a pop-up mechanism for the following prompts:

      • W depends on X, Y, Z which must be activated too. Is that OK? [Yes] [No]
      • Deactivating W will deactivate X, Y, Z which depend on it. Is that OK? [Yes] [No]
      • Unsatisfied dependency: W depends on X, X depends on Y, Y depends of Z, and Z is not available. [Ok]
    • The configuration can be similar to the "hotfix" proposed one, but with the type (game, world, mods) as a prefix:

      load_mod_modname = type.modpackname

      where type is game, world or mods. For mods in the root directory, that would be

      load_mod_modname = type.

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:

Any fix you'd want would break all existing worlds and be backwards incompatible

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 load_mod_modname = true use the backwards-compatible search method, while load_mod_modname = mods would always give preference to the mods directory (which will be forwards-compatible with the proposed long-term solution) (Edit: Nope because that evaluates to false, not to true).

@ghost ghost referenced this issue Jan 9, 2018

Closed

Allow distinguishing mods by modpack #6898

4 of 4 tasks complete
@ghost

This comment has been minimized.

Copy link

commented Jan 9, 2018

#6898 implements the short-term solution mentioned above.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.