Mod搜索功能，加载器判断优化

[MinecraftYYDS7]

检查项

• [X] 我已在 Issues 页面 和 常见&难检反馈及问题列表 中搜索，确认了这一建议未被提交过。
• [X] 我已查看 功能投票页面，确认了这一建议未在投票列表中。

描述

1.13-的Mod基本基于Forge加载器开发，因此当玩家选择[1.12.2 Forge]加载器时，跳过对Mod的加载器判断（可以解决#4118的一部分内容） 1.13+的Mod，若作者没有设置该版本的加载器，可以检索Mod版本名称，如果Mod版本名加载器名字相关字样时（Forge、Fabric、Both、Quilt），判定该Mod加载器是否与检索的一致。 1.18-，设置加载器为Fabric/Quilt的Mod，直接判定为Fabric。 例： Quark-r1.6-178.jar （1.12.2版本，判定Forge） Mouse Tweaks 2.10.1 (1.12.2版本，判定Forge)

原因

4118 Issue

[allMagicNB]

你应该要去找 Mod 作者，而不是让启动器作者为他们擦屁股。

[MinecraftYYDS7]

我什么时候说一定要龙猫优化了 反馈一下不行呗

[SALTWOOD]

不支持，硬修可能导致误判，况且人家的事你不找人家来找启动器？ 大概率忽略/拒绝

[Pigeon0v0]

那就算做了，按照你这个说法，如果文件名带 NeoForge，上传打了 Fabric 标签，实际上是啥你也不能确定吧，他完全可以里面是个 Forge Mod（

Fabric 和 Quilt 是不能完全等同的，基于后者开发的 Mod 大概率不能在前者用

会先贴等待确认，主要是留个档

[wuliaodexiaoluo]

判定该Mod加载器是否与检索的一致。 1.18-，设置加载器为Fabric/Quilt的Mod，直接判定为Fabric。

Fabric 和 Quilt 是两个不同的加载器，虽然后者的底层是 Fabric，但是不等于就一定能加载 Fabric Mod（实际上可能加载不了一点）

1.13-的Mod基本基于Forge加载器开发，因此当玩家选择[1.12.2 Forge]加载器时，跳过对Mod的加载器判断（可以解决#4118的一部分内容）

我记得，好像 1.13-的加载器不只 Forge，还有 Liteloader 吧

1.13+的Mod，若作者没有设置该版本的加载器，可以检索Mod版本名称，如果Mod版本名加载器名字相关字样时（Forge、Fabric、Both、Quilt），判定该Mod加载器是否与检索的一致

我可以 build 一个带 NeoForge 字样的 Quilt Mod，然后再打上 Fabric 的标签

有些作者可能写的 Mod Forge、Fabric 都兼容，所以这个 Mod 文件名同时包含了 Fabric 和 Forge，然后逻辑错一下变成了可视化安装 Mod 列表失败：指定的 Visual 已经是另一个 Visual 的子级或者已经是 CompositionTarget 的根

这个想法未必都是坏处，但是文件名不可信，如果真这么搞，到时候社区要处理的就不再是无法检测依赖等等等等基础问题，这会变成 PCL 识别为 Fabric 的 Mod 无法在 Fabric 版本运行，到时候就需要日志去找什么东西报错了，各种分析讨论，最后发现是因为有个 Forge Mod 包含了 Fabric 字样导致 PCL 误识别为 Fabric Mod 导致用户下到了这个错误的 Mod，这比 处理 Mod 没有前置、无法筛选 更能浪费社区资源和精力

[SALTWOOD]

总之就是，模组作者的锅龙猫不背。 龙猫以前也处理过相似的 issue（找不到了，反正是拒绝/放弃来着），建议关了

[LTCatt]

可以考虑在 1.12- 禁用 mod 筛选选项？

[SALTWOOD]

可以考虑在 1.12- 禁用 mod 筛选选项？

不是有 LiteLoader 吗？还有 Legacy Fabric 什么的也会有标 Fabric 的 我觉得能尽量不改就不改，毕竟.png

经常出现奇葩命名，还有令人高血压的高耦合啊，没做单例啊，瞎勾八乱糊啊之类的问题……

[LTCatt]

是把那个筛选下拉框隐藏了（

[LTCatt]

umm 最后做了一项调整： 如果同时设置了版本 1.13-、Mod 加载器为 Forge 这两个筛选项，就视作没有设置 Mod 加载器的筛选。