[Feature] 通过启动参数 以modlist的形式加载mod

[lycc193]

描述 | Description

在旧版本的forge(1.12~1.20.0(?))和neoforge中 允许使用 --fml.mavenRoots --fml.modLists 这两个参数 进行mod加载，而不是局限于version/mods 这个文件夹下

1.12

1.13~1.16

1.17~1.19

forge 1.20最新版把这个参数删掉了

neoforge还在

与此同时 在fabric中 也允许使用 addMods 将任意路径下的mod文件提交给加载器

fabric

建议在启动器中提供设置maven路径的选项, 在下载mod和整合包时 下载到本地仓库 同时在版本文件夹下生成对应于forge/fabric的modlist文件, 导入整合包时 自动进行manifest.json -> modlist的转换

对于不支持这种形式加载的文件 依旧放入mods文件夹下

比如opt

原因 | Reason

相同版本的mod只需要下载一份，同时在修改/更新整合包下的mod版本时 也更为方便

[burningtnt]

本功能对玩家要求过高，需要理解模组加载器的工作原理。

如果你确实需要使用此功能，可以进入 游戏特定设置 - 高级游戏设置 - 自定义命令 - 游戏参数，添加对应的游戏参数，
或进入 游戏特定设置 - 高级游戏设置 - Java 虚拟机设置 - Java 虚拟机参数，添加对应的 Java 虚拟机参数。

[lycc193]

我是说，有没有可能由启动器去维护maven仓库和modlist文件
如果由用户去维护 在安装整合包时 并不能减少重复文件的下载和空间占用

[burningtnt]

本功能对玩家要求过高，需要理解模组加载器的工作原理。

[lycc193]

功能整体对玩家应该是无感的阿，全程由启动器负责下载安装运行

[burningtnt]

0. 既然启动器把所有模组都下载到统一的地方了，那么模组文件夹里就应当是空的，用户看到空荡荡的模组文件夹会不会引起更大的困扰呢？
1. 下载到统一的地方后，为防止文件名冲突，只能以哈希作为文件名，那就只能通过 HMCL 管理了，是否会被认为是搞垄断呢？
2. 如果有较老的 Fabric 版本等不支持此类参数呢？这会增加游戏调试的困难度
3. 如果放弃用户无感这一项，我不认为用户可以理解全局模组仓库的意义。

[lycc193]

1 下载到maven仓库 以版本文件夹的形式保存 不可能存在文件名冲突的阿 和hash就更没关希了
2 fabric那个启动参数是21年的更新 可以在安装时检测版本 不支持的依旧放到mods文件夹 1.12-的forge也同样处理
3 用户无感指的是 不需要用户手动生成/管理modlist文件 由启动器根据整合包的manifest 抽象出来

[burningtnt]

下载到maven仓库 以版本文件夹的形式保存 不可能存在文件名冲突的阿 和hash就更没关希了

版本文件夹？你不考虑跨版本复用的吗？如果不考虑，那这个功能的意义在于？

用户无感指的是 不需要用户手动生成/管理modlist文件 由启动器根据整合包的manifest 抽象出来

用户看到空荡荡的模组文件夹会不会引起更大的困扰呢？

[lycc193]

1 本地maven仓库是 mavenroot/modid/modversion/mod.jar 这种形式保存的文件阿 保证了同一个版本只会存在一份
2 如果一切都交给启动器负责管理 用户根本不需要进入模组文件夹阿
隔壁我也发了一份，是希望同一个仓库 大家一起使用的

[burningtnt]

本地maven仓库是 mavenroot/modid/modversion/mod.jar 这种形式保存的文件阿 保证了同一个版本只会存在一份

按照现有 modid 的数量，根本无法保证 modid 和 version 两者合起来可以唯一。

如果一切都交给启动器负责管理 用户根本不需要进入模组文件夹阿

你来说服用户用 HMCL 管理模组。

隔壁我也发了一份，是希望同一个仓库 大家一起使用的

我看到了，等着被拒绝吧。

[lycc193]

唯一性是很容易保证的，modid前面加上jar对应的包名就行了 ，很多mod本身 就是通过maven来发布版本的

[burningtnt]

唯一性是很容易保证的，modid前面加上jar对应的包名就行了 ，很多mod本身 就是通过maven来发布版本的

0. modid 本身在当今这个模组爆炸式增长的时代，已经偶发撞车的情况
1. jar 的包名？Java 8 是没有“包”这个概念的，如果你是指类似于 net.burningtnt.mymod 这样的东西，那我得说，一个 jar 中可能有很多这样的路径，你选哪一个？那就只能通过 HMCL 管理了，是否会被认为是搞垄断呢？

唯一解决方案就是，把模组计算个哈希，然后以哈希命名。

[lycc193]

不对阿，我看了一下cf整合包的manifest.json 是有唯一id的阿 那个projectID，还有包里隔壁的那个modlist.html url上的id也是唯一的阿

[lycc193]

这种命令行传递modlist和mods文件夹扫描是同时进行的，可以只把cf上已有的 可以保证唯一性的 放到仓库里阿