GuillaumeVDN的插件文档/QuestCreator/基础内容 - 版本历史

2020年11月24日 (二) 02:14 Qsefthuopq

2020-11-24T02:14:46Z

←上一版本		2020年11月24日 (二) 02:14的版本
第175行：		第175行：

	==更多目标和模型设置==		==更多目标和模型设置==
	~~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.~~		你可以给予玩家/quest start [任务] 指令的权限来开始任务，你也可以设置一个可查看并管理全部任务的GUI。

	~~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.~~		你还可以让玩家与Citizens的NPC对话来开始任务，或在玩家进入特定区域时自动开始任务。

	~~That’s the main purpose of activators : to activate quests under certain conditions. They’re located under~~ /quest_activators/.		而这就是激活器的主要用途：在特定条件下激活任务。激活器位于/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:		activators:
	- my_activator		- 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.~~		如果my_activator是物理激活器，任务会在玩家与之交互时开始。否则激活器会在满足特定条件时激活任务。

	~~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/.		而这就要用到任务池。任务池位于/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.~~		当玩家连接到服务器时，任务池会检测是否已处理该玩家该时期的任务。比如阶段为每日，当GuillaumeVDN在当天15:30首次连接到服务器时，此时任务池未处理该玩家的任务。然而此时任务池已处理在当天14:00连接到服务器并完成每日任务的玩家Notch的任务。

	~~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).~~		如果每日任务的券在今天的18:30被消耗，则只有在第二天才会刷新任务券。
	==任务池设置==		==任务池设置==
	~~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).		尽管我个人喜欢通过YAML文件进行编辑（因为这样可以有一个更全面的视角），你也可以用游戏内编辑器来编辑几乎所有的东西（输入/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.~~		通过文件编辑和在游戏内编辑的全部设置都是一样的。增加深度（YAML的缩进数）会打开子菜单。

	~~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.~~		每个基础值在GUI内都有图标和不同的点击类型。你可以在这里查看对设置内的一切选项的解释。

	~~Most enumeration settings (Citizens NPC, click type, block type, enchantments, etc) can be selected in a menu or quickly imported.~~		你可以在菜单中选取或快捷导入大多数我之前所列举出的选项（Citizens NPC、点击类型、方块类型、附魔等）。

	~~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.		由于我使用了自定义的YAML读取器，插件会在重写文件时保留文件的设置顺序和注释，所以你不必担心注释丢失的问题。

Qsefthuopq：/* 简易示例 */

2020-11-24T01:04:15Z

简易示例

←上一版本		2020年11月24日 (二) 01:04的版本
第154行：		第154行：
	最后请注意，如果没有活跃的分支（由于某个地方缺失了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.~~		在这个复杂的示例中你可以看到不同的概念。该示例是NPC任务的实际用例。
	branches:		branches:
	unique_branch: # 这是个简单任务，因此我们只需要一个分支		unique_branch: # 这是个简单任务，因此我们只需要一个分支
	starts_directly: true # ~~this is actually true by default~~		starts_directly: true # 默认为true，自动开始分支
	starts_at: START_NPC_DIALOG # ~~we start the quest by talking to the NPC~~		starts_at: START_NPC_DIALOG # 与NPC对话开始任务
	objects:		objects:
	START_NPC_DIALOG:		START_NPC_DIALOG:
	# ~~... our dialog settings go here~~		# …… 此处省略对话设置
	goto: OBJECT FARM_STONE		goto: OBJECT FARM_STONE
	FARM_STONE:		FARM_STONE:
	# ~~... our farming settings go here~~		# …… 此处省略挖掘目标设置
	goto: OBJECT DELIVER_ITEMS_TO_NPC		goto: OBJECT DELIVER_ITEMS_TO_NPC
	DELIVER_ITEMS_TO_NPC:		DELIVER_ITEMS_TO_NPC:
	# ~~... our NPC delivery settings go here~~		# …… 此处省略交付物品给NPC的设置
	goto: OBJECT END_NPC_DIALOG		goto: OBJECT END_NPC_DIALOG
	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~~		goto: QUEST_SUCCESS # 停止并标记任务为已完成
	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		提示：我知道goto系统可能看起来很复杂，但实际上，特别是对于简单的任务，你的goto会按照列表顺序执行。对于更高级的任务，goto带来的自由度必不可缺。没有goto你就难以实现执行对话、循环、逻辑等功能。QuestCreator的设计理念不是简单，而是强大。熟能生巧，多练练你就会用了。:D

	==更多目标和模型设置==		==更多目标和模型设置==
	Obviously, there aren’t just branches and objects configured in our quest model, there are many others settings.		Obviously, there aren’t just branches and objects configured in our quest model, there are many others settings.

