Allow mods to declare "sub-mods".

[MainMemory]

Because the mod manager now stops scanning for mods as soon as a mod.ini file is found, this would allow people to nest a mod folder within a mod folder, and optionally allow them to specify that the sub-mod is dependent on the parent mod as well, which would forcibly enable the parent mod when the sub-mod is enabled (or maybe disable the sub-mod when the parent mod isn't enabled), useful for optional patches on a larger mod. Sub-mods should be loaded recursively.

The INI stuff would be something like this:
[SubMod1]
Path=CoolPatch
Dependency=false
[SubMod2]
Path=OptionalStuff
Dependency=true

[DankRank]

I think "Dependency" should be defined in child mod's mod.ini, since it's related to child mod, and not to the parent mod.

Also, maybe child mods should be able to depend on each other. Example:

• smodub3 depends on submod1 and submod2
• Additionally, submod1 depends on parentmod.
• Enabling submod3 would prompt user to enable submod1, submod2 and parentmod.

Extending from this, we should make any mods able to depend on any other mods. Here's example of what it could look like for submod3 in the above example:

[Dependencies]
0=parentmod/submod1
1=parentmod/submod2

We also could make ModManager have a TreeView for viewing submods:

parentmod
├─submod1
├─submod2
└─submod3

I'm not sure about how we would do the mod ordering, and listview columns (version/author), though.

[MainMemory]

What about circular dependencies?

[DankRank]

@MainMemory When recursively resolving dependencies, keep a list of mods that have been already processed, and then just check if a mod is a duplicate dependency.

Here's pseudocode for the recursive function: (should be called with an empty list)

void recursive(Mod thismod, List list){
        list.add(thismod);
        foreach(mod in thismod.dependencies){
                if(!list.contains(mod)){
                        recursive(mod,list);
                }
        }
}

This not only fixes circular dependencies, but it also fixes duplicates.

[MainMemory]

I feel like using a TreeView to display sub-mods only makes sense if the sub-mods have a required dependency on the parent mod. The standard behavior for a tree view with checkboxes is for the parent item's checkbox to reflect the state of all the child items' checkboxes: unchecked means all sub-items are unchecked, checked means all sub-items are checked, filled means some sub-items are checked.

[DankRank]

I guess we should stay with ListView then, because sub-mod depending only on it's parent is a very specific case. TreeView doesn't work well when your tree nodes have more that one parent.

One thing I thought about is enforcing the mod order, by placing "dependee" mods above "depender" mods, but that isn't possible in case of circular dependencies, so this isn't the way to go.

I might start working on implementing this.

[MainMemory]

You know, all this talk of dependencies is a completely different feature than what I actually created the issue for, which is to simply allow the mod manager to find mods in subfolders of other mods without having it search all the subfolders.

[DankRank]

Yeah, sorry. I'll implement that too.

[DankRank]

Gonna make a PR after I add dependencies.

[DankRank]

I am going to add 3 types of dependencies:

• Required - ModLoader refuses to load without those
• Recommended - ModManager prompts to auto-enable those (along with Required)
• Optional - Shown somewhere in some dialog

Working on ModLoader right now.

[SurDno]

A better implementation would be giving an abillity to any mod to declare master mod rather than giving an abillity for mods to declare sub mods.

This would make it possible for people that are not original mod developers to make their addons dependant on main mod.

[MainMemory]

And how would that be implemented? How do you uniquely identify a mod?

[SurDno]

Folder name?

[MainMemory]

While it is true that two mods can't share the same folder, people can easily rename a mod's folder, and using the 1-click support for GameBanana will likely result in a different folder name than if you download a mod manually.

The only thing I can think of is assigning a GUID or such to each mod, but the problem with that is it has to be done manually for every mod before the feature can be used.

[SurDno]

Does SADX FE somehow check if Dreamcast Conversion is enabled (or vice verse, I can’t remember correctly)?

[MainMemory]

I don't know, but in general, when one mod checks for another mod being enabled, it's done by querying the Windows GetModuleHandle function to see if the mod's DLL file is loaded. It's not infallible, but it generally works well enough. Although it's probable, you can't really guarantee that a mod you're dependent on will have a DLL, and even if it does, the DLL's name can be changed.

[SurDno]

Changed by user or mod author? If it's changed by mod author, then all references to it might be changed too, and if you're talking about changing DLL name by user — why would anyone do that?

If you can't always check DLL, what about using mod name in mod.ini? Still better than nothing.

Because as of now there are lots of addons that need mods by other people to work, such as AutoDemo Conversion dependent on Dreamcast Conversion, AutoDemo Lighting dependent on Lantern Engine, different console prompts by CheatFreak dependent on HD GUI, SephusJo Classic Skins dependent on Dreamcast Characters, DC Fixes dependent on Dreamcast Conversion, etc.