Open Speiger opened 9 months ago
marchermans
commented
9 months ago Hello, thanks for the request.
However we are having an issue understanding what exactly you are requested? What modules are you talking about? We normally talk about module layers, of which none exists that is named system...
Could you provide an example setup? Even if it does not compile/work? So that we can better figure out what you are requesting, and how to support it?
Speiger
commented
9 months ago @marchermans Lets take buildcraft as a example.
They have a "Fat Jar" and "module jars", module jars being "energy/builders/robots" each being a separate jar. If you try install a module jar next to a fat jar the game crashes without any actual ingame report what went wrong.
https://legacy.curseforge.com/minecraft/mc-mods/buildcraft https://legacy.curseforge.com/minecraft/mc-mods/buildcraft-transport
Nowdays if you startup forge with duplicate mods or mods that have issues it will finish loading and then show you a screen: Ok this went wrong please fix it. If a fat/multimod jar has a duplicate with a single mod jar the game just crashes, yes the game crash log shows what went wrong but we know how good users are at reading those, otherwise the "what went wrong screen" wouldn't be necessary.
Edit: To clearify this a bit more. I am asking to improve the handling of issues with interactions between multimod jars and single mod jars. Best solution is IMO, if a multimod jar mod has a single jar duplicate to either load the newer one, or if you can't "not load" the mod inside a multimod jar due to other issues simply not load single jar mod instead, or make a errored load that says: "What you are trying is not supported"
Basically the the mods.toml is really strict, where you have to either autogenerate it in the release builder if you have multiple mods in 1 workspace, or have multiple mods.toml files that you have to then maintain separately.
The request is to make the mods.toml less strict in the sense if a mod in said mods.toml wasn't found in the jar it will be ignored. That way no "autogeneration script" or "multifile" solution is required. Or provide a better approach.
Example is here what we have to do atm. https://github.com/TinyModularThings/UniqueEnchantments/tree/1.19/src/main/resources/META-INF (Files) https://github.com/TinyModularThings/UniqueEnchantments/blob/1.19/build.gradle#L127 (Custom build task that filters out the "mods.toml" and replaces it with the specific required "mods toml")
Edit: I hope this explains it better.
Speiger
commented
8 months ago @marchermans reminder that the info was provided.
cech12
commented
5 months ago @Speiger @marchermans
I have an example mod, where I add an additional test mod in my development environment. In 1.20.2 it works, but in 1.20.4 I have issues to get the same structure running. https://github.com/cech12/BucketLib
Maybe it helps to find & fix the issue. :)
Some mods have multiple mods in them as a module type of system. And to export a Mod you have to provide a mods.toml per mod that exists inside of them.
Yes i know you can merge mods into a single module but the opposite isn't possible.
Take scavenge for example, if I have a single development space for it and it's addons I have to have:
It would nice if there was a better system regarding multi module mods where you could define mods as "Optional" and if the mod wasn't found inside of the class it would be simply discarded.
Also another issue is: If a FAT mod was installed and you install a slim mod that just contains a single module forge/neoforge will simply crash. It would be nice if a "simply do not load said mod/a proper user info" was thrown out.
To be honest, i don't see these issues as "unusable" but it would be nice if that would be addressed at some point, or at least a stance on it would be issued at some point.