2020年11月24日 (二) 00:46 Qsefthuopq

2020-11-24T00:46:59Z

←上一版本		2020年11月24日 (二) 00:46的版本
第108行：		第108行：
	这份配置里有很多信息，这些信息混淆了我们迄今谈到的不同概念。		这份配置里有很多信息，这些信息混淆了我们迄今谈到的不同概念。

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

	The starts_directly boolean setting for each branch is used to indicate whether this branch should start automatically when the quest starts, or not (like we did for branch branch_3) if you would like to start it later manually.		每个分支的starts_directly布尔设置用于指示该分支是否在任务开始时自动开始。branch_3的布尔值为false，该分支会之后手动开始。

	The objects section is a list of available objects for this branch, with an identifier that must be unique to the branch. But you can have multiple objects named object_1 as long as they’re in different branches (like in our example).		objects下方是可用的任务目标。你可以在不同的分支内使用相同的目标名。
	==goto的重要性==		==goto的重要性==
	Even though a branch has a ‘list’ of available objects, those objects might not follow the list order. For instance, in example above branch_1, you might decide that the branch will first run object_3 and then go to object_2.		虽然分支有可以目标的“列表”，但这些目标并不一定按顺序执行。比如在上面示例中的branch_1，你可以决定先运行object_3再运行object_2。

	~~The starts_at setting for each branch is used to indicate to the plugin at which object the branch should begin when started.~~		每个分支的starts_at设置用于指示插件应该在分支开始时开始哪个任务目标。

	~~You could also repeat objects as many times as you want, for instance : object_3~~ > object_2 > object_1 > object_4 > object_1 > object_4 > ~~... and stop looping until a certain condition is met.~~		同一目标可以重复执行，比如：object_3 > object_2 > object_1 > object_4 > object_1 > object_4 > …… 并在满足特定条件时停止循环。

	So, from what we’ve seen until here, to put it simply, let’s just say the plugin is not ‘smart enough’ to detect what object it should run next, because you’re actually freed from the ‘fixed list order’. You’ll have to indicate to the plugin what object it should run next, or more generally ‘what goto it should perform’.		简而言之，从我们看到这里为止，这个插件还“不够聪明”，不能检测出它下一步应该运行什么目标，因为你实际上已经从“固定的列表顺序”中解放出来了。你必须向插件表明它下一步应该运行什么目标，或者更笼统的说是“它应该执行什么goto”。

	~~So, let’s add goto’s to our branch branch_1 :~~		让我们将goto加入到分支branch_1中吧：
	object_1:		object_1:
	# …… 此处省略目标设置		# …… 此处省略目标设置
