[其他]：关于 Modrinth 模组的文件路径的规范对策

• 临时解决 Modrinth 独占模组的文件路径：projects/[版本]/assets/0-modrinth-mod/modid/
• 打包器和 CFPABot 部分重写（交给技术）
• 正式解决 Modrinth 独占模组的文件路径：projects/[版本]/assets/[平台]/[平台对应id]/modid/（完成重写后勾）

[dovisutu]

• 其实打包并不在意现在被叫做cf-name的这层文件夹叫什么，只要是唯一的就可以了（我印象中当时写的参数名直接叫做mod-name）
  倒是bot会假定这是cf模组，从而出错......

理论上在现有的名称里加上modrinrh标记其实就足够bot识别了， 除非有什么神奇mod名字带modrinth的 ；新开一层文件夹的问题就是大规模移动，以及各种部件都要更改，工作量有点大

[TexBlock]

• 其实打包并不在意现在被叫做cf-name的这层文件夹叫什么，只要是唯一的就可以了（我印象中当时写的参数名直接叫做mod-name）
  倒是bot会假定这是cf模组，从而出错......

理论上在现有的名称里加上modrinrh标记其实就足够bot识别了， 除非有什么神奇mod名字带modrinth的 ；新开一层文件夹的问题就是大规模移动，以及各种部件都要更改，工作量有点大

新开一层文件夹这个东西是我在群里提的，我认为这样比较保险一些（但是好像没考虑工作量）。🤔

[dovisutu]

我大概陈述一下我的想法：

• 在现有的CurseForge 项目名这层文件夹下，与命名空间并列的位置，加上一个标记文件（名称、格式待定，可以由CFPAbot的支持来决定），用于标记下载源、slug和project id（CF）等信息。
  • 没有统一下载源或有多个的也可以在这里说明。
  • 没有该文件的，默认按curseforge处理，slug -> id的映射使用bot自带的。
• 修改对CurseForge 项目名的定义，将其定义为模组唯一标识符之类的名称。
  • 对于Cf模组，可以沿用目前的Slug；Mr模组可以找类似物，或者另起一个（如果冲突的话）。
  • 同时，可能可以考虑清理1.12.2下的1UNKNOWN目录（这是当初增加模组名这一层的副产物）。
  • 考量：目前用于放置字体修复的minecraft命名空间应当放在何种唯一标识符下？（由于必须要覆盖minecraft:default与minecraft:uniform，不可能完全移出此命名空间。但是仍可以考虑修改其标识符，以更明确地指出“字体修复”这一用途。）

修改量

• Bot：需要增加对标记文件的支持——反正无论何种办法，Bot必须要修改。
• Packer丨Actions：基本无需修改。
  • 目前的文件检索方式应该不会检索到标记文件，因为并未放在命名空间以下，除非被谁塞到additionalContents了。
  • Actions据我所知也没有引用具体的文件结构。
• 仓库结构：
  • Modrinth相关模组需要移至正确位置，加上正确标记。
  • 1UNKNOWN类（如果需要修正）也要移动。
  • 其余内容基本无需移动。
• 贡献指南等参考资料：所有对CurseForge 项目名的引用都需要改名，并且可能需要小规模修改。

相较于直接加一层文件夹应该要好点——尤其考虑到这种大型修改可能会导致大量文件错乱，这是之前已经发生过的事情。如#1163 。

[DrIceTea123]

提出一些我的大致想法

由于：

• 目前CFPA仓库以CurseForge为主要模组来源
• 大多数模组都来自CurseForge或Modrinth
• CurseForge与Modrinth都（分别）有属于该模组的唯一Project ID，（在自身库内）不会重复
• CurseForge 项目名对打包无任何影响

我的建议：使用前缀区分模组发布平台

