跳到主要内容

整合包作者上手指南

先做一份能提交、能领奖的任务，再添加前置、阶段和重复限制。本页使用原版物品和默认来源，不要求 KubeJS。示例数量和报酬用于验证配置，发布时请按整合包经济调整。

本文适用于潮汐委托 1.6.0。

1. 找到实际生效的目录​

启动游戏并进入测试世界，让模组生成配置。单人使用当前游戏实例的 config/tidalcommission/；多人使用服务器目录下的同名目录。只改自己客户端的文件，不会改变远端服务器规则。

文件或目录用途
commission_rules.json来源、翻牌费用、自动补充、时限、入口等共用规则
tasks/作者编写的静态任务 JSON
player_commissions.json玩家自行发布委托的规则，与本页的作者任务分开配置
client_ui.json本地显示设置，不控制任务抽取

在独立测试存档操作，并取得管理员权限（等级 2）。下面的管理器、重载和诊断命令都需要该权限。

2. 保存第一份任务​

创建文件 config/tidalcommission/tasks/official/tutorial_iron.json，完整复制以下内容。保留 official 来源的默认启用状态及正权重。

{
  "id": "tutorial:iron",
  "tier": 1,
  "source": "official",
  "stars": 1,
  "brief_description": "提交一个铁锭",
  "full_description": "接取后，在委托详情中提交一个铁锭，领取一颗绿宝石。",
  "weight": 10,
  "duration": 0,
  "requirements": {
    "type": "item",
    "target": "minecraft:iron_ingot",
    "count": 1
  },
  "accept_cost": {
    "primary": { "item": "minecraft:gold_nugget", "count": 1 }
  },
  "rewards": {
    "primary": { "item": "minecraft:emerald", "count": 1 },
    "extras": []
  }
}

这里有三个不同的标识：

  • tutorial_iron.json 是文件名，供作者管理文件。
  • tutorial:iron 是任务 ID，前置关系和完成记录使用它；tutorial 是作者自行取的命名空间，不要求安装同名模组。
  • official 是来源 ID，必须能在主配置的 sources 中找到。

文件夹用于整理，任务属于哪个来源由 source 决定。不要给两份任务相同的 id。改标题可以保留 ID；改 ID 会让旧完成记录和前置引用无法对应。

3. 先确认加载，再测试提交​

保存文件后执行：

/tc reload
/tc doctor
/tc editor manage

在管理器找到刚才的任务。如果没有出现，先检查扩展名是否为 .json、JSON 语法，以及重载提示和服务端日志是否报告跳过文件。

管理器的「测试」按钮会把选中任务直接放入一个空闲灰卡栏位，并设为进行中。准备一个铁锭，在详情中提交，确认物品消耗且获得一颗绿宝石。这一步无需反复抽卡寻找任务。

「测试」会绕过抽取资格和接取流程。 它适合检查目标、交付和奖励，不能证明来源权重、前置、重复限制或接取费用正确。测试任务完成后也会记录完成历史；验证一次性任务或前置时，应使用没有相关历史的测试玩家。没有空闲灰卡时，先正常结束其他测试委托并等待栏位可用。

4. 再验证正常接取​

执行 /tc open，在灰卡选择一档并翻开。正常路径有三种不同的支出：

支出设置位置本例
翻开栏位主配置 open_costs按当前一档费用准备
接取任务任务 accept_cost一个金粒
提交目标任务 requirements一个铁锭

自动补充省去第一项，不省去第二项。验收费用时使用生存模式，且不要携带会抵扣接取成本的担保凭证。

默认任务也在同一个池里，未抽到本例不等于加载失败。若要隔离测试，在备份后的独立测试实例中，把其他任务文件移到 tasks/ 以外，只保留本例再重载；放到 tasks/backup/ 仍会被递归读取。不要清空正式服任务目录做这种测试。

本例 duration: 0 表示接取后不限时，但翻开后仍须在接取倒计时内接受。改成正数会使用主配置中一档的完成时限，正数本身不是单份任务的自定义天数。

5. 理解任务怎样出现​

普通静态任务先按目标档位筛选，再排除当前不能抽取的任务，例如前置未完成、重复限制未结束、阶段不满足或已占用相关栏位的任务。之后在有候选的来源间按来源权重抽取，再按该来源内部的任务有效权重抽取。

规则回答的问题
tier属于哪个抽取档位？不是章节编号
source属于哪个来源？不是前置关系
来源 weight普通随机抽取时，来源相对其他可用来源有多大机会？
任务 weight同档、同来源内，任务相对其他候选有多大机会？
prerequisites玩家是否完成了指定任务？多个 ID 要全部完成
stage_rules玩家是否具备作者定义的进度标记？
repeat玩家完成过后，还能否再次抽取？

例如只有两个可用来源，权重同为 10，各占一半机会。选中某来源后，其中仅有两个候选任务，权重为 10 和 30，则分别占该来源内的四分之一和四分之三。候选随玩家状态变化，权重不是固定百分比。

自动补充会尝试档位并筛选候选；指定来源栏位允许玩家选择来源。玩家发布委托还有单独的抽取配置，不应直接套用上面的静态任务概率。

6. 按需要增加规则​

第一份任务测试通过后，阅读按需求配置任务：

  • 允许分批提交，或只检查物品不消耗。
  • 从目标或奖励中选择。
  • A 完成后解锁 B，以及两个前置汇合。
  • 一次性、一小时冷却或现实时间每日限制。
  • 获得阶段后开放任务。
  • 增加来源分类。

/tc editor 可新建任务；/tc editor manage 可编辑已有任务。1.6.0 的「条件」页使用「前置委托 ID」文本框，多个 ID 用英文逗号分隔。具体字段见任务 JSON 与数据包。

7. 把配置交给玩家​

本教程直接随整合包分发 config/tidalcommission/tasks/ 与所需主配置。配置文件和玩家存档是两套数据：前者定义任务，后者保存完成记录、阶段及委托板；备份时分别保存。

数据包在当前版本用于初始化配置任务，不能持续覆盖已有配置。目录已有任意任务 JSON 时不会重新导入，且初始化有命名空间限制，详见实际任务目录。不要删除正式配置来强迫重新导入。

发布前，在干净测试实例走一次抽取、接取、提交和领奖。对前置或一次性任务，再用没有完成历史的玩家验证顺序。更新整合包时保留任务 ID，并说明哪些配置文件需要更新。

遇到问题先查哪里​

现象检查顺序
管理器没有任务文件位置、扩展名、JSON 语法、重载提示及服务端日志
管理器有任务但抽不到来源启用及权重、档位、前置记录、重复限制、阶段、栏位占用
完成前置后没马上看到下一项解锁只是获得抽取资格，后续仍需刷新和抽取
改 JSON 后已接取任务没变旧栏位保存了任务实例；用新抽取或重新装入的测试实例检查
测试能完成，正常接取失败「测试」跳过接取流程；另行检查费用和资格
doctor 有数量但仍抽不到玩家诊断主要统计阶段条件，不是全部抽取条件的最终诊断