第135行：		第135行：
	# …… 此处省略目标设置		# …… 此处省略目标设置
	goto: OBJECT object_1		goto: OBJECT object_1
	~~This respects the order of our example : object_3~~ > object_2 > object_1 > object_4 > object_1 > object_4 > ..., even though here the loop between object 1 and 4 will never stop because we didn’t set any conditions. Conditions and logic are explained further in this documentation, but this example is given to clearly explain the power of goto’s.		这份配置遵循了示例中的顺序：object_3 > object_2 > object_1 > object_4 > object_1 > object_4 > ……，即使由于未设置任何条件，目标1和4会无限循环。条件与逻辑将在本文档后面解释，而该份示例清晰地解释了goto的作用。

	So here, you indicate with the OBJECT goto type that you wish to run an object of the same branch when the current object is completed. But goto’s can actually trigger more than objects, they can start or stop branches, complete the quest, manipulate other quests and stuff. See a list of goto types here		所以在这里，你使用goto类型表示你希望在当前目标完成后运行同一分支的目标。但实际上，goto的触发方式不仅仅是目标，它们可以启动或停止分支、完成任务、操作其它任务等。请查看这里的goto类型列表。

	For instance, we have in our example a branch named branch_3 that doesn’t start automatically. At some point in our quest, we might want to start that branch ! We could do that at the end of the second branch :		在示例中的分支branch_3不会自动开始。我们可以在任务的任意阶段开始该分支！比如在第二个分支结束时开始该分支：
	branch_2:		branch_2:
	starts_directly: true		starts_directly: true
第150行：		第150行：
	# …… 此处省略目标设置		# …… 此处省略目标设置
	goto: BRANCH branch_3		goto: BRANCH branch_3
	Once object 2 is completed, the goto will start our branch_3 branch. And since the goto of branch_2 did not call an object from the same branch, branch_2 will be stopped because it wouldn’t know what to do next in the same branch. Don’t worry, there are ways to start other branches without stopping the current one, but again, this is just for example’s sake.		当玩家完成object_2时会开始分支branch_3。因为branch_2的goto不会调用同一分支的目标，所以该分支会停止。别担心，你还有很多方式开始其它分支，而这只是个示例。

	~~And finally, note that if there are no active branches (due to a missing goto somewhere), the quest stops because it doesn’t know what to do next.~~		最后请注意，如果没有活跃的分支（由于某个地方缺失了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.		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:		branches:
	unique_branch: # ~~this is a simple quest, so we just need one branch~~		unique_branch: # 这是个简单任务，因此我们只需要一个分支
	starts_directly: true # this is actually true by default		starts_directly: true # this is actually true by default
	starts_at: START_NPC_DIALOG # we start the quest by talking to the NPC		starts_at: START_NPC_DIALOG # we start the quest by talking to the NPC

2020年11月23日 (一) 10:57 Qsefthuopq

2020-11-23T10:57:16Z

显示更改

Qsefthuopq：创建页面，内容为“{{模板:VDNBox}} =视频= ==QuestCreator介绍（英语）== 我制作的这个视频涵盖了大多数核心特性的介绍。如果你是刚使用这款插件，…”

2020-10-24T06:43:10Z

创建页面，内容为“{{模板:VDNBox}} =视频= ==QuestCreator介绍（英语）== 我制作的这个视频涵盖了大多数核心特性的介绍。如果你是刚使用这款插件，…”

新页面

{{模板:VDNBox}}
=视频=
==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/ 内的文件结构。
==配置==
The main configuration file is /config.yml, it contains a few useful settings. Everything is explained inside that file with comments.

You can configure user, server and global variables in their respective .yml files.

You can download the default configuration files to take a look.
==元素存储位置==
All elements (quest models, quest pools, GUIs, global branches, global objects, …) are stored in their own folders :
* /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对于大小写敏感（须小写）。

你也可以创建子文件夹来更清晰地给文件分类。
==数据==
If you’re using JSON as a back-end for data boards, data files will be saved under /plugins/QuestCreator/data_v6/. Removing that folder will discard all current user data (active quests, history, user variables, etc). It should be noted that quest points are stored in GCore’s statistics system, located with JSON under /plugins/GCore/data_v8/statistics/.
=任务介绍=
==任务模型==
The first thing to note is the difference between “quests” and “quest models”.

A “quest model” is a configuration file that contain all the configuration and possibilities that will (or might) happen during the quest. They’re located under /quest_models/.

A “quest” represents an active quest model. Each player (or group of players for cooperation) might or might not have a “quest” instance with different choices and progression.
==理解分支和目标==
A running quest has always at least one active “branch” with an active object inside. Each branch can be seen as a “container of objects”.

