HMCL-dev / HMCL

A Minecraft Launcher which is multi-functional, cross-platform and popular
https://hmcl.huangyuhui.net
GNU General Public License v3.0
6.89k stars 676 forks source link

有没有可能给HMCL添加一个管理【预设MOD列表】的功能 #1044

Open Knighthana opened 3 years ago

Knighthana commented 3 years ago

有没有可能给HMCL添加一个管理“预设MOD列表”的功能? 我注意到目前HMCL管理MOD的启用与否是通过对MOD文件夹下的MOD文件名后添加或者去除disabled来实现的 但是当由于实际需要在同一个版本下游玩多套不同的MOD组合方案的时候,需要手动启用或者关闭MOD会非常地麻烦,需要一个一个地选择启用或者关闭

我试着在下面的版本列表处创建新的项目并给他起一个不同的名字来尝试创建新的配置方案,但是我发现这个配置方案似乎仅仅只是在hmcl.json文件中创建了一个新的条目,其中并没有记录MOD配置的信息,也就是说无法通过建立新的版本列表来控制这些MOD进行不同的启用或者关闭方案(如果说错了请指正)

目前唯一想到的方案是安装多个版本,在启用版本隔离之后在版本文件夹下面各自单独安装MOD,但是有些MOD比如optifine之类的是通用的,或者说在这些游玩方案之间部分MOD是通用的,这些MOD完全没有必要为每个version文件夹都安装一遍

我不知道我是否描述清楚了这是一个什么样的功能,我举一个例子,不知道有没有人玩过ARMA3,ARMA3的启动器在【修改模块】界面提供了一个叫做【预设】的功能,这个功能可以创建自己的修改模块启用方案,这样就可以在安装上百个MOD之后仍然能够高效地控制这些MOD 希望能提供一点这样的可能性,尤其是同时游玩好几个版本的情况下,感觉还是迫切地需要一种高效管理MOD的方案

附件是HMCL启动器的MOD管理页面和ARMA3启动器的MOD管理页面,希望这张图片能够帮助表达清楚我的意思

HMCLMOD

Tidy-Bear commented 3 years ago

类似想法 +1 在常规 java 项目开发中,是有 maven/gradle 等工具专门管理 jar 包的。腾出一个空间,按照规则放置所有 jar 包,形成“仓库”。在具体某一个项目中,再以一套规则写一个描述文件,让 maven/gradle 知道这个项目要使用仓库中的哪些 jar 包。 回到 Minecraft。Fabric 没接触过。Forge 在开发阶段就是用 gradle 构建的。但事实上,其底层还存在着极其隐晦的特性(隐晦到压根没有任何文档描述过,让人一度怀疑这个API存在的意义):mod(jar)扫描路径除了常规的 mods 文件夹外,还包括 maven 仓库,前提是在游戏启动参数中指定仓库路径和描述文件(.list文件)路径。 不过这套 API 不是很完善(都没人用),面向普通玩家而言太过简陋,启动器想要实现估计很耗时间,何况还要考虑其它 modloader 的兼容性。 先提一下吧,好歹之前研究过,希望能帮到开发团队 0. 0

wifi-left commented 3 years ago

建议直接使用bat批处理

burningtnt commented 1 year ago

你需要的是版本隔离

Knighthana commented 1 year ago

你需要的是版本隔离

这两个概念有些不一样

Tidy-Bear commented 1 year ago

你需要的是版本隔离

“版本隔离” 是几乎完全的隔离,mod jar 包、mod config 文件、option.txt、资源包、光影包等,这些文件每个版本各自持有一份。玩家想要在另一个版本中使用相同的文件,只能选择手动拷贝,既操作繁琐,又文件冗余,文件修改后还存在版本间的同步问题(每次都要复制光影包,每次都要改按键配置 =。=)

这条 issue 是一个抛砖引玉,看能否在 版本共用 和 版本隔离 这两种极端模式当中设计出一种混合模式,根据玩家需要对各种游戏资源选择性地复用与独立管控。说到底,这件事其中一个核心推动力是 mod loader,得让他们想办法对 mod jar 包及相关衍生文件做好类似“依赖管理”的管理,光让启动器去实现确实吃力

目前而言,愿意折腾的人可以自己写个脚本,比如通过 快捷方式/软连接 实现

burningtnt commented 1 year ago

你需要的是版本隔离

“版本隔离” 是几乎完全的隔离,mod jar 包、mod config 文件、option.txt、资源包、光影包等,这些文件每个版本各自持有一份。玩家想要在另一个版本中使用相同的文件,只能选择手动拷贝,既操作繁琐,又文件冗余,文件修改后还存在版本间的同步问题(每次都要复制光影包,每次都要改按键配置 =。=)

这条 issue 是一个抛砖引玉,看能否在 版本共用 和 版本隔离 这两种极端模式当中设计出一种混合模式,根据玩家需要对各种游戏资源选择性地复用与独立管控。说到底,这件事其中一个核心推动力是 mod loader,得让他们想办法对 mod jar 包及相关衍生文件做好类似“依赖管理”的管理,光让启动器去实现确实吃力

目前而言,愿意折腾的人可以自己写个脚本,比如通过 快捷方式/软连接 实现

不,单独隔离 mod 列表是非常危险的。不同版本的同一 mod 对于 config 文件编码是不同的,这会导致 config 文件丢失。 对于“每次都要复制光影包,每次都要改按键配置”的问题,您可以新建版本后从其他版本中复制 config 文件。 如果您想要“在 版本共用 和 版本隔离 这两种极端模式当中设计出一种混合模式,根据玩家需要对各种游戏资源选择性地复用与独立管控”,那么说明:您不是普通的 Minecraft 用户,而是对游戏资源引用有一定理解的用户,您可以自行编写脚本,见 Issue https://github.com/huanghongxun/HMCL/issues/2144 ,或本人正在开发的仓库: https://github.com/burningtnt/HMCL/tree/pluginsystem

burningtnt commented 1 year ago

很不幸,绝大部分 Mod Loader 都没有考虑资源复用,并不允许通过 Java Args 自定义 config dir,minecraft dir 等