GuillaumeVDN的插件文档/QuestCreator/基础内容

GuillaumeVDN的插件文档
页面	GuillaumeVDN的插件文档 · 迁移
所有插件都有的常见内容	配置 · 杂项 · 关联
QuestCreator	基础内容 · 示例 · 详细特性 · 高级内容 · 关联

视频

QuestCreator介绍（英语）

我制作的这个视频涵盖了大多数核心特性的介绍。如果你是刚使用这款插件，那么我推荐你从头看到尾。在视频下方的描述里写有了时间点，你可以根据需求跳到特定的时间点观看。

https://www.youtube.com/watch?v=5Lwh9qGReVk

QuestCreator介绍（西班牙语）

maxmar628用西班牙语介绍了QuestCreator。

https://www.youtube.com/watch?v=ARukGd7m5zc

QuestCreator介绍（英语）

InkBat制作的介绍任务结构的视频。这个视频有一段时间了，因此配置部分和现在的已截然不同。

https://www.youtube.com/watch?v=KjZ9gaJlObI

文件结构

这一部分描述了 /plugins/QuestCreator/ 内的文件结构。

配置

主要的配置文件是/config.yml，该文件包含了不少有用的设置。文件内的注释详细地解释了每一个选项。

你可以在对应的.yml文件内配置用户、服务器和全局变量。

点击下载默认配置文件

元素存储位置

所有元素（任务模型、任务池、GUI、全局分支、全局目标等）都存储在对应的文件夹内：

• /quest_activators/
• /quest_models/
• /quest_models_functional/
• /quest_groups/
• /quest_pools/
• /guis/
• /global_branches/
• /global_conditions/
• /global_gui_items/
• /global_objects/
• /global_time_frames/

在每个文件夹里，每个元素都是一个 .yml格式的文件。比如，/quest_models/my_quest.yml 是id为my_quest的任务模型。id对于大小写敏感（须小写）。

你也可以创建子文件夹来更清晰地给文件分类。

数据

如果你使用JSON作为数据板的后端，数据文件将保存在/plugins/QuestCreator/data_v6/下。删除该文件夹将导致所有当前用户数据的丢失（活跃中的任务、任务历史、用户变量等）。需要注意的是，任务点数存储在GCore的数据统计系统中，在/plugins/GCore/data_v8/statistics/下以JSON的形式存储。

任务介绍

任务模型

你最先需要区分的概念就是“任务”和“任务模型”。

“任务模型”是配置文件，其包含在玩家进行任务时可能会遇到的种种可能性相关的配置。任务模型位于/quest_models/。

“任务”代表活跃中的任务模型。每名玩家（或多名组队玩家）可能会有不同选择和进度的“任务”实例。

理解分支和目标

进行中的任务至少拥有一个已激活的“分支”以及分支内的目标。你可以将分支视作“任务目标的容器”。

任务目标代表以下两者：

• 玩家必须完成的任务对象
• 或是服务器必须执行的操作（比如发送消息、播放音效、操控实体等）

在任务中，虽然每个分支只有一个活跃的目标，但你可以给任务设置多个分支。

以下是一份活跃任务可能的配置结构草稿（并不是实际的配置）：

my_active_quest:
  branch_1: *active
    - object_1
    - object_2
    - *object_3
    - object_4
  branch_2: *active
    - *object_1
    - object_2
  branch_3: not active
    - object_1
    - object_2
    - object_3
    

在任务模型中共有3个分支，但只有2个分支活跃在玩家的任务中。在这2个分支里有很多种可能的目标，但在每个分支中只有一个是活跃的目标。

实践

让我们将理论付诸于实践吧：

