Cobblemon训练家战斗指令

.detail-panel[hidden] { display: block !important; } .detail-tabs { display: none; } /* These three panels are rendered by the browser. */ [data-versions], [data-changelog-panel], [data-comments] { display: none; }

Cobblemon 训练师战斗指令（TBCS）

提供用于管理训练师和开始战斗的指令，可充当其他模组（例如 Easy NPC）的接口。

此模组主要面向地图作者和整合包开发者。

支持者

指令

tbcs
- attach <trainerId> <entity>：将指定的训练师附加到指定的实体上（一个训练师只会被附加到一个实体）。该附加关系在服务器重启后不会保留。
- battle <battleFormat> <participants1>... vs <participants2>... [rules <battleRules>] [onwin <winCommands>]：在指定的参与者之间以指定的战斗格式、规则和胜利指令开始一场战斗（后两者为可选）。
- reload <trainerId>：允许从任何配置的训练师路径重新加载单个训练师（使用原版 /reload 指令可重新加载所有训练师）。

重要提示：自版本 0.14.0-beta 起，attach 指令仍然可用，但通常建议使用 as <trainerId> 参数（详见参与者）。

所有指令都需要权限等级 2。

参与者

battle 指令支持多种参数类型来指定战斗参与者。这些包括单个实体选择器（如 @s、@e[...,limit=1] 或 @p）、实体 UUID 和训练师 ID。

此外，可选参数 as <trainerId> 可用于在战斗开始时立即将训练师附加到选定的实体上：

此参数可以跟在任何实体选择器之后，并允许指定一个训练师 ID，该训练师将在战斗开始时附加到该实体上。
使用此参数等同于对目标实体调用 attach，并且使显式调用 attach 变得多余（虽然 attach + battle 仍然有效，但通常建议使用 battle ... <entity> as <trainerId>）。
当与玩家选择器一起使用时（例如 @s as <trainerId>），玩家将使用该训练师队伍的临时副本进入战斗（尽情设置谜题吧）。
当与另一个训练师 ID 一起使用时（例如 <trainerId_1> as <trainerId_2>），trainerId_2 将被附加到 trainerId_1 当前所附加的同一实体上（如果可能的话）。

as <traineId> 参数自版本 0.14.0-beta 起可用。

战斗规则

战斗规则由具有以下属性的 json 对象描述：

maxItemUses：指定每位参与者在战斗中可以使用多少物品。

是的，目前只有这一个属性。

胜利指令

胜利指令也由 json 对象描述，但其结构更具动态性。一个胜利指令对象可以为每个战斗方（即 1 或 2）定义一个属性，其中包含在该方获胜时执行的指令数组（见下方示例）。

此外，任何胜利指令都可以访问特殊的选择器（类似于 @s 或 @e），允许在指令中选择任意战斗参与者。这些选择器的结构如下：@<n>，其中 <n> 指定战斗参与者的位置，相对于执行胜利指令的一方而言。

在讨论指令时，需要回答一些重要的问题：谁在执行指令？在哪里执行？

胜利指令通常由服务器在所有战斗参与者的中心位置执行。不过，也可以让战斗中的任何参与者成为指令的执行者，在这种情况下，该指令也在该参与者的位置执行。

现在，正式描述到此为止，让我们进入……

示例

重要提示： 以下指令中使用的训练师（例如 tbcs:mytrainer1）仅为示例。您必须提供自己的训练师或安装其他提供训练师的模组（参见下方训练师部分）。

tbcs attach tbcs:mytrainer1 @e[type=minecraft:villager,limit=1,sort=nearest]

将 tbcs:mytrainer1 附加到最近的村民。

tbcs battle GEN_9_SINGLES @s vs tbcs:mytrainer1

在执行指令的玩家和 tbcs:mytrainer1（必须已附加到某个实体）之间开始一场战斗。

tbcs battle GEN_9_SINGLES @s vs tbcs:mytrainer1 rules {maxItemUses: 1}

如上所述，但将每方的物品使用次数限制为 1。

tbcs battle GEN_9_SINGLES @s vs tbcs:mytrainer1 rules {maxItemUses: 1} onwin {1: ['give @1 minecraft:diamond']}

另一个类似示例，但这次玩家获胜时会获得一颗钻石（第一方的第一个参与者）。

tbcs battle GEN_9_SINGLES @s vs tbcs:mytrainer1 onwin {1: ['loot spawn ~ ~ ~ loot minecraft:chests/simple_dungeon']}

这是使用 give 的替代方案（通常奖励更多，但这取决于战利品表）。胜利指令将由服务器在所有战斗参与者的中心位置执行。若要以玩家身份执行指令（即让战利品直接生成在玩家头顶），可以在 loot 指令前加上 @1（另见下方示例）。

tbcs battle GEN_9_MULTI @s tbcs:mytrainer1 vs tbcs:mytrainer2 tbcs:mytrainer3 onwin {1: ['give @1 minecraft:diamond', '@2 say We got them!']}

这是一个位置选择器的示例。当第一方（即玩家方）获胜时，玩家将获得一颗钻石，tbcs:mytrainer1 将说 “We got them!”。这也展示了指令如何从服务器以外的其他来源执行（第二条指令将由 tbcs:mytrainer1 所附加的实体执行）。

tbcs battle GEN_9_MULTI @s tbcs:mytrainer1 vs tbcs:mytrainer2 tbcs:mytrainer3 onwin {1: ['give @1 minecraft:diamond', '@2 say We got them!'], 2: ['@3 tp ~ ~10 ~']}