• CurseForge平台模组（或CF/Mr双平台模组）提交方式不变，即无前缀默认为CurseForge平台
• 仅Modrinth平台的模组，提交时在CurseForge 项目名前加[Modrinth]前缀，并使用Modrinth项目名
• 【可选】极少量的不发布于CF与Mr平台、仅发布于Github上的模组，提交时在CurseForge 项目名前加[Github]前缀，并使用Github仓库名
• 极少量的除CF、Mr、Github之外平台的模组（第三方模组），提交时在CurseForge 项目名前加[Unknown]前缀，并使用模组显示名的驼峰命名法（去除非法字符）

以匠魂3（Tinkers' Construct 3）为例：

• CurseForge地址：网页 ；项目名：tinkers-construct
• Modrinth地址：网页 ；项目名：tinkers-construct
• Github仓库：网页；仓库名：TinkersConstruct
• 模组命名空间：tconstruct
• 作为CF模组的提交路径（1.18）：project/1.18/assets/tinkers-construct/tconstruct/lang/zh_cn.json
• 作为仅Mr模组的提交路径（1.18）：project/1.18/assets/[Modrinth]tinkers-construct/tconstruct/lang/zh_cn.json
• 作为仅Github模组的提交路径（1.18）：project/1.18/assets/[Github]TinkersConstruct/tconstruct/lang/zh_cn.json
• 作为第三方模组的提交路径（1.18）：project/1.18/assets/[Unknown]TinkersConstruct3/tconstruct/lang/zh_cn.json

优点：

• 操作简单明了，不引入额外文件/文件夹，避免提交流程复杂化，避免文件/文件夹过度嵌套
• Bot修改逻辑简单，无需检测更多内容，只需在检测CurseForge 项目名时先检测前缀即可
• 对于（可能会出现的）第三模组平台甚至第四模组平台的兼容度高，后续（几乎）无需再修改

缺点：

• 现有仓库结构调整较为复杂，需要找到所有库内Modrinth提交的Modrinth项目名，以及清查所有UNKNOWN文件夹
• 对于仅Github模组和未知来源（第三方）模组，缺少溯源途径（Github模组或许可以再加上作者名以溯源，或要求在提交此类模组时附带发布地址）
• 【核心问题】对于多平台发布的模组难以核查，且较难避免多平台重复提交

总结：以上操作可以作为（长期的？）临时方案，可行性较高，可快速兼容Modrinth，并且仅需修改Bot与部分仓库结构；缺点也很明显，因此在解决模组发布平台核查方法的问题前，不适合作为永久方案。

[dovisutu]

这个方法也行。主要是看仓库这边和bot的协调，对我来说其实没什么工作，只要总体结构没改。

（不过，如果以后准备“按需打包”的话，已经需要准备从modid（或者别的）到cf-id的映射了；不过这个不知道适不适合放在主库里面）

[Cyl18]

bot这边我都可以改 目前都写了一点了

[Cyl18]

• 对于移动目录的方案：
  对 CFPABot 的屎山级别的代码来说，无异于重写，所以我不支持，当然我要是有决心的话还是想推动减少 GitHub 使用的方案

• 对于在文件夹名前添加前缀的方案：
  我心里找不到一个又美观又符合编程命名法的命名方法

  • modrinth-XXX 万一有 mod 在 CF 上就叫这个名字咋办
  • modrinth_XXX-XXX 我靠这也太丑了

• 对于添加标记文件的方案：
  排除法， 我觉得挺好，可扩展性强。至于方便提交者提交的话，可以依靠 CFPABot / CFPABot 的网页功能

[DrIceTea123]

提问：添加标记文件的方案，如何处理CurseForge和Modrinth平台同项目名不同模组的冲突？

[TexBlock]

提问：添加标记文件的方案，如何处理CurseForge和Modrinth平台同项目名不同模组的冲突？

这个概率有多大，感觉不会发生这种事（

[Cyl18]

我觉得吧 用 modrinth-XXX 的方案最简单了， 万一有 mod 在 CF 上就叫这个名字那就特殊处理

[Cyl18]

我拍板了 就用 modrinth-XXX，bot支持已经写好

[Cactusstudent]

我觉得吧 用 modrinth-XXX 的方案最简单了， 万一有 mod 在 CF 上就叫这个名字那就特殊处理

拟定转正，我稍后写Doc