branches:
  branch_1:
    starts_directly: true
    starts_at: object_3
    objects:
      object_1:
        # …… 此处省略目标设置
      object_2:
        # …… 此处省略目标设置
      object_3:
        # …… 此处省略目标设置
      object_4:
        # …… 此处省略目标设置
  branch_2:
    starts_directly: true
    starts_at: object_1
    objects:
      object_1:
        # …… 此处省略目标设置
      object_2:
        # …… 此处省略目标设置
  branch_3:
    starts_directly: false
    starts_at: object_2
    objects:
      object_1:
        # …… 此处省略目标设置
      object_2:
        # …… 此处省略目标设置
      object_3:
        # …… 此处省略目标设置

这份配置里有很多信息，这些信息混淆了我们迄今谈到的不同概念。

分支配置下的每个分支都代表一个可能的分支，它们拥有不一样的标识符（branch_1、branch_2……）。

每个分支的starts_directly布尔设置用于指示该分支是否在任务开始时自动开始。branch_3的布尔值为false，该分支会之后手动开始。

objects下方是可用的任务目标。你可以在不同的分支内使用相同的目标名。

goto的重要性

虽然分支有可以目标的“列表”，但这些目标并不一定按顺序执行。比如在上面示例中的branch_1，你可以决定先运行object_3再运行object_2。

每个分支的starts_at设置用于指示插件应该在分支开始时开始哪个任务目标。

同一目标可以重复执行，比如：object_3 > object_2 > object_1 > object_4 > object_1 > object_4 > …… 并在满足特定条件时停止循环。

简而言之，从我们看到这里为止，这个插件还“不够聪明”，不能检测出它下一步应该运行什么目标，因为你实际上已经从“固定的列表顺序”中解放出来了。你必须向插件表明它下一步应该运行什么目标，或者更笼统的说是“它应该执行什么goto”。

让我们将goto加入到分支branch_1中吧：

object_1:
  # …… 此处省略目标设置
  goto: OBJECT object_4
object_2:
  # …… 此处省略目标设置
  goto: OBJECT object_1
object_3:
  # …… 此处省略目标设置
  goto: OBJECT object_2
object_4:
  # …… 此处省略目标设置
  goto: OBJECT object_1

这份配置遵循了示例中的顺序：object_3 > object_2 > object_1 > object_4 > object_1 > object_4 > ……，即使由于未设置任何条件，目标1和4会无限循环。条件与逻辑将在本文档后面解释，而该份示例清晰地解释了goto的作用。

所以在这里，你使用goto类型表示你希望在当前目标完成后运行同一分支的目标。但实际上，goto的触发方式不仅仅是目标，它们可以启动或停止分支、完成任务、操作其它任务等。请查看这里的goto类型列表。

在示例中的分支branch_3不会自动开始。 我们可以在任务的任意阶段开始该分支！比如在第二个分支结束时开始该分支：

  branch_2:
    starts_directly: true
    starts_at: object_1
    objects:
      object_1:
        # …… 此处省略目标设置
        goto: OBJECT object_2
      object_2:
        # …… 此处省略目标设置
        goto: BRANCH branch_3

当玩家完成object_2时会开始分支branch_3。因为branch_2的goto不会调用同一分支的目标，所以该分支会停止。别担心，你还有很多方式开始其它分支，而这只是个示例。

最后请注意，如果没有活跃的分支（由于某个地方缺失了goto），任务就会停止。

简易示例

I’ve used kind of complicated examples until here so you could visualize the different concepts. Here’s a practical example of a simple NPC farm quest.

branches:
  unique_branch:  # 这是个简单任务，因此我们只需要一个分支
    starts_directly: true  # this is actually true by default
    starts_at: START_NPC_DIALOG   # we start the quest by talking to the NPC
    objects:
      START_NPC_DIALOG:
        # ... our dialog settings go here
        goto: OBJECT FARM_STONE
      FARM_STONE:
        # ... our farming settings go here
        goto: OBJECT DELIVER_ITEMS_TO_NPC
      DELIVER_ITEMS_TO_NPC:
        # ... our NPC delivery settings go here
        goto: OBJECT END_NPC_DIALOG
      END_NPC_DIALOG:
        # ... our dialog settings go here
        goto: QUEST_SUCCESS  # this will stop the quest and mark is as successfully completed

