CFPAOrg
[其他]：关于 Modrinth 模组的文件路径的规范对策
- [x] 临时解决 Modrinth 独占模组的文件路径：
projects/[版本]/assets/0-modrinth-mod/modid/ - [ ] 打包器和 CFPABot 部分重写（交给技术）
- [ ] 正式解决 Modrinth 独占模组的文件路径：
projects/[版本]/assets/[平台]/[平台对应id]/modid/（完成重写后勾）
- 其实打包并不在意现在被叫做cf-name的这层文件夹叫什么，只要是唯一的就可以了（我印象中当时写的参数名直接叫做mod-name） 倒是bot会假定这是cf模组，从而出错......
理论上在现有的名称里加上modrinrh标记其实就足够bot识别了， ~除非有什么神奇mod名字带modrinth的~ ；新开一层文件夹的问题就是大规模移动，以及各种部件都要更改，工作量有点大
- 其实打包并不在意现在被叫做cf-name的这层文件夹叫什么，只要是唯一的就可以了（我印象中当时写的参数名直接叫做mod-name） 倒是bot会假定这是cf模组，从而出错......
理论上在现有的名称里加上modrinrh标记其实就足够bot识别了， ~除非有什么神奇mod名字带modrinth的~ ；新开一层文件夹的问题就是大规模移动，以及各种部件都要更改，工作量有点大
新开一层文件夹这个东西是我在群里提的，我认为这样比较保险一些（但是好像没考虑工作量）。🤔
我大概陈述一下我的想法：
- 在现有的
CurseForge 项目名这层文件夹下，与命名空间并列的位置，加上一个标记文件（名称、格式待定，可以由CFPAbot的支持来决定），用于标记下载源、slug和project id（CF）等信息。- 没有统一下载源或有多个的也可以在这里说明。
- 没有该文件的，默认按curseforge处理，slug -> id的映射使用bot自带的。
- 修改对
CurseForge 项目名的定义，将其定义为模组唯一标识符之类的名称。- 对于Cf模组，可以沿用目前的
Slug；Mr模组可以找类似物，或者另起一个（如果冲突的话）。 - 同时，可能可以考虑清理1.12.2下的
1UNKNOWN目录（这是当初增加模组名这一层的副产物）。 - 考量：目前用于放置字体修复的
minecraft命名空间应当放在何种唯一标识符下？（由于必须要覆盖minecraft:default与minecraft:uniform，不可能完全移出此命名空间。但是仍可以考虑修改其标识符，以更明确地指出“字体修复”这一用途。）
- 对于Cf模组，可以沿用目前的
修改量
- Bot：需要增加对标记文件的支持——反正无论何种办法，Bot必须要修改。
- Packer丨Actions：基本无需修改。
- 目前的文件检索方式应该不会检索到标记文件，因为并未放在
命名空间以下，~除非被谁塞到additionalContents了~。 - Actions据我所知也没有引用具体的文件结构。
- 目前的文件检索方式应该不会检索到标记文件，因为并未放在
- 仓库结构：
- Modrinth相关模组需要移至正确位置，加上正确标记。
- 1UNKNOWN类（如果需要修正）也要移动。
- 其余内容基本无需移动。
- 贡献指南等参考资料：所有对
CurseForge 项目名的引用都需要改名，并且可能需要小规模修改。
相较于直接加一层文件夹应该要好点——尤其考虑到这种大型修改可能会导致大量文件错乱，这是之前已经发生过的事情。如#1163 。
提出一些我的大致想法
由于：
- 目前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与部分仓库结构；缺点也很明显，因此在解决模组发布平台核查方法的问题前，不适合作为永久方案。
这个方法也行。主要是看仓库这边和bot的协调，对我来说其实没什么工作，只要总体结构没改。
（不过，如果以后准备“按需打包”的话，已经需要准备从modid（或者别的）到cf-id的映射了；不过这个不知道适不适合放在主库里面）
-
对于移动目录的方案： 对 CFPABot 的~~屎山级别的~~代码来说，无异于重写，所以我不支持，当然我要是有决心的话还是想推动减少 GitHub 使用的方案
-
对于在文件夹名前添加前缀的方案： 我心里找不到一个又美观又符合编程命名法的命名方法
-
modrinth-XXX万一有 mod 在 CF 上就叫这个名字咋办 -
modrinth_XXX-XXX我靠这也太丑了
-
-
对于添加标记文件的方案： ~~排除法，~~ 我觉得挺好，可扩展性强。至于方便提交者提交的话，可以依靠 CFPABot / CFPABot 的网页功能
