mcmod
mcmod copied to clipboard
Ahrwing
模组关系优化
Lib 模组原则上不应有拓展，拓展应限定在非 Lib 模组中使用。 由于目前填写前置不会自动添加拓展，所以 Fabric API 应可填入模组关系。 前置应当更加醒目，因为比拓展/联动更重要。
一点碎碎念：如果有一个新的 lib mod 是基于另一个 lib mod 制作的，岂不是可以管这个叫「lib 的扩展」？！
在我看来「拓展」/「联动」/「前置」应该直接合并成同一种关系，名字不知道。
此方案在编辑群中早有提过
hanlie @.***> 于2021年9月19日周日 上午3:13写道：
或许可添加 Fabic API 作前置，但不可再 Fabic API 添加拓展会更好？
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Ahrwing/mcmod/issues/709#issuecomment-922358993, or unsubscribe https://github.com/notifications/unsubscribe-auth/AI56N2FHEBHKTUPPCT4Z7LTUCTQHBANCNFSM5EJFNFAQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
在模组制作层面都不是统一的，据我所知 如果一个 Lib 模组添加了一个物品，那它是题述的“非 Lib 模组”还是 Lib 模组呢。
Urey. Xue @.***> 于2021年9月19日周日 上午3:50写道：
一点碎碎念：如果有一个新的 lib mod 是基于另一个 lib mod 制作的，岂不是可以管这个叫「lib 的扩展」？！
在我看来「拓展」/「联动」/「前置」应该直接合并成同一种关系，名字不知道。
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Ahrwing/mcmod/issues/709#issuecomment-922364267, or unsubscribe https://github.com/notifications/unsubscribe-auth/AI56N2FYRSMNPIQKSPPQ6W3UCTUQBANCNFSM5EJFNFAQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
在模组制作层面都不是统一的，据我所知
是统一的，都是依赖项。只是强制不强制安装的区别。
如果一个 Lib 模组添加了一个物品，那它是题述的“非 Lib 模组”还是 Lib 模组呢。
理论和实践的差别。 理论：Lib 模组不应该添加物品。 实践：是不是 Lib 完全基于开发者主观定义。
百科是要忠于作者的主观定义呢，还是实际情况呢？
@Ahrwing 有两个问题，希望得到解答
一甲、A 模组与 B 模组联动，A 是被动被联动的，其资料页面中是否应注明与 B 联动，如果否的话
一乙、C 模组被 D 模组依赖，C 是被动被依赖的，其资料页面中是否应注明由 D 拓展
二、E 模组加入了与 F 模组相关的配方，此配方涉及的 F 物品之矿词仅这一物品包含，但出于「懒得判断 F 加载了没，所以干脆只在配方里写上矿词并不去判断了」的考虑，在代码层面与 F 并无直接联动关系，但实际效果与联动相同，作者也有联动意愿，是否应判定为联动
（以上内容转自百科 QQ 编讨群的个人发言）
@HanlieChina
为什么要区别对待所谓的「库」和有游戏内容的模组？两者同为拓展者提供了代码
（以上内容转自百科 QQ 编讨群的个人发言）
为什么要区别对待所谓的「库」和有游戏内容的模组？两者同为拓展者提供了代码
因为在日常使用中，不会把 Lib 的拓展称之为“拓展”，拓展多指拓宽原有内容。
不必纠结名称，因为判定是根据定义来的：
如果 A 模组必须同时安装 B 模组才能启动游戏，则 B 模组是 A 模组的 {名称1} 如果 B 模组是 A 模组的 {名称1}，则 B 模组一定是 A 模组的 {名称2}
而目前对于两者名称的描述为： {名称1} = 前置 {名称2} = 拓展
如果 LIB 有“拓展”显得不合理，那换一个就是了。
@WuzgXY-GitHub 或许应该将联动判定改回最初的形式，其中一方为另一方添加了代码，则双方都算作联动关系，编辑时在一边添加后，另一边也自动补全。
@WuzgXY-GitHub 或许应该将联动判定改回最初的形式，其中一方为另一方添加了代码，则双方都算作联动关系，编辑时在一边添加后，另一边也自动补全。
版本对不上，自动补全是不太可能的（
@mamaruo:
因为在日常使用中，不会把 Lib 的拓展称之为“拓展”，拓展多指拓宽原有内容。
感觉日常交流不会这样
mamaruo 2021-09-20 22:16:03 而“拓展”被赋予了“在原有内容上添加内容”的意义，才会出现如此争论
WuzgXY 2021-09-20 22:21:53 没见过这个意义的广泛应用
mamaruo 2021-09-20 22:23:56 你从来不会听人说某 Lib 的拓展，只会说某模组要有个“前置”Lib
WuzgXY 2021-09-20 22:25:17 是的
WuzgXY 2021-09-20 22:25:25 那只是因为讨论库的拓展没有意义
WuzgXY 2021-09-20 22:25:41 不代表「拓展」这个词只能拿来描述内容
由 QQ 的收藏功能生成
版本对不上，自动补全是不太可能的（
确实可能会出现由分组名称格式不一致导致的自动补全创建重复分组或错位的情况
Edit: 我忽略了原有条件组的问题……那段时间恐怕不可能了
所以说以文本作为分类标准，极其难标准化，条件组必须要用勾选，模组下载同理，还有很多其他的例子，如刚解决的链接标记预设
版本对不上，自动补全是不太可能的（
确实可能会出现由分组名称格式不一致导致的自动补全创建重复分组或错位的情况Edit: 我忽略了原有条件组的问题……那段时间恐怕不可能了
所以说以文本作为分类标准，极其难标准化，条件组必须要用勾选，模组下载同理，还有很多其他的例子，如刚解决的链接标记预设
短
另外为什么重生要用引用块说话？
文本标准化确实不可能，但能以高效的方式传达出模组关系信息就够了，总不能整一套 Regular Expression 出来专门描述模组关系（其实未尝不可
不必纠结名称，因为判定是根据定义来的：
如果 A 模组必须同时安装 B 模组才能启动游戏，则 B 模组是 A 模组的 {名称1} 如果 B 模组是 A 模组的 {名称1}，则 B 模组一定是 A 模组的 {名称2}
而目前对于两者名称的描述为： {名称1} = 前置 {名称2} = 拓展
如果 LIB 有“拓展”显得不合理，那换一个就是了。
@WuzgXY-GitHub 或许应该将联动判定改回最初的形式，其中一方为另一方添加了代码，则双方都算作联动关系，编辑时在一边添加后，另一边也自动补全。
自动补齐不太行，至少需要区分是主动/被动。 比如前置自动补齐拓展，这是可以的，因为名称不同。 但联动自动补齐联动，这不太好，因为名称相同。
自动补齐不太行，至少需要区分是主动/被动。
带有主被动的新设定维护起来相当麻烦，还是最初的设定效率高一些。
另外为什么重生要用引用块说话？
不知从哪儿学来的坏习惯.jpg
WuzgXY 2021-09-20 22:25:25 那只是因为讨论库的拓展没有意义
mamaruo 2021-09-20 22:31:31 于是乎“拓展”这个民间用词出现了局限性
WuzgXY 2021-09-20 22:32:31 百科作为规范制定者不能过分脱离民间
WuzgXY 2021-09-20 22:32:38 所以就这样挺好的
mamaruo 2021-09-20 22:33:09 正因脱离才有此提案
WuzgXY 2021-09-20 22:34:06 讨论库的拓展没有意义是因为这不能对模组们作出有效分类
WuzgXY 2021-09-20 22:34:19 不是说「库的拓展」这个概念本身没有意义
WuzgXY 2021-09-20 22:34:30 真要让它有意义起来也很简单
WuzgXY 2021-09-20 22:35:32 MCA 工作室的模组全都是 Abnormals Core 的拓展
@Ahrwing
E 模组加入了与 F 模组相关的配方，此配方涉及的 F 物品之矿词仅这一物品包含，但出于「懒得判断 F 加载了没，所以干脆只在配方里写上矿词并不去判断了」的考虑，在代码层面与 F 并无直接联动关系，但实际效果与联动相同，作者也有联动意愿，是否应判定为联动
另外为什么重生要用引用块说话？
不知从哪儿学来的坏习惯.jpg
我之前也爱用 .jpg 表示一些能用 （ 表示的东西，后来发现这已经完完全全脱离 .jpg 的本意了，于是就不用了.jpg
在我看来「拓展」/「联动」/「前置」应该直接合并成同一种关系，名字不知道。
依赖、被依赖、可选依赖、可选被依赖
可选被依赖 -> 被可选依赖 怎么看都怪
@3TUSK
E 模组加入了与 F 模组相关的配方，此配方涉及的 F 物品之矿词仅这一物品包含，但出于「懒得判断 F 加载了没，所以干脆只在配方里写上矿词并不去判断了」的考虑，在代码层面与 F 并无直接联动关系，但实际效果与联动相同，作者也有联动意愿，是否应判定为联动
如果 E 模组专为 F 模组写了代码就算，通配的不算。
在我看来「拓展」/「联动」/「前置」应该直接合并成同一种关系，名字不知道。
依赖、被依赖、可选依赖、可选被依赖
只填写主动的，即A 是 B 的依赖项（强/弱） 而显示则分主/被动，感觉会更好。
自动补齐不太行，至少需要区分是主动/被动。
带有主被动的新设定维护起来相当麻烦，还是最初的设定效率高一些。
另外为什么重生要用引用块说话？
不知从哪儿学来的坏习惯.jpg
在填写的部分只有 主动强/弱，没有被动。 在显示的时候分主/被动。
显示时检测双向联动并予以合并显示（而不是分别显示成一个主动和一个被动）
hanlie @.***> 于2021年9月21日周二 上午12:03写道：
自动补齐不太行，至少需要区分是主动/被动。
带有主被动的新设定维护起来相当麻烦，还是最初的设定效率高一些。
另外为什么重生要用引用块说话？
不知从哪儿学来的坏习惯.jpg
在填写的部分只有 主动强/弱，没有被动。 在显示的时候分主/被动。
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Ahrwing/mcmod/issues/709#issuecomment-923063601, or unsubscribe https://github.com/notifications/unsubscribe-auth/AI56N2FNOO47TEORNS44MFTUC5LOBANCNFSM5EJFNFAQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
可选被依赖 -> 被可选依赖 怎么看都怪
那是当然的咯，平时谁会讨论「一个模组被哪些模组依赖」？ 我认为编辑者应该只能编辑「A 依赖 B」这样的关系，「B 被 A 依赖」这一层关系应该由系统自动推导出来。
说点有趣的，隔壁 CurseForge 在上传项目时允许你选依赖类型，但这个模型我个人认为毫无参考价值，因为在我的主观印象里除了 Required Library 以外基本都是乱选的：
欢迎来猜一下这些选项都应该是什么意思。我没有标准答案。