我们可以通过添加另一方的胜利指令来扩展前面的示例，即如果玩家方失败则执行这些指令。提醒一下，位置参数是相对于胜利指令所在方的，并且从左到右排列。因此，对于从第二方执行的指令，选择器的映射如下：

@1 -> tbcs:mytrainer2
@2 -> tbcs:mytrainer3
@3 -> @s
@4 -> tbcs:mytrainer1

作为参考，从第一方执行的指令将按如下方式映射选择器：

@1 -> @s
@2 -> tbcs:mytrainer1
@3 -> tbcs:mytrainer2
@4 -> tbcs:mytrainer3

因此，第二方的胜利指令将在玩家方失败（即第二方获胜）时惩罚玩家，方式是将玩家从其当前位置相对向上传送 10 格（该指令由玩家执行）。

tbcs battle GEN_9_SINGLES @s vs tbcs:mytrainer1 onwin {1: ['@2 say Not bad, but are you ready for this?!', 'tbcs attach tbcs:mytrainer2 @2', 'tbcs battle GEN_9_SINGLES @1 vs tbcs:mytrainer2 onwin {1: [\'give @1 minecraft:diamond\']}']}

这个示例将一场战斗连接到另一场战斗。让我们来分析一下（所有这些都在玩家获胜时执行）：

第一条指令将使 tbcs:mytrainer1 的训练师实体说 “Not bad, but are you ready for this?!”
第二条指令将另一个训练师 tbcs:mytrainer2 附加到 tbcs:mytrainer1 所附加的同一实体上。
第三条指令紧接着在玩家和 tbcs:mytrainer2 之间开始另一场战斗。这场战斗也有自己的胜利指令定义，玩家获胜时将获得一颗钻石作为奖励。

查看指令的实际效果：

战斗连战演示

这可以无限重复。请注意，胜利指令嵌套越深，就需要越多的反斜杠（\）来*转义*包围指令的撇号（'）。

tbcs battle GEN_9_SINGLES @s vs tbcs:mytrainer1 onwin {2: ['@1 say You need to practice more @2!'], 1: ['@2 say You got me. Take this @1', 'loot spawn ~ ~ ~ loot minecraft:chests/end_city_treasure']}

这里没有什么新东西。这只是我的一次测试指令。

Easy NPC 示例

Easy NPC 演示

注意：该视频来自旧版本，训练师 ID 的结构现在略有不同（请参阅游戏内指令的提示），但功能是相同的。您可以在仓库中找到完整视频。

训练师

结构

训练师可以使用 json 定义，训练师模式由 RCTApi 提供，因此其结构与我的另一个模组 Radical Cobblemon Trainers 基本相同（唯一的例外是 identity（此模组中不存在）以及 battleFormat 和 battleRules（两者都是指令参数））。您可以在相应的文档中找到更多信息和示例。

位置

每当加载世界时，将在所有 trainerPaths 中搜索训练师文件，该列表是相对于世界目录的路径列表。所有训练师都将注册一个ID，该 ID 由其文件名派生。例如，假设我们有一个如下的 minecraft 安装目录（简略版）：

mods
config
trainers
  bug_catcher.json
saves
  My Cool World
    Strong Trainers
      Ash Ketchum.json
  Boring World
...

假设 trainerPaths 定义为：["Strong Trainers", "../../trainers"]。

加载 My Cool World： 这将注册训练师 tbcs:bug_catcher 和 tbcs:ash_ketchum。
加载 Boring World： 这将仅注册训练师 tbcs:bug_catcher。

如果具有相同 ID（即不同文件夹但相同文件名）的训练师被多次注册，则后续训练师的 ID 将附加一个计数器（_n）。

兼容性

该模组与其他同样依赖于 RCTApi 的模组兼容。当这些模组也安装时，来自这些模组的训练师副本将自动注册到 TBCS（参见配置）。

Radical Cobblemon Trainers

配置

配置文件位于 config/tbcs-server.toml：

[Trainers]
  #━━━━━━━━━━
  #相对于世界目录的路径列表，用于在（重新）加载世界时搜索训练师 json 文件。
  #
  #默认值: ["trainers", "../trainers", "../../trainers"]
  trainerPaths = ["trainers", "../trainers", "../../trainers"]
  #━━━━━━━━━━
  #同样依赖 RCTApi 来定义训练师的模组 ID 列表。
  #来自所列模组的训练师副本也会注册到 TBCS。
  #
  #默认值: ["rctmod"]
  trainerMods = ["rctmod"]

[Commands]
  #━━━━━━━━━━
  #胜利指令的更高权限等级。
  #
  #默认值: 2
  #范围: 1 ~ 4
  winCommandsPermission = 2

仅服务端 API

自版本 0.14.0-beta 起，一个 API 版本 将随常规模组一同分发（文件名带 api 后缀，例如 tbcs-api）：

所有 API 功能仅在服务端，可以与任何 tbcs-api 版本一起安装（即客户端无需安装 TBCS）。
如果服务器上安装了常规的 TBCS 模组，则不应同时安装 tbcs-api，因为 TBCS 已包含该 API（这将要求客户端也必须安装 TBCS）。
模组的 API 版本不提供任何指令，它本身不执行任何操作（它仅为可能依赖 TBCS 的其他模组提供功能）。