Allow a mod to "provide" or "fulfill" another mod to satisfy dependencies

[sparr]

I would like to be able to publish two different mods that each satisfy the same dependency of another mod. For example, many of the big mod packs have their graphics in separate mods, and it would be nice to be able to publish a lower resolution version of those mods that would satisfy the same dependency as the original high resolution version.

This would also allow abandoned mods to be "replaced" by new forks with different names, without all the mods that depend on the abandoned one having to change their dependency list, and fulfilling "sync mods with save" requirements when the abandoned mod is no long compatible with the current game version.

[robot256]

Interesting idea. As an alternative in your case at least, you could set both mods as conditional dependencies and use a script in the data stage to check that one of them is installed. You can throw a custom error message during loading if the correct one is not found.

For the case of "impersonating" dependencies, I can imagine an equal number of scenarios where it would help and hurt. I know a few of the biggest modders would be very unhappy if they started getting bug reports caused by mods that they never intended to be compatible. The only real problem it would solve is cases where Mod A requires Mod B to function, neither Mod A nor Mod B are being maintained, and Mod A has a restrictive license attached that prevents it from being re-released with a new dependency. I've seen a decent amount of unpleasantness traded when people disagree about how to solve incompatibilities, so it would certainly be abused at some point.

[Qon]

The only real problem it would solve is cases where Mod A requires Mod B to function, neither Mod A nor Mod B are being maintained, and Mod A has a restrictive license attached that prevents it from being re-released with a new dependency. I've seen a decent amount of unpleasantness traded when people disagree about how to solve incompatibilities, so it would certainly be abused at some point.

You provide a great use-case but then proceed to say that the feature will be abused. How would it be abused? You didn't provide an abuse-case.

[kirazy]

How would you handle clashes, where both the dependency that's specified, and a mod that's fulfilling the requirement be handled?

[robot256]

The only real problem it would solve is cases where Mod A requires Mod B to function, neither Mod A nor Mod B are being maintained, and Mod A has a restrictive license attached that prevents it from being re-released with a new dependency. I've seen a decent amount of unpleasantness traded when people disagree about how to solve incompatibilities, so it would certainly be abused at some point.

You provide a great use-case but then proceed to say that the feature will be abused. How would it be abused? You didn't provide an abuse-case.

I was thinking that it was the only positive use case and that it would be extremely rare. I didn't consider that now in 1.X land, mods are more likely to continue functioning even if they are abandoned, rather than go obsolete in a year from API changes. But it's still unlikely that Mod B would break while Mod A still works, and this use case is hypothetical unless you have an example.

I thought "getting bug reports caused by mods that they never intended to be compatible" was enough of a con. That's not an issue when Mod A is abandoned, obviously, though still confusing for users.

The second other positive use case I can think of would be to alter a mod's behavior (via a dependency it loads) without their consent. But I can't find a good example of where this would actually be useful. Things like graphics and translations can already be modified *after* the original mod loads.

Hard dependencies are actually pretty rare in the community, especially among mods by different authors. Nearly always, they are used when Mod A has to access files contained in Mod B. In that case, Mod A will hard-code paths into Mod B based on the mod's official name inside Factorio. For the impersonation feature to work, it would have to use the same namespace as the original as well, but I really don't like the idea of having zero way to tell the "real" mod from the "fake" mod.

Resolving conflicts is a real question. Would the game ever auto-download "replacement" dependencies, or only the official one? What if both are installed at the same time? This would only really work if the game becomes a full-featured package manager. And in real package managers, the most useful application of the "provides" feature is when a generic dependency and interface has already been agreed upon, which seems like overkill for Factorio.

But OP's original example does not even provide a valid use case for the proposed feature. Their need is exactly what Space Exploration already does with their graphics packs. The Low-Res pack is mandatory, the Hi-Res pack is optional, and the data scripts detect if HR is present and use it in that case. In fact, OP's solution doesn't work, because a HR graphics do not substitute for LR graphics: You must have either LR, or LR+HR. The game's user settings determine whether HR graphics are enabled.

A few related discussions for the interested:
viewtopic.php?f=6&t=69932
viewtopic.php?f=34&t=85466
viewtopic.php?f=25&t=71589
viewtopic.php?f=28&t=70116

[robot256]

I would like to be able to publish two different mods that each satisfy the same dependency of another mod. For example, many of the big mod packs have their graphics in separate mods, and it would be nice to be able to publish a lower resolution version of those mods that would satisfy the same dependency as the original high resolution version.

This would also allow abandoned mods to be "replaced" by new forks with different names, without all the mods that depend on the abandoned one having to change their dependency list, and fulfilling "sync mods with save" requirements when the abandoned mod is no long compatible with the current game version.

I missed the part where it's someone else's graphics pack you want to replace? That sucks that they lump everything together. The correct solution is for those authors to split their graphics packs into LR and HR when they get large enough, like Space Exploration does. You could indeed do what you say to work around it, if "provides" was a thing. But if the parent mod is expecting HR to be there, you would have to include a bunch of dummy images so that it can still "find" those files.

I don't think "sync mods with save" is a good example either. It would be too hard for the game to figure out what version to download automatically, and the dialog is entirely "suggestion" anyways. Manually, you can check/uncheck any box before confirming and I usually do customize it when migrating from one version/modpack to another.

