Third-party mod is enabled rather than using mod in base game

[rubenwardy]

Minetest version

5.7.0-dev-baf99f826c6e35519f68b666c27af6953f295159

baf99f826c6e35519f68b666c27af6953f295159

Summary

Steps to reproduce

• Install Mineclone2, Mesecons, and mcl_level_status_indicator.
• Create a world with Mineclone2
• Enable mcl_level_status_indicator. Mesecons will be partially enabled, despite the dependencies existing in Mineclone2

[rubenwardy]

Can confirm using the example given, but can't confirm using an minimal reproducible example

[Kimapr]

MineClone2 has its own custom version of Mesecons (for redstone), so loading the original on top is going to break things

despite the dependencies existing in Mineclone2

This is false. Most parts of Mesecons depend on default, which is not present in MineClone2.

[rubenwardy]

MineClone2 has its own custom version of Mesecons (for redstone), so loading the original on top is going to break things

That's the bug here, original mesecons shouldn't be automatically enabled

This is false. Most parts of Mesecons depend on default, which is not present in MineClone2.

mcl_level_status_indicator only depends on mesecons_walllever, which is present in MineClone 2

[Kimapr]

Nevermind, i was confused. The bug seems to be that mods in nested modpacks are not visible to the main menu, and so aren't included in its dependency resolution. With this mod structure:

game
└─ <modpack>
   └─ <modpack>
      └─ A

mods
├─ B (depends on A)
└─ <modpack>
   └─ A (depends on default)

enabling B will ignore A in game and enable broken A from user mods instead.