A quest object represents either :

* An objective that the player must complete (typically, to progress to the next part of the quest)
* Or an action the server must do (for instance, sending messages, playing sounds, manipulating entities, stuff like that).
In a quest, there is only one active object per branch at a time, but you can have multiple running branches.

Here’s a scheme (not actual config) of one possible structure of an active quest :
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

In the quest model, there are 3 available branches, but only 2 of them are active in the player’s quest. In each of those two branches, there are many possible objects, but only one is currently active in each branch.
==实践==
Let’s translate our example into the actual configuration settings of a quest model :

branches:
branch_1:
starts_directly: true
starts_at: object_3
objects:
object_1:
# ... object settings go here
object_2:
# ... object settings go here
object_3:
# ... object settings go here
object_4:
# ... object settings go here
branch_2:
starts_directly: true
starts_at: object_1
objects:
object_1:
# ... object settings go here
object_2:
# ... object settings go here
branch_3:
starts_directly: false
starts_at: object_2
objects:
object_1:
# ... object settings go here
object_2:
# ... object settings go here
object_3:
# ... object settings go here
Lot of information here, it mixes the different concepts we’ve seen so far.

Each branch under the branches configuration section represents a possible branch, with an identifier (branch_1, branch_2, …) that must be unique.

The starts_directly boolean setting for each branch is used to indicate whether this branch should start automatically when the quest starts, or not (like we did for branch branch_3) if you would like to start it later manually.

The objects section is a list of available objects for this branch, with an identifier that must be unique to the branch. But you can have multiple objects named object_1 as long as they’re in different branches (like in our example).
==goto的重要性==
Even though a branch has a ‘list’ of available objects, those objects might not follow the list order. For instance, in example above branch_1, you might decide that the branch will first run object_3 and then go to object_2.

The starts_at setting for each branch is used to indicate to the plugin at which object the branch should begin when started.

You could also repeat objects as many times as you want, for instance : object_3 > object_2 > object_1 > object_4 > object_1 > object_4 > ... and stop looping until a certain condition is met.

So, from what we’ve seen until here, to put it simply, let’s just say the plugin is not ‘smart enough’ to detect what object it should run next, because you’re actually freed from the ‘fixed list order’. You’ll have to indicate to the plugin what object it should run next, or more generally ‘what goto it should perform’.

So, let’s add goto’s to our branch branch_1 :
object_1:
# ... object settings go here
goto: OBJECT object_4
object_2:
# ... object settings go here
goto: OBJECT object_1
object_3:
# ... object settings go here
goto: OBJECT object_2
object_4:
# ... object settings go here
goto: OBJECT object_1
This respects the order of our example : object_3 > object_2 > object_1 > object_4 > object_1 > object_4 > ..., even though here the loop between object 1 and 4 will never stop because we didn’t set any conditions. Conditions and logic are explained further in this documentation, but this example is given to clearly explain the power of goto’s.

So here, you indicate with the OBJECT goto type that you wish to run an object of the same branch when the current object is completed. But goto’s can actually trigger more than objects, they can start or stop branches, complete the quest, manipulate other quests and stuff. See a list of goto types here

For instance, we have in our example a branch named branch_3 that doesn’t start automatically. At some point in our quest, we might want to start that branch ! We could do that at the end of the second branch :
branch_2:
starts_directly: true
starts_at: object_1
objects:
object_1:
# ... object settings go here
goto: OBJECT object_2
object_2:
# ... object settings go here
goto: BRANCH branch_3
Once object 2 is completed, the goto will start our branch_3 branch. And since the goto of branch_2 did not call an object from the same branch, branch_2 will be stopped because it wouldn’t know what to do next in the same branch. Don’t worry, there are ways to start other branches without stopping the current one, but again, this is just for example’s sake.

And finally, note that if there are no active branches (due to a missing goto somewhere), the quest stops because it doesn’t know what to do next.
==简易示例==
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: # this is a simple quest, so we just need one 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.