I am very interested if you have an example of a mod where the unsupported parent still works but has an unsupported child that's broken.

[Xorimuth]

I didn't consider that now in 1.X land, mods are more likely to continue functioning even if they are abandoned, rather than go obsolete in a year from API changes.

On the contrary: 1.1 will have lots of breaking changes.

[sparr]

How would you handle clashes, where both the dependency that's specified, and a mod that's fulfilling the requirement be handled?

I think "provides" would imply "conflicts".

I missed the part where it's someone else's graphics pack you want to replace? That sucks that they lump everything together. The correct solution is for those authors to split their graphics packs into LR and HR when they get large enough, like Space Exploration does. You could indeed do what you say to work around it, if "provides" was a thing. But if the parent mod is expecting HR to be there, you would have to include a bunch of dummy images so that it can still "find" those files.

Not every mod has LR and HR graphics at all. And many mods' LR/only graphics are still much higher res than I need or want.

I don't think "sync mods with save" is a good example either. It would be too hard for the game to figure out what version to download automatically

It wouldn't be hard at all as long as the "provides" list includes version numbers.

I am very interested if you have an example of a mod where the unsupported parent still works but has an unsupported child that's broken.

I don't have it handy but I recently ran across a mod with an optional dependency on a mod by one of the authors who have deprecated/abandoned all of their mods for principle reasons. Generally speaking, almost anything with an optional dependency works fine if that dependency is gone, but has functionality that only works if that mod is present.

[robot256]

How would you handle clashes, where both the dependency that's specified, and a mod that's fulfilling the requirement be handled?

I think "provides" would imply "conflicts".

Makes sense.

I missed the part where it's someone else's graphics pack you want to replace? That sucks that they lump everything together. The correct solution is for those authors to split their graphics packs into LR and HR when they get large enough, like Space Exploration does. You could indeed do what you say to work around it, if "provides" was a thing. But if the parent mod is expecting HR to be there, you would have to include a bunch of dummy images so that it can still "find" those files.

Not every mod has LR and HR graphics at all. And many mods' LR/only graphics are still much higher res than I need or want.

If you make a new graphics mod, it can load after the base mod and simply modify the graphics paths in the data structures added by the base mod. What I don't know is whether the game will ignore/purge assets that are not referenced by any entities. If not then you are probably right, and an alternate dependency would be needed.

Of course, nothing is stopping you from running locally with a modified graphics package that satisfies the dependency. But this might cause more problems, because the base mod has to specify the size of each sprite in its Lua code.
You would need one mod to fake the dependency, then a post-process mod to change the sprite sizes. Actually this could be done in data-final-fixes by your new graphics mod. As long as the modded entities were not copied by any other mods before you changed them...

I don't think "sync mods with save" is a good example either. It would be too hard for the game to figure out what version to download automatically

It wouldn't be hard at all as long as the "provides" list includes version numbers.

"sync with server" has to match mod versions, but "sync with save" ignores version numbers. This actually caused silent failures when a mod had a hard depends on a specific version by "sync with save" picks the wrong one (don't know if they fixed this). Normally it's okay because you want to either use the versions you have downloaded, or download the most recent one. The devs would have to completely address this before "provides" would work.

I am very interested if you have an example of a mod where the unsupported parent still works but has an unsupported child that's broken.

I don't have it handy but I recently ran across a mod with an optional dependency on a mod by one of the authors who have deprecated/abandoned all of their mods for principle reasons. Generally speaking, almost anything with an optional dependency works fine if that dependency is gone, but has functionality that only works if that mod is present.

Yes, I am starting to agree that this might be an issue. I am curious which mods you are talking about there.

[sparr]

If you make a new graphics mod, it can load after the base mod and simply modify the graphics paths in the data structures added by the base mod. What I don't know is whether the game will ignore/purge assets that are not referenced by any entities. If not then you are probably right, and an alternate dependency would be needed.

Even if this works, I would still have to download the unnecessary graphics (adding 10-20 minutes to my mod updates, boo) and store them (1GB+ of files I don't need) and load them (30-60 seconds of extra game load time).

[Qon]

Even if this works, I would still have to download the unnecessary graphics (adding 10-20 minutes to my mod updates, boo) and store them (1GB+ of files I don't need) and load them (30-60 seconds of extra game load time).

The game doesn't load files that are not referenced. If your updates replaces all filename references to HR graphics then the graphics loading stage (after data) should never find those HR files. The game doesn't just simply copy the mod directory into memory. It reads data(-updates|-final-fixes)?.lua in data stage, then reads in the graphics found in prototypes after all mods have been data-loaded and then reads control.lua after load of a safefile.

You could get around storing the HR graphcs by simply deleting them from the mod, though that would have to be after download. Since you replace the filepaths in prototypes in data stage the prototypes will be valid anyways before they are checked. If it worked differently it would be very inefficient and would also not support the features we have today. This is not trivial for any user though, and requires manual work at updates if you want those.

But download is a bit harder to get around. info.json is probably downloaded already by the mod manager automatically, and the mod portal api might support downloading info.json from mods also? If it's purely a graphics package then that's all you need since you are going to delete all the other files anyways. If it's just a single package mod then I don't have a solution. Far from ideal, I know.