Note : I know the goto’s system can be seen as annoying at first glance. Practically, especially for such simple quests, you’ll have your first object be the first of the list and your goto’s will actually follow the order of the list. But for more advanced quests, the goto’s brings the essential freedom you need to truly be able to perform dialogs, loops, logic, etc. QuestCreator wasn’t designed to be simple, but powerful. Don’t worry, you can easily get the hand of it with some patience :D

更多目标和模型设置

Obviously, there aren’t just branches and objects configured in our quest model, there are many others settings.

A detailed list of objects settings can be found here.

A detailed list of model settings can be found here.

激活器介绍

Now, you have a quest, right ? But how can the player start it ?

If you want, you can give them the permission to start quests via the /quest start [quest] command. You could also configure a GUI so they can see all the quests and manage it there.

But you could also want the quest to start when talking to a Citizens NPC, or when they enter a certain area, or just automatically.

That’s the main purpose of activators : to activate quests under certain conditions. They’re located under /quest_activators/.

It’s pretty simple to add an activator to a quest : just create the activator and the settings for it, and then add the activator to your quest model :

activators:
  - my_activator

If my_activator is a physical activator, the quest will start when the player interacts with it. Otherwise, it’ll just start when the activator’s conditions are respected.

Read more about activators and their settings here.

任务池介绍

You might want to make it so some of your quests are available daily or weekly, and change it every day/week.

This is where quest pools are useful. They’re located under /quest_pools/.

理解任务池处理方式

A quest pool doesn’t have direct control on the starting of quests. What it does is ‘processing’ the quests for each period (a period is ‘the current day/week/…’) : calculating which quests will be available during the period.

When the player connects, the pool will check if it has already processed its quests for the player during the current period. For instance, let’s say you have a daily period and GuillaumeVDN connects for the first time that day at 15:30. The pool will not yet have processed the quests for him ; however, player Notch who connected at 14:00 will already have his quests processed for the day.

Once the pool processed a player for the active period, it doesn’t do it again it until the next day (or until it’s manually reset through a command).

任务券

Unlike regular quest management, quest pools work with a ‘token’ feature for quests. When a pool processes its quests for a said period, it gives them tokens.

Then, when the player wants to start the quest (through an activator or a gui, for instance), the plugin detects if the quest is in a pool and if it has remaining tokens.

When the player starts the quest once, one token is ‘consumed’ (taken from the player). Once the player doesn’t have any tokens left, they won’t be able to start the quest until the pool reprocesses, in the next period.

For instance, for a daily period, if the token is consumed today at 18:30, no new tokens will be available until reprocessing when the next day starts, at midnight (or later tomorrow if the player is not online then).

任务池设置

Read more about pools and their settings here.

游戏内编辑器

Even though I personally like editing through YAML files (because of how you can have a more global view), you can edit almost everything with the in-game editor (open it with /qc edit).

However, I do advise you to read through the documentation once to get a general understanding of the plugin. The in-game editor just contains all the settings and provide tools to edit them, but it does not actually ‘explain’ anything (‘what are quest models’, ‘what are activators’, ‘how to do this’, etc). So it’s just better to understand all of this before getting into it !

All the settings are the exact same as editing through files. Everytime the depth increases (the amount of indentation in YAML), it’s another submenu that opens.

Every basic value will have an icon in the GUI and different click types are available. Everything specific to that setting, and all the actions you can do with it, are explained there.

Most enumeration settings (Citizens NPC, click type, block type, enchantments, etc) can be selected in a menu or quickly imported.

I advise you to try it out by yourself to get a general feel of it ^_^

Because of my custom YAML reader, the original file settings order and comments will be kept when the in-game editor overwrites the file, so you could also configure most of it through files and use the editor to import stuff, for instance items or locations.