[2022.06.06][PCD]Denizen新手教程之三：基础篇

本帖最后由秋风残叶于 2022-6-6 22:54 编辑

Denizen新手教程

Denizen Beginner's Guide

译者按

Denizen是一款功能非常强大的脚本引擎类型的服务端插件，如果您对Denizen还不了解请参考这个站内搬运帖。
Denizen虽然功能强大，但学习起来较为复杂，无编程基础的新人想要入门总是十分不易。在以前，Denizen只提供了用来查阅变量/脚本的参考文档，甚至连个入门教程都没有，这更让新手入门雪上加霜。
本插件的搬运者摸索了插件脚本的基本用法，并在搬运帖中写了少量教程，写的十分外行且不系统，但就算是这样的内容也确实帮助了一些服主，帮助他们燃起对Denizen脚本的兴趣，搬运者十分感谢他们的支持。
现在，想必作者团队也发现了插件入门不易的问题，现改版了旧版的 Denizenscript论坛并逐步推出了浅显易懂的入门教程，Denizen的搬运者立刻着手于本教程的翻译工作，现发布本译文。

秋风残叶

本教程总共9个大章节，您现在阅读的是第3大章节

基础篇

The Basics

注意：《基础篇》按照作者原定计划分为12小章节，但作者进度拉胯，目前只完成部分小章节（参下文）

译者目前已跟进作者之进度

原文链接

本部分内容会帮助你理解Denizen提供的所有基础功能，阅读这篇内容之前请务必首先阅读前面的“迈出第一步”内容，如果你不理解本部分教程中的指令（command）或者变量（tags）,请首先阅读“迈出第一步”！

相信阅读到这里的你应该已经有了一部分基础知识，接下来的教程内容不再会按照手把手的模式进行教学，因为我们默认你已经有能力写一些简单的脚本了。

请记住：书读百遍不如实做一遍，你需要将以下教程里提供的脚本复制下来，自己运行一次，从而积累相关脚本的经验，这非常重要。

指令if
短期存储——定义（definitions）
长期存储——标签（flags）
机制与属性（Mechanisms And Properties）
再来一遍——循环（loops）
玩家指令
？
队列系统（queue system）
？
脚本和变量，本为一家——指代型脚本（作者没写完）
？
我已经通关了基础篇！

注意：本部分共12小章节，其中已完成的共8小章（1、2、3、4、5、6、8、12），没写完的共1小章（10），其余则一点没动。

指令if

原文链接

什么是指令if？

一条包含if的指令应该长啥样？

If指令同样也是一种易学易用的指令，这是基础格式：

需完善

- if (某些条件):
- (执行指令)
- (执行指令)

复制代码

需完善

你可以看到，if和其它Denizen指令一样（开头写法一样，且指令后面也有需要添加的参数）但是有一个英文冒号: 在后面（就跟world脚本写事件一样）而且其子指令行相对于if那行来说前面空了很多空格，如果你写子指令前面不空格的话，Denizen可能因为无法识别它们而直接跳过。

让我们看一个实例：

可复制

magic_healing_bell:
type: world
events:
on player right clicks bell:
- if <player.health_percentage> < 25:
- heal
- actionbar "<green>魔法铃铛治疗了你！"

复制代码

可复制

上面的示例脚本的功能是：如果玩家点击一个“魔法铃铛”，将会立刻治疗玩家，但【仅当】玩家血量仅剩25%不到时生效（在后面的教程中，当我们介绍到指令flag时，我们会稍微拓展一点这个“魔法铃铛”的脚本，来让玩家只能每隔几分钟使用一次魔法铃铛功能）

条件

If的含义是“如果”，既然有“如果”那后面肯定会跟各种“条件”，简单来说，条件可以是一个布尔值变量（返回值是true或者false）举个例子 - if <player.on_fire>: ，只有这个布尔值变量返回值是true，后面的子指令才会继续执行，如果返回值是false则根本不执行，你也可以在变量前面加一个英文感叹号“!”来让这一切都反过来——（返回值是false才执行，返回值是true却不执行）例如 - if !<player.on_fire>: 只有玩家没有着火时后面的子指令才会执行。

当然，条件中也可以是一些数据型的变量（相对于布尔型变量稍微复杂一些），你需要将这个数据型变量和某个值做比较，基础的写法应该是 - if (first value) (比较符) (second value): （例如 - if <player.name> == mcmonkey4eva: ）两个需要被比较的值都可以是变量（技术层面上来说，两个需要被比较的值都可以写成普通文本，但俩文本互相比较有什么意义呢？）

“比较符”可用如下几种：

==表示“等于”（- if 3 == 3:将会继续运行它的子指令，但- if 3 == 4:就不行）简而言之就是“如果3等于3，那么继续运行子指令”
!=和上面的刚好相反，表示“不等于”（也就是说- if 3 != 3:不会继续运行它的子指令，但- if 3 != 4:可以），简而言之就是“如果3不等于3，那么继续运行子指令”实际上比较符两边都可以是变量。
>大于 >=大于等于 <小于 <=小于等于为数字型变量比较符，需要注意的是>大于和<=小于等于互斥，而<小于和>=大于等于互斥，另外需要注意：你可能注意到了大于号和小于号><看起来和用来括变量的英文书名号<>完全一致，但它们完全不是一个概念，这没啥，我相信你也不会傻到在一个比较算式中同时用上<>，两个比较符的，比较算式中的< >不会被认作是变量。

把条件组合起来

只是一个简单的比较算式似乎无法满足你的要求？没关系，if指令提供了“组合条件”可以让你做到更多事情！
以下提供两种“组合条件”

如果你在if指令中写入了多个条件，并要求只有全部条件都返回true时才继续执行子指令，请使用一个双写的符号“&&”（和），例如 - if <player.on_fire> && <player.health_percentage> < 25: ，只有玩家同时着火以及低血量都满足时才能继续执行下面的子指令。

如果你在if指令中写入了多个条件，并要求只有任意一个条件返回true时就可继续执行子指令，请使用一个双写的符号“||”（或），例如 - if <player.on_fire> || <player.health_percentage> < 25: ，玩家同时着火以及低血量只需符合任意一项即可继续执行下面的子指令。
如果你想写入更多条件，可以直接把它们串起来，类似- if (condition one) && (condition two) && (condition three)，请注意你在一大串条件里写分隔符时，要么全部写“&&”（和）要么全部写“||”（或），请不要把这俩混合一起用，不然可能会有奇怪的事情发生，比如你想写- if (one) && (two) || (three) && (four): 这是啥意思？我们作为聪明的人类也许能猜出其原本的含义，但是Denizen只是一个插件，实在没有能力读出这是什么。

但我就是要写这种既用&&又用||的条件，怎么办？可以使用英文括号()以及相应的空格来给这些变量分个组，比如下面这个写法：

需完善

- if ( <player.name> == mcmonkey4eva && <player.health_percentage> > 90 ) || ( <player.on_fire> && <player.health_percentage> < 25 ):
- narrate "mcmonkey的血量很足嘛，但是丝毫不关心某个玩家快要被烧死了"

复制代码

需完善

以上就是这种组合的写法，你可以把要使用“和”或者“或”的变量用括号组合起来，而且组合里还可以套组合，但是请务必注意一个一层一层套叠的条件可能让阅读它变得十分困难，你应该写的稍微清晰一些。

If的最常用之处

指令if的功能在我们之前用来示例的“魔法铃铛”脚本里已经展示的很透彻了，其核心功能是：决定何时继续运行下面的子指令，其监听的条件，不仅仅是“玩家是不是点击了钟”更包括了“玩家的血量是不是很低”，简单来说，if的最常用之处就是缩短监听的条件。

有时，你在某些成品脚本文件里可能看到一些脚本看上去写法不同，但能实现同一个功能。

可复制

magic_healing_bell:
type: world
events:
on player right clicks bell:
- if <player.health_percentage> > 25:
- stop
- heal
- actionbar "<green>魔法铃铛治疗了你"

复制代码

可复制

上面这个例子中，指令stop是其上方的if的子指令，其功能是让玩家血量如果大于25%时直接终止整个触发型脚本，和前面我们介绍的脚本恰恰相反，之前我们的脚本的功能是“若玩家血量小于25%则获得治疗”而现在我们这个脚本的功能是“若玩家血量大于25%则无法获得治疗”，如果你想达成许多条件，那么这种写法将会非常有用，这种“排除性”的写法可以使你不需要一条条把需要达成的条件都写进脚本里，来让脚本看起来更加简洁。

If……Else？

Else指令长啥样？

Else指令的用法和if指令差不多。以下是基础写法：

需完善

- if (触发条件):
- (若条件是'true'，执行这个)
- else:
- (若条件是'false'，执行这个)

复制代码

需完善

很简单吧？else指令后面没有跟别的条件，其余内容都和if相同，else指令必须紧跟着前面的if指令，如果前面的if指令返回值是false，那么else里的子指令就会被执行。

让我们还以之前的“魔法铃铛”脚本为例子，并添加进新的else指令：

可复制

magic_healing_bell:
type: world
events:
on player right clicks bell:
- if <player.health_percentage> < 25:
- heal
- actionbar "<green>魔法铃铛治疗了你！"
- else:
- actionbar "<red>你的血量还多着呢，魔法铃铛无法治疗你！"

复制代码

可复制

这个脚本会给血量低于25%的玩家进行治疗，并且还会给出一条提示语，避免让玩家以为点击了铃铛以后什么都没有发生。

你也许会问：我难道不能按照你之前教的，用stop指令么？这样子看上去写的还能短一点。当然！你说的没错，那么else指令的优势在哪里？优势就在于如果你可以在if/else指令后面继续写其它指令，这些指令是否被触发取决于指令if/else的执行情况，请看例子：

可复制

magic_healing_bell:
type: world
events:
on player right clicks bell:
- if <player.health_percentage> > 90:
- actionbar "<red>你的血量还多着呢，魔法铃铛无法治疗你！"
- stop
- if <player.health_percentage> < 25:
- actionbar "<green>好险！你差点死了！魔法铃铛治疗了你！"
- else:
- actionbar "<green>魔法铃铛治疗了你！"
- heal

复制代码

可复制

该脚本会阻止血量超过90%的玩家继续执行此脚本其它指令，只要血量不到90%的玩家都会被治疗，但如果玩家血量低于25%，还能额外看到特殊的消息，如果我们不使用else指令，我们只能这样写：

反面例子

magic_healing_bell:
type: world
events:
on player right clicks bell:
- if <player.health_percentage> > 90:
- actionbar "<red>你的血量还多着呢，魔法铃铛无法治疗你！"
- stop
- if <player.health_percentage> < 25:
- actionbar "<green>好险！你差点死了！魔法铃铛治疗了你！"
- heal
- stop
- actionbar "<green>魔法铃铛治疗了你！"
- heal

复制代码

反面例子

这样写看起来糟透了！别这样写！我们将不得不写heal指令两次，更别提还有两次stop指令，额……你觉得这样写看起来还能接受？那你仔细想想，真正的成品脚本写起来比这些示例要复杂多了，可不止有heal这一条指令，你可能需要把大段的指令复制两遍……万幸else指令帮我们避免了这点！

第3种结局，第4种结局……更多结局！

Else if指令该咋写？

这是一个简单的例子：

需完善

- if (第一个条件):
- (若第一个条件为'true'则执行此指令)
- else if (第二个条件):
- (若第二个条件为'true'则执行此指令)
- else:
- (若以上所有条件都为'false'则执行此指令)

复制代码

需完善

看懂了没，就是把一个if塞进了else的后面，你写多少行else if都可以，唯一的限制是脚本开头必须有一个if打头，你没有必要非要加上一个else，你想加就加，但else应该写在脚本的最后一行。

来看个实例：

可复制

magic_healing_bell:
type: world
events:
on player right clicks bell:
- if <player.health_percentage> > 90:
- actionbar "<red>你的血量还多着呢，魔法铃铛无法治疗你"
- else if <player.health_percentage> < 25:
- actionbar "<red>你伤得太重，魔法铃铛也治不了你了"
- else:
- actionbar "<green>魔法铃铛治疗了你！"
- heal

复制代码

可复制

如果你的血量大于90%，这个版本的“魔法铃铛”脚本不会治疗你，小于25%时也不会治疗你，只有处于90%到25%之间才会治疗你。通过else if指令，我们不再总是需要使用stop来让脚本终止，最终的执行指令heal也仅在条件符合要求时才会触发。

分支套分支，结局套结局

如果你有其他编程语言的经验——等一下，你都会编程了你还看这个破教程干嘛？但是你肯定可以理解所谓“分支”（branch）的含义，如果你不理解，试着想象一棵树，拥有很多分支的树，如果你还是听不懂我在说什么，我将在下文中进行解释。

一个脚本能运行出多少种结局？每个结局都是一个“分支”，而包含所有“分支”的就是整个“树”。

当脚本开始运行时，会从“树根”的位置开始（一般来说就是脚本的第一个指令），这个脚本的走向会在if指令处分叉，分出不同的“分支”。

其实你没必要非要搞懂这些“分支”呀“树”呀什么的，但是如果你看到别人使用了这一概念，至少你要知道他在表达些什么，直到那时你估计能想起这篇教程，到时候还能回来看一看。

此外你还需要注意的两个内容是“通过”（pass）和“不通过”（fail）。如果if后面跟的条件返回值为true，则说明这个if指令“通过”了，就会继续运行接下来的子指令，若if后面跟的条件返回值为false，则说明这个if指令“不通过”，接下来的子指令则不会运行。

再延伸一点

相关的参考文档

短期存储——定义（definitions）

原文链接

定义（definitions）是什么？

“定义”如何使用？

“定义”可以使用Denizen指令define来创建以及修改，也可以被定义变量来读取。

每一个所谓的定义都有其名称以及内容，定义的名称通常是一个固定的名字（但也可以设置为可变的内容），而定义的内容通常是可变的，并在服务器内存中进行更改处理。

定义变量（The Definition Tag）
“定义变量”是一种特殊的变量，它的写法是 <definition[<name>]> ，其中<name>即为定义的名称，若将名称直接写进脚本里，写法应该是 <[<name>]>

例如，一个名称叫做target的定义可以被写作 <[target]> 。

如果名称叫做target的定义包含了种类为EntityTag的内容，那么变量 <EntityTag.health> 就可以被写成 <[target].health>

现在咱们复习一下变量的基础写法，所谓定义变量应该由“基础变量”（Base Tag）作为开头，并且包含了一个可以填入内容的地方，例如变量<element[hi]>，其基础变量部分名字叫element，并写入了一个名叫hi的内容，这种写法是不是和我们之前教的都不同？但实际上定义变量就是这样的格式，你也许会问“这个定义变量中的基础变量部分是啥？我怎么看不到？”答案是：空。没错“空”就是定义变量的基础变量部分，换句话说，一个由0个字组成的玩意就是定义变量的基础变量，你当然看不到。

指令define
你可以使用指令define来修改定义。

Define指令的标准写法是 - define <name> <value>

举个例子：

- define target <player.target> 这个指令将一个名字叫target的定义的内容设置为<player.target>，也就是玩家当前正在看着的位置。
- define count 10 这个指令将一个名字叫count的定义的内容设置为数字10
- define goal <player.health.mul[2]> 这个指令将一个名字叫goal的定义的内容设置为玩家的当前血量，并将此值乘以2

基础使用方法

以下是一个展示define指令基本用法的任务型（Task）脚本。

可复制

def_sample:
type: task
script:
- define current <player.health>
- define goal <util.random.int[2].to[10]>
- narrate "你当前的血量是 <[current]>血，接下来我将把你治疗成 <[current].add[<[goal]>]>血"
- heal <[goal]>

复制代码

可复制

如果你在游戏内使用指令/ex run def_sample，你会看到一条消息，显示你的当前血量以及一个比当前血量稍大一点的数字，之后你将被治疗并达到这个数字的血量（或者直接被治疗满血）

所以define的优势在哪？

如果你认真阅读了上面作为范例的def_sample脚本，你可能会发现define的一个妙用之处：设置随机数值！如果你想把变量util.random同时用在narrate和heal指令里，你可能看到的消息是一个数字，实际治疗的血量又是另一个数字，那岂不很糟？使用了指令define以后，你只需要使用随机数值变量一次，并在脚本其它地方多次调用这个内容。

除了随机数值以外，define指令还能被用于一些不断变化的内容上，请看一下下面的脚本：

反面例子

this_needs_defs:
type: world
events:
after player breaks *_ore:
- ratelimit <player> 30s
- if <player.health> < 5:
- narrate "不错啊小伙子，你刚刚挖掘了一个 <context.material.name> 方块"
- wait 2s
- narrate "但是啊，玩家 <player.name>，你需要关注一下你的血量了！"
- wait 2s
- narrate "你现在只剩下 <player.health> 血量了！还不赶紧治疗一下？"

复制代码

反面例子

第一眼看上去是不是没什么毛病？实际测试运行看起来貌似也没啥问题？问题大了去了，如果玩家血量低于5且正在挖掘矿石，这个问题脚本将会不停地发送消息催促玩家关注血量造成刷屏，绝不可能是每30秒发一次。

许多含有指令wait的脚本，尤其是像上面这个例子中的，其中的wait就好比两次对话之间的停顿一般，但恰恰是这种“停顿”造成了严重问题：上面例子中的脚本，从第一行运行到最后一行一共停顿了4秒，万一玩家在这4秒内血量有变化呢（比如玩家死了，血量归零），你可能会看到类似这种提示语“你现在只剩下20血量了！还不赶紧治疗一下？”，这种提示语是不是很蠢？你以为你是慎重勇者龙宫院圣哉吗？

如果我们使用上了“定义”，我们就可以避免这种蠢情况发生，当我们给玩家血量加了定义以后，我们就可以确保最后一行提示语显示的是正确的低血量。

可复制

better_with_defs:
type: world
events:
after player breaks *_ore:
- ratelimit <player> 30s
- define health <player.health>
- if <[health]> < 5:
- narrate "不错啊小伙子，你刚刚挖掘了一个 <context.material.name> 方块"
- wait 2s
- narrate "但是啊，玩家 <player.name>，你需要关注一下你的血量了！"
- wait 2s
- narrate "你现在只剩下 <[health]> 血量了！还不赶紧治疗一下？"

复制代码

可复制

在上面这个脚本中，脚本的最后一行提示语显示的就是正确的“低于5”的血量，和脚本刚被触发时没有任何区别。

“定义”还有一个优势是：简洁，有时你可能会用到一些写的很长的变量，如果给这些长变量加上“定义”，你就可以使用简短的定义名称来代替那些冗长的变量，让整个脚本看起来更简洁。

短期存储？

回到本章节内容开头，我们说“定义”是短期存储，那所谓的“短期”到底是多短？

实际上，“定义”只在本队列脚本（queue）中生效，如果本队列已经执行完了，定义也就完成了它的使命（你可以在接下来的 “队列”有关教程中学到更多）

也就是说，当一个脚本开始运行，其中包含的定义会各自开始发挥功能，一个事件中的定义是不会在另一个事件中生效的。

以下是一个例子，来让你知道什么情况下定义无法生效。

反面例子

cant_go_between_scripts:
type: world
events:
after player breaks iron_ore:
- define health <player.health>
after player breaks stone:
- narrate "你现在有 <[health]> 血量"

复制代码

反面例子

上面的例子里定义无法生效，因为定义和调用定义的脚本并不在同一事件下。

反面例子

no_queue_persistence:
type: world
events:
after player breaks iron_ore:
- narrate "你现在有 <[next_health]> 血量"
- define next_health <player.health>

复制代码

反面例子

上面的例子里定义也是无效的，首先，当玩家首次挖掘铁矿石时，定义并没有写在第一行，因此不会第一个运行，此外哪怕玩家已经多次触发此脚本，定义照样还是无效的，因为本次事件触发中的定义只在本次事件中生效，并不会在下一次触发中生效。

拓展来说，不仅仅是触发型（World）脚本，你每次运行任务型（Task）脚本，其中的定义都是相互独立的，你可以在接下来的教程中学到更多。

在下一个章节中，你将会接触到“长期存储”。

修改定义

如果你想修改一个你已经设置好的定义，实际上你可以再用一遍define指令，比如这个例子：

可复制

def_sample:
type: task
script:
- define current <player.health>
- define goal 1
- if <player.inventory.contains.scriptname[治疗法杖]>:
- define goal 20
- narrate "你当前的血量是 <[current]>血，接下来我将把你治疗成 <[current].add[<[goal]>]>血"
- heal <[goal]>

复制代码

可复制

这个指令会治疗玩家1血，但假如玩家手中的物品名字叫“治疗法杖”，则治疗20血，在这个脚本中，使用新的define指令将同一个定义重新赋值，这样写是有效的。

但是，能不能用某些方法直接对定义的内容进行修改呢？例如，直接给define已经定义的数值加上1，我们可以使用变量来实现，比如 - define mydef <[mydef].add[1]>

此外，我们还有稍微简洁一点的方法来实现定义修改，这种方法叫做：数据操作符（Data Actions）

数据操作符怎么个操作法？
数据操作符写起来非常简单，对于之前提供的例子，若我们使用数据操作符而非变量，写起来是这样的- define mydef:++ 是不是简洁多了？

数据操作符还有以下用法

++ 增加数值（加1），例如- define mydef:++
-- 减少数值（减1），例如- define mydef:--
! 清除数值（移除定义），例如- define mydef:!

你也可以使用数据操作符来增减具体数值，例如，你想给定义的数据加3，你可以写成- define mydef:+:3

数据操作符还有别的类似这样的用法：

+ 加具体数值，比如- define mydef:+:3
- 减具体数值，比如- define mydef:-:3
* 乘具体数值，比如- define mydef:*:3
/ 除具体数值，比如- define mydef:/:3

定义的内容可以是一个列表型的数据，如果内容是一个列表数据，使用数据操作符可以方便地修改列表内容。

-> 给列表中新增一个数据，例如: - define mydef:->:new_value
<- 从列表中移除一个数据，例如: - define mydef:<-:new_value
| 将一个新列表插入旧列表，例如: - define mydef:|:a|b|c

为了让你真正学会以上这些数据操作符的用法，不妨写一个Task脚本并将下面的例子粘贴进去，使用上方所有种类的数据操作符，来看看输出的结果有什么变化。

需完善

data_actions_test:
type: task
script:
- define mydef 3
# 请将不同的数据操作符用于下面这行指令中，来看看输出内容有什么变化。
- define mydef:++
- narrate "mydef 现在变成了 <[mydef]>"

复制代码

需完善

如果你运行上面的脚本，输出的内容将会是“mydef 现在变成了 4”，这说明数字3被加上了新数字，变成了数字4，如果你尝试了别的数据操作符，你会发现输出的值会跟着有了新变化。

对于列表型的数据，请把上方脚本第一行改为 - define mydef <list[old_value|some_other_value]> 并继续你的测试。

创建定义的其它方法

相关的参考文档

长期存储——标签（flags）

原文链接

在上一章节的教程中我们学到了短期存储——定义的相关知识，在本章节中你将学到新知识：标签（flags）

（译者注：本篇内容中objects官方应该翻译为“对象”，但是译者觉得翻译为“依附物”更贴切。）

什么是标签？

标签的基本用法

在我们介绍一大堆复杂教程之前，不妨用一用我们的老朋友：/ex 指令！

进入你的Minecraft服务器，并输入这个指令

/ex flag server greetable:World

复制代码

执行了这个指令之后，你就以server为依附物，创建了一个名叫greetable的标签，其标签内容是World
让我们试试使用以下这个标签，请输入：

/ex narrate "Hello, <server.flag[greetable]>!"

复制代码

如果一切运行顺利，你将会看到如下内容输出：

标签和依附物（Objects）

标签必须和依附物相挂钩，在上面的例子中，我们使用了server作为依附物，server依附物比较特殊，毕竟“server”（服务器）是不会变化的。因此依附于server的标签无论何时何地都可以随意使用。

但是标签更多情况下依附的是某个玩家，如果一个标签依附于一个玩家，这表明只有这个玩家有这个标签，要是别的玩家想要这个标签，只能把flag脚本再用一次来重新设置。

给玩家设置标签相当简单，跟给server设置标签一样，你只需要把依附物设置为某个具体玩家，而非server，即可。

不妨试试这个指令：

/ex flag <player> status:learning

复制代码

然后再输入这个试试：

/ex narrate "<player.name> is <player.flag[status]> Denizen!"

复制代码

你会看到如下内容：

如果别的玩家在没有使用/ex flag设置标签的前提下使用上面的/ex narrate指令——它会直接报错，因为只有你拥有名叫status的标签，别的玩家是没有的。

说了这么多，标签有啥用处？

上面的例子实际上已经讲得很明了，所以现在让我们用标签来写一些稍微实用一点的脚本。

可复制

ore_counter:
type: world
events:
after player breaks iron_ore:
- flag player ores_broken:++
- narrate "你已经挖了 <player.flag[ores_broken]> 个铁矿石！加油！"

复制代码

可复制

这个脚本会统计玩家当前已经挖掘了多少铁矿石，每个玩家都有单独的计数（此脚本中我们使用了“++”数据操作符，请参考上一章的 “定义” 部分）

你还可以使用数据操作符 ! 来移除一个标签，在上面的脚本例子中，使用指令/ex flag player ores_broken:! 就可以移除你当前铁矿石挖掘数量的标签，如果做完这一切之后重新开始挖掘铁矿石，你会发现计数重新变回了1（代表脚本开始重新计数了）

我有标签！你也有吗？

如果你想知道一个依附物是否拥有一个标签，解决办法很简单：has_flag，这玩意和flag看起来差不多，但它不会返回一个标签值，而是返回布尔值true或者false.

想使用has_flag，你可以把他写进指令，类似 - if <player.has_flag[ores_broken]>: 只要玩家挖掘了至少一个铁矿石就可以触发这个if指令。

正因为flag有“有”和“没有”两种状态，所以可以通过这种特性来做出某些“开关”的效果，请看例子：

需完善

toggler_task:
type: task
script:
- if <player.has_flag[my_first_toggle]>:
- flag player my_first_toggle:!
- narrate "开关已关闭"
- else:
- flag player my_first_toggle
- narrate "开关已开启"

复制代码

需完善

上方的例子中，如果我们执行了指令/ex run toggler_task，我们可以把my_first_toggle这个“开关”打开或者关闭，其原理就是添加标签和移除标签（上面的例子里，标签只有名字，其内容没有被赋予，这是允许的），并使用has_flag来检测玩家是否有标签。

当你学到后面的玩家指令部分时，你可以使用标签的特性来做出简单但强大的效果，比如使用指令操控某些“标签开关”，或者使用触发型脚本来检查玩家是否有某个标签，从而触发一些特殊效果。

标签是Denizen的核心

标签是Denizen的核心，也就是说标签被用在Denizen每个地方，来让使用Denizen更加容易。

例如，如果你想要实现：玩家只有拥有某个标签时才能触发某个事件，你可以使用 flagged: 事件开关，例如：

可复制

optional_ore_counter:
type: world
events:
after player breaks iron_ore flagged:ore_quest:
- flag player ores_broken:++
- narrate "你已经挖了 <player.flag[ores_broken]> 个铁矿石！加油！"

复制代码

可复制

这个就是刚刚的计数玩家挖掘铁矿石数量的脚本，但现在，这个脚本只有玩家拥有标签ore_quest才会运行。现在，除了简单的计数玩家挖矿数量以外，这个脚本还做出了类似任务一样的功能，玩家需要挖掘铁矿石才能继续任务。

Denizen提供了许多诸如此类的功能，除了适用于玩家的flagged: 以外，还有server_flagged: 和 location_flagged: 等等，这些标签开关均可以作为指令的参数（比如announce指令的to_flagged参数，可以使用像这样的变量 <server.online_players_flagged[flag_name]> 等等）如果你Denizen学的足够精，并且已经开始阅读参考文档，你会看到很多这种例子。

“永久”

标签过期

标签的一个常见用法是一个永久性的冷却计时器，可以用在某些任务中或者制作出每天按时自动运行一次的脚本等，以下是一个例子：

需完善

once_a_day:
type: task
script:
- if <player.has_flag[my_script_cooldown]>:
- narrate "你每天只能领取一次每日奖励，你需要再等待 <player.flag_expiration[my_script_cooldown].from_now.formatted>."
- stop
- flag player my_script_cooldown duration:1d
- narrate "这是你的每日奖励！"
- give diamond

复制代码

需完善

上面的脚本运行后，会给予玩家一个钻石，但是为了实现每天只能运行一次，可以将标签作为冷却计时器而使用。

在Task（任务型）指令中，这种写法也许没啥意义，在未来，如果你学Denizen学的足够精在之后的教程里你将可以把指令绑定在NPC上（需要Citizens）你就可以点击NPC来呼出每日签到菜单，让每日签到成为你服务器里的新机制。

你可能会看到标签系统的两个新机制在这里被使用。

首先，在flag指令中，包含了一个duration:1d 参数，字面意思上的意思就是：它能让这个flag标签的有效期只有1天。一旦标签过期，它就会直接消失，仿佛根本没有存在过一样。在这里面输入的参数是DurationTag类型的数据，可以被写成类似1d这样的写法，1d表示“1天”，5h表示“5小时”等等，这个数值决定的是标签什么时候会过期（通过当前时间加上有效期来算出过期时间）并将其存储于标签中。

另外，在narrate指令中，我们还用到了flag_expiration变量，这个变量顾名思义，返回的是标签何时过期，且返回值是一个TimeTag类型的变量。当我们使用变量TimeTag.from_now时，我们得到的是一个DurationTag数据类型的“时长”，也就是“从当前时间开始直到设置好的TimeTag时间为止的时长”（也就是说，一旦这个标签开始生效，这个时长一开始是1d，如果你再等个一小时以后，这个时长就变成了23h，以此类推）另外，变量DurationTag.formatted功能是把程序读取的时长文字转化为人类能读懂的简洁内容。

要注意的是虽然标签过期的时间你可以通过变量查询，但是标签过期这个“事件”你是不能监听的，Denizen中并不存在一个名叫flag expires的事件，如果你想搞明白为什么是这样，可以读一读标签系统机制

还要注意的是如果你想把标签过期时间设置的很短（比如小于1小时），建议使用ratelimit指令而非flag指令，比如 - ratelimit <player> 1h ，ratelimit指令相对于标签flag来说简单易用，但是一旦服务器重启，ratelimit的数据是无法保存的，而且ratelimit也无法像上面例子中一样显示诸如冷却时间一类的消息，这是ratelimit和flag的不同之处。

标签还有什么别的依附物？

你可以给标签设置各种各样的依附物！以下提供一些常用的：

服务器本身：以服务器本身作为依附物，可以形成一个全服性的标签，依附物名称为server
任意玩家：请使用PlayerTag数据作为依附物
任意Citizens的NPC：请使用NPCTag数据作为依附物
任意实体：请使用EntityTag数据作为依附物
任意方块位置：请使用LocationTag数据作为依附物
任意区块：请使用ChunkTag数据作为依附物
任意物品：物品稍微要麻烦一些，我们将在自定义物品页面详细说明
任意世界：请使用WorldTag数据作为依附物
任意被标记的区域：（“被标记”将在进阶篇教程中介绍）请使用CuboidTag, EllipsoidTag, 以及PolygonTag数据作为依附物
任意被标记的容器：（“被标记”将在进阶篇教程中介绍）请使用InventoryTag数据作为依附物

还有许许多多其它种类的依附物，只要是有其独特特征，可以被识别的东西，都可以作为依附物被加上标签。

对于玩家来说，如果使用了一个依附玩家的标签，但玩家实际上不在线，玩家的数据还是会被加载以让标签运行。

然而对于实体来说，如果一个实体依附物被系统删除（也就是其所待的区块被系统卸载）这种情况我们是无法加载这个实体的，因此这个实体依附的标签也不会工作。

对于方块来说，如果包含这个方块依附物的区块没有被加载，你可能必须先让区块加载才能让标签工作，如果你使用了flag指令，加载区块的工作将会是自动的，但你要是使用了包含标签的变量，那这种情况没法自动加载区块，你只能先手动使用chunkload指令来加载区块，再考虑让标签工作的问题。

想获得更多和标签-依附物相关的信息，请参考标签系统机制

进阶教程-标签与映射表

需要被限制的标签名称

更多存储内容

相关的参考文档

机制与属性（Mechanisms And Properties）

原文链接

什么是机制（Mechanisms）？

简单来说，机制就是一种可以修改某事物上单个数据值的方法，就好比一个小小的工人，在流水线上为庞大的工厂工作。
（译者注（临时）：Mechanisms翻译成“机制”我觉得并不是很合适，但我暂时没有找到更加合适的译名，反正意思传达到了就行）

以下是一个机制被使用的例子：

可复制

ultra_sword:
type: item
display name: Ultra Sword
material: diamond_sword
mechanisms:
unbreakable: true

复制代码

可复制

这个脚本中，物品型（item）脚本中包含了机制（mechanisms）设置项，并且拥有一个名称为unbreakable的机制，且其内容值为true，这就给这个物品添加了“无法破坏”的功能。

可复制

undead_golden_swordsman:
type: entity
entity_type: zombie
item_in_hand: golden_sword
item_in_offhand: golden_sword
health_data: 80/80

复制代码

可复制

这个实体型（entity）脚本创建了一只僵尸，并且其拥有item_in_hand 和 item_in_offhand 两个机制，这使得其双手都各拿了一把金剑，此外它生成时有80血，最大血量也是80，这使用的是health_data机制。

指令adjust

机制的可用之处很多很多，如果你需要调整一个机制的值，你可以使用指令adjust

例如，如果我们想写一个脚本，玩家右键点击一只羊，就可以改变其羊毛颜色：

可复制

random_sheep_colors:
type: world
events:
after player right clicks sheep with:stick:
- adjust <context.entity> color:<context.entity.allowed_colors.random>

复制代码

可复制

运行此指令之后，只要玩家使用木棍右击一只羊，羊就会改变为随机颜色。

Adjust指令可以用来修改机制，以及数据的种类（例如玩家、实体等等）但是某些情况下运用机制需要不同的方法。

指令adjustblock

Adjustblock指令是adjust指令的一个变种，它可以通过修改方块的material机制来修改方块种类（相关列表请参这里）

虽然adjustblock指令写起来比较长，但实际上它还是很有用的，举个例子，你可以使用下面的脚本让农作物方块快速长成熟

可复制

plant_grower:
type: world
events:
after player right clicks block with:stick:
- if <player.cursor_on.material.is_ageable>:
- adjustblock <player.cursor_on> age:<player.cursor_on.material.maximum_age>

复制代码

可复制

如何使用adjust修改物品

你可以使用adjust修改容器里的物品，可以通过指令inventory搭配adjust参数实现。

如果你想直接使用adjust修改玩家手持的一件物品，你可能会这样写：

反面例子

flint_fancifier_bad:
type: world
events:
after player right clicks block with:flint:
- adjust <player.item_in_hand> "display:Fancy Flint"
- adjust <player.item_in_Hand> "lore:Built with Denizen!"

复制代码

反面例子

然而，标签player.item_in_hand>返回的只是flint这个名字而已，没有具体说是哪一个flint物品，上面的脚本错误之处在于，它只是在尝试修改flint物品这个大概念，而非具体到玩家手持的这一件flint，如果你修改物品没有具体到是哪一件，那么修改是无法生效的。

所以，修改容器内物品的最常用方法是使用inventory指令搭配adjust参数，来把修改具体到某个物品上。

下面这个脚本写法是正确的，当玩家右击该物品可以真正修改此物品：

可复制

flint_fancifier:
type: world
events:
after player right clicks block with:flint:
- inventory adjust slot:<player.held_item_slot> "display:Fancy Flint"
- inventory adjust slot:<player.held_item_slot> "lore:Built with Denizen!"

复制代码

可复制

inventory adjust的功能就是“修改容器内物品”，因为你指定了玩家背包内某个具体物品（或者GUI菜单里某个具体的格子），因此inventory adjust指令是可以正常工作的。

With变量
.with变量可以方便地修改某物品上的机制，和inventory adjust指令不同的是，后者只能修改一个“真实存在”的物品，而.with可以修改虚拟的概念上的物品，修改其各项机制，最后可以使用某些指令来取回这件“虚拟物品”，来让虚拟物品变成真实的。
（译者注：想象一下制作RPG武器物品的流程）

例如：你可能不只是想给玩家手持的物品换个名字，你也许还想直接给玩家一件耐久全新的物品。

可复制

sword_duplicator:
type: world
events:
after player right clicks bedrock with:diamond_sword:
- ratelimit <player> 1h
- give "<player.item_in_hand.with[display=Your Free Duplicate Sword].with[durability=0]>"
- narrate "<&b>成功复制了一把剑！"

复制代码

可复制

上面的脚本里，如果玩家手持钻石剑点击基岩方块，会自动获得手中剑的复制品一个，而且耐久是满的，但每小时只能生效一次。

你可以看到在上面的例子中，with变量可以放在任意ItemTag类型数据后面，正因为被“with”之后的ItemTag数据还是ItemTag数据，所以你可以在后面跟无数个with，写成长长一行。

你需要注意对于MaterialTag数据也是有其相应的with的，其原理和物品修改一样，只不过对象是方块。

修改定义

Adjust指令还可以用来修改定义（definition）里存储的内容，并且直接将修改后的数据返回定义之中。

这个机制相对来说有点复杂，但是很有用，它允许使用if指令来首先选择哪个机制需要被更改，之后再进行修改操作。
比如下面的例子：

可复制

sword_duplicator:
type: world
events:
after player right clicks bedrock with:diamond_sword:
- ratelimit <player> 1h
- define sword <player.item_in_hand>
- adjust def:sword "display:Your Free Duplicate Sword"
- if <player.location.material.name> == lava:
- adjust def:sword "lore:<&c>Forged in lava."
- adjust def:sword durability:0
- give <[sword]>
- narrate "<&b>成功复制了一把剑！"

复制代码

可复制

这个例子和我们上面讲的用剑点击基岩获得复制品的脚本差不多，但是现在，只有玩家有胆量跳入岩浆，这个机制才会生效（在实际测试脚本时，你可以将一个#符号写在ratelimit脚本前面，这样你测试脚本就不需要真的等待那么久了）（译者注：就是把ratelimit那一行变成注释而已）

使用这个方法修改物品，优势在于更加简洁，可以一次修改多条机制。

属性（Properties）

“属性”是一个记录某个事物详细内容的系统，这个事物必须“没有特殊之处”才行。

一般来说，每个“属性”都包含一个变量和一个机制，变量会读取当前的数据值，而机制会赋予一个新数据值，属性还会与其它变量或者机制相关联，来让使用特性变得更加容易。请注意：尽管一个属性同时包含了一个变量和一个机制，但不是每个变量或机制都一定和一个属性挂钩。

属性一般会被用于Denizen插件对对象的描述，对象描述是针对任何对象的可重复的描述，并在其前面使用对象标记符标记（类似 i@这样的），这个机制一般只在插件内部数据记录中被用到，你一般只能在脚本的debug消息中找到它们。

物品属性
属性最长被用到的地方是物品上，在Denizen中，一个“物品”实际上就是物品本身加上一系列“属性”，例如，如果你在生存模式下使用一把刚刚合成的钻石剑攻击一个实体，你可以使用指令/ex narrate <player.item_in_hand> 来查看Denizen内部是怎么描述你手持的这把剑的属性的，你可能会看到其返回内容是i@diamond_sword[durability=1]，在这里，durability是物品的唯一属性，其值是1，也就是物品已经损失的耐久，多个物品属性是使用英文分号相隔开的，例如i@diamond_sword[durability=1;display_name=Skullbuster]（请记住，不要把写脚本时常用的英文逗号什么的用作分隔符，因为这些内容是交给Denizen内部处理的，不能把写脚本那一套带进插件内部）

再说一遍，物品=物品本身+属性，玩家背包内任何物品都遵循这个等式，任何物品的属性都是可以读取和修改的。

方块属性
方块（Materials）和物品一样，没有特殊之处，一个石头方块就是一块石头待在世界某个坐标而已，而一个小麦农作物方块可能稍微复杂一些，它除了位置属性以外还有一个名叫age的属性，如同你在上文adjustblock中的例子中看到的一样，使用age这个机制可以允许你更改方块的属性，当你从世界坐标中读取一个方块时，将会返回所有与之关联的属性，例如，检查一个篝火方块是否会往外冒烟，或者和红石状态有关的复杂属性，甚至是一个蘑菇块方块六个面分别是什么情况。

带属性的方块，可以使用变量<player.cursor_on.material>来指代，其将会返回类似m@wheat[age=7]的内容（一个完全长成熟的小麦作物方块），在这个例子里，小麦的age属性是7。

实体属性
实体当然也有属性！实体属性和方块属性一样可以被读取或者编辑，你可以使用变量<EntityTag.describe>来显示当前实体拥有的所有属性列表，例如，当玩家鼠标准星对准一直染过色的羊时，执行以下指令/ex narrate <player.target.describe> 可有如下内容输出：

e@sheep[age=0;has_ai=true;is_aware=true;color=orange;equipment=li@i@air|i@air|i@air|i@air|;health_data=8/8;speed=0.23]

复制代码

你可以看到，这只羊身上所有的属性都被Denizen记录了下来，并按照“EntityTag实体+全部属性”的格式输出了出来，每个属性都是用英文分号区分开的，存储在每个属性中的数据根据属性的情况而变化。

这些属性可以使用adjust指令修改，并使用相应变量来读取，对于属性color来说，我们假设这个EntityTag实体有一个机制还有一个变量都名叫color

/ex narrate "The <player.target.entity_type> you're looking at is colored <player.target.color>"

执行以上指令，你会看到以下输出

The SHEEP you're looking at is colored orange.

在脚本中运用属性
你可以直接在脚本中使用属性，只要你有一个拥有少量属性的对象，你就可以直接将其属性敲进脚本中，而不需要从头写一个新脚本来描述这个对象。

请看下面的例子：

可复制

sand_cannon:
type: world
events:
after player right clicks air with:sand:
- shoot falling_block[fallingblock_type=sand] origin:<player> speed:1

复制代码

可复制

上方例子中的脚本，当玩家手持沙子方块右键点击空气时，发射出去一个掉落方块实体，需要注意必须使用属性的格式来描述这个“掉落方块实体”。

可复制

pumpkin_meloner:
type: world
events:
on player right clicks pumpkin_stem with:golden_hoe:
- modifyblock <context.location> melon_stem[age=7]

复制代码

可复制

上方例子中的脚本，当玩家使用金锄头点击一个南瓜梗方块的时候，会将其转变为西瓜梗，同理，“西瓜梗”这个方块也需要用属性的相应格式来写。

需要注意的是，如果你要使用包含数据值的变量，这种一行一行写的属性是不能用的，这种情况下请使用我们之前讲过的with变量。

相关的参考文档

再来一遍——循环（loops）

原文链接

什么叫“再来一遍”（loops）

直到目前，我们所教学的脚本，运行起来都是按部就班地从头运行到尾，当脚本被触发，排列好的指令会一条一条被执行，如果你使用了if指令的话跳行运行也能做得到。那么，假如我想把刚刚运行的指令再运行一遍该怎么办？你有以下方法：最直白而且最傻的方法是：把原脚本再复制一遍。如果你只需要重复唯一的一行脚本，又或者你只需要它运行唯独这两遍的话这个法子勉勉强强还是讲的过去的。

幸运的是你不需要使用这么蠢的法子就可以做到，Denizen提供了三种不同的循环执行（loop）指令来让你可以把一组指令再运行一遍。

指令repeat： 把一组脚本指令重复运行一定次数。
指令foreach： 基于一个列表进行指令重复，列表中每个对象都会被安排到一次。
指令while： 当满足一定条件时才开始重复执行指令，和指令 if 类似，但它会一遍一遍执行下去直到条件不符合。

指令repeat

循环运行最常见的使用之处就是把一组指令重复运行第二遍，这也是指令repeat最常被用到之处。

所谓指令repeat，顾名思义，就是把一组脚本指令“重复”运行几次。

指令repeat的基本写法是这样的：

需完善

- repeat (重复的次数):
- (需要被重复执行的脚本内容)

复制代码

需完善

这个写法看起来和指令if的写法类似，你需要在指令repeat那一行末尾加一个冒号: 来让Denizen明白下面的内容就是你想要重复执行的脚本内容。

以下是一个具体的使用范例：

可复制

my_lightning_task:
type: task
script:
- repeat 5:
- strike <player.location>
- narrate "你被雷击中了！"
- wait 1s
- narrate "雷击结束了，已经安全了"

复制代码

可复制

不妨将这个脚本加载进服务器，并使用指令 /ex run my_lightning_task 亲自试一试。

雷击的脚本会被重复执行5遍，玩家会被雷击中并看到提示语“你被雷击中了！”，另外还包含一个wait指令，这个代表两次重复之间暂停的间隔（在这个范例里是1秒），这个暂停还是很重要的，有暂停的话被重复的指令就不会瞬间全部执行完毕。在上面的范例中，如果你把指令wait这个暂停去掉再运行，5次重复雷击会瞬间全部执行，看起来就好像只执行了1次。

当所有重复执行完毕，脚本会继续往下运行，玩家会看到提示语“雷击结束了，已经安全了”。

如果我想让玩家知道自己被雷击了几次，该怎么办？你当然可以使用“定义”（definition）来记录玩家被雷击的次数，但是指令repeat已经提供了计数功能，只需要加一个 as: 参数，类似下面这样写：

可复制

my_lightning_task:
type: task
script:
- repeat 5 as:count:
- strike <player.location>
- narrate "你被雷击中了！这是第 <[count]> 次！"
- wait 1s
- narrate "雷击结束了，已经安全了"

复制代码

可复制

当脚本被触发，现在它的提示语会变成“你被雷击中了！这是第1次！” “你被雷击中了！这是第2次！”……等等，一直到第5次。

指令foreach

上文中介绍的指令repeat用起来很方便，但是有时你可能会想要基于一个列表来进行重复，给列表里每个对象都重复执行到一遍，该怎么做呢？

假设我想执行一个脚本，输出玩家身边所有的牛的位置，假设我们使用上文介绍到的指令repeat，写法是这样的：

反面例子

my_cow_task:
type: task
script:
- define cows <player.location.find_entities[cow].within[30]>
- repeat <[cows].size> as:index:
- define cow <[cows].get[<[index]>]>
- narrate "在距离你 <[cow].location.distance[<player.location>].round> 格远的位置发现了牛！"
- playeffect effect:fireworks_spark at:<[cow].location> visibility:50 quantity:100 data:0 offset:3

复制代码

反面例子

其实使用foreach来处理这个操作更为方便，foreach的含义是“对于每个列表中的对象来说...”，它会基于列表来把脚本指令对列表中每个对象都执行一次。

foreach的写法和repeat差不多，以下是写法：

需完善

- foreach (列表) as:(每个对象的定义变量):
- (需要被重复执行的脚本内容)

复制代码

需完善

上面那个脚本，当我们使用到指令foreach以后：

可复制

my_cow_task:
type: task
script:
- foreach <player.location.find_entities[cow].within[30]> as:cow:
- narrate "在距离你 <[cow].location.distance[<player.location>].round> 格远的位置发现了牛！"
- playeffect effect:fireworks_spark at:<[cow].location> visibility:50 quantity:100 data:0 offset:3

复制代码

可复制

想试试这个脚本，不妨在游戏里找个身边有几头牛的位置待着，并执行 /ex run my_cow_task 试试。

是不是好多了？显而易见地，我们不需要定义每一头被执行到的牛，foreach帮我们搞定了一切。

另外，指令foreach有一个内置的功能：<[loop_index]>，来记录下脚本已经被执行了几次，使用例如下：

可复制

my_cow_task:
type: task
script:
- foreach <player.location.find_entities[cow].within[30]> as:cow:
- narrate "<[loop_index]> - 在距离你 <[cow].location.distance[<player.location>].round> 格远的位置发现了牛！"
- playeffect effect:fireworks_spark at:<[cow].location> visibility:50 quantity:100 data:0 offset:3

复制代码

可复制

运行这个脚本，输出的文字消息前面会加个“1-” “2-” 等等。

指令while

有时，你不太确定一个脚本到底要重复几次，但是你知道什么时候该停，那么你可以试试指令while，它和指令if类似，只要条件符合，它会一遍又一遍地重复执行指令，直到条件不符合。

需完善

- while (条件):
- (需要被重复执行的脚本内容)

复制代码

需完善

写法和指令 if 的写法类似，如果你已经忘了 if 是怎么写的请参考这里。（不会吧？）

现在我们来看一个例子：

可复制

my_move_task:
type: task
script:
- define location <player.location>
- while <player.is_online> && <[location].distance[<player.location>]> < 3:
- narrate "别站在这里！快走开！"
- wait 2s

复制代码

可复制

不妨试试用指令 /ex run my_move_task 来尝试一下这个脚本，一旦被运行，这个脚本会不停地让你赶紧走开，直到你移动到原来站的位置3格以外。

和指令repeat类似，这个脚本中也包含了指令wait来让脚本运行暂停，指令wait在指令repeat中也许可用可不用，但是在指令while里 一定要用 ，如果不用wait，指令while会不停地检查条件是否符合并不停地运行（进入死循环），可能会导致服务器卡顿，甚至崩服。

需要谨记：指令while用起来一定要谨慎，最好是不要用，因为很容易就会造成 死循环 （infinite loop），而且一旦进入死循环，将没有可以停下它的办法，除非你重启服务器。

另外，一些大聪明用户会写出 while true 这样的脚本来让脚本永远循环运行——这不是一个好方法，你可以使用 delta time事件来实现永远运行。

停止循环

很多时候，你只想让脚本循环个几次就停下，但你不想让整个脚本都终止（指令stop会使整个脚本都终止），那么你可以使用repeat/foreach/while stop 来让循环在特定的条件下终止。

例如，在前文提到的repeat那个例子里，假如我们想要实现当玩家血量低于5时就停止雷击循环，我们可以这样写：

可复制

my_lightning_task:
type: task
script:
- repeat 5 as:count:
- strike <player.location>
- narrate "你被雷击中了！这是第 <[count]> 次！"
- if <player.health> < 5:
- repeat stop
- wait 1s
- narrate "雷击结束了，已经安全了"

复制代码

可复制

我们使用了repeat stop之后，只有repeat这个循环停下了，但整个脚本没有停下，后面的narrate还是继续执行着。

停止循环还可以用在foreach中，在前文提到的foreach那个脚本例子中，假如我们想要实现当扫描到幼年牛时就停下循环，我们可以这样写：

可复制

my_cow_task:
type: task
script:
- foreach <player.location.find_entities[cow].within[30]> as:cow:
- narrate "在距离你 <[cow].location.distance[<player.location>].round> 格远的位置发现了牛！"
- playeffect effect:fireworks_spark at:<[cow].location> visibility:50 quantity:100 data:0 offset:3
- if <[cow].is_baby>:
- narrate "哦！我们发现了一只小牛！"
- foreach stop

复制代码

可复制

下个循环

有时，你会想要跳过某一轮循环，但并不终止整个循环，你可以使用repeat/foreach/while next 来跳过这一轮循环，进入下一循环。

还用我们之前那个foreach的例子，假如我们想在输出牛的位置时跳过所有幼年牛，只输出成年牛的位置，当然用指令if 也是可以做到的，如下：（译者注：在下面的脚本中作者使用了if !<cow.is_baby> 来首先判断扫描到的牛是否符合“不是幼年”，随后再进行输出）

可复制

my_cow_task:
type: task
script:
- foreach <player.location.find_entities[cow].within[30]> as:cow:
- if !<[cow].is_baby>:
- narrate "<[loop_index]> - 在距离你 <[cow].location.distance[<player.location>].round> 格远的位置发现了牛！"
- playeffect effect:fireworks_spark at:<[cow].location> visibility:50 quantity:100 data:0 offset:3

复制代码

可复制

但假如我们使用next：（译者注：在下面的脚本中作者使用了if <cow.is_baby>来首先判断扫描到的牛是否符合“是幼年”，若符合，则使用next跳过这一循环，继续下一次扫描）

可复制

my_cow_task:
type: task
script:
- foreach <player.location.find_entities[cow].within[30]> as:cow:
- if <[cow].is_baby>:
- foreach next
- narrate "在距离你 <[cow].location.distance[<player.location>].round> 格远的位置发现了牛！"
- playeffect effect:fireworks_spark at:<[cow].location> visibility:50 quantity:100 data:0 offset:3

复制代码

可复制

~~简单的范例~~ （内容过期）

（译者注：这一部分是作者在尚未写完此部分脚本时临时写的一些脚本范例，现作者已写完此部分，原文中已删去这一小节）

以下提供一些loops在实际脚本运用中的写法：

可复制

my_counter_task:
type: task
script:
- repeat 10 as:num:
- narrate "让我们来数数吧！ <[num]>"

复制代码

可复制

在游戏中使用指令/ex run my_counter_task，它会开始从1数到10。

可复制

my_cow_task:
type: task
script:
- foreach <player.location.find_entities[cow].within[30]> as:cow:
- narrate "在距离你 <[cow].location.distance[<player.location>].round> 格位置发现一头牛！"
- playeffect effect:fireworks_spark at:<[cow].location> visibility:50 quantity:100 data:0 offset:3

复制代码

可复制

当你在游戏里站在一群牛附近并使用指令/ex run my_cow_task，它会输出你附近所有牛距离你的距离。

可复制

my_move_task:
type: task
script:
- define location <player.location>
- while <player.is_online> && <[location].distance[<player.location>]> < 3:
- narrate "别站在这里！快走开！"
- wait 2s

复制代码

可复制

在游戏中使用指令/ex run my_move_task，它会不停催促你走开，直到你移开初始位置超过3格。

相关的参考文档

玩家指令

原文链接

玩家指令（Player Commands）是什么？

指令基本结构

所有的自定义指令都有一样的基本结构，其基本结构的写法和你之前学到的任务型脚本（Task脚本）差不多，但有更多细节：

需完善

ScriptContainerName:
type: command
name: [指令名称]
description: [简短的指令描述]
usage: [指令用法描述]
permission: [指令涉及的权限]
script:
- (指令涉及的脚本内容)

复制代码

需完善

在脚本编辑器中，你可以输入command并使用tab补全来呼出指令基本结构的模板。

这种脚本的种类为command，你需要提供指令的名称，也就是玩家在聊天栏里输入以执行指令的内容（指令的名称不包含斜杠/）。

同时你还要提供指令的描述和用法，当玩家输入/help 时这些内容将会显示出来。

你还需要指定一个允许运行此指令的权限，权限写什么都可以，如果你使用的是测试服，那么你估计已经是OP了，指令的权限限制并不会限制到你。

把这些细节都完善以后，让我们看看一个新指令要怎么写：

可复制

warp_command:
type: command
name: warp
description: 将你传送至预设的地标
usage: /warp
permission: dscript.warp
script:
- narrate "<&[base]>已将您传送至地标！"

复制代码

可复制

现在你就可以在游戏内执行这个指令/warp 试试看，它会输出一条消息，其实这条指令能做到的远远不止这些，我们只是通过这个简单的例子来展示自定义指令的基本功能。（译者注：若你的服务器内安装了Essentials等插件，这些插件可能自带了/warp指令，从而本插件提供的warp指令执行时可能会受到干扰）

玩家指令参数

一个指令肯定不止只有一段（除非是一些基础指令），指令中可能会被添加更多细节参数，在上面的指令warp例子中，我们尝试创建一个地标，并可以通过指令传送至这个地标。假如我想使用指令/warp create spawn 来制作一个名为spawn的地标，这个指令中的“create”和“spawn”就是我们所谓的“指令参数”。

和事件类似，一个指令型脚本也包含了环境变量（Context Tags），其可以存储一些关于玩家如何使用此指令的相关信息，其中一个环境变量为<context.args>，这个环境变量包含了玩家输入指令中所有的指令参数。

让我们给之前的warp指令加点新功能，我们可以给新地标命名，也可以传送至这个地标，请看写法：

黄色框？

warp_command:
type: command
name: warp
description: 将你传送至预设的地标
usage: /warp create|goto [warp-name]
permission: dscript.warp
script:
- choose <context.args.first>:
- case create:
- define name <context.args.get[2]>
- flag server warps.<[name]>:<player.location>
- narrate "<&[base]>已创建地标 <&[emphasis]><[name]><&[base]>!"
- case goto:
- define name <context.args.get[2]>
- teleport <player> <server.flag[warps.<[name]>]>
- narrate "<&[base]>已传送至 <&[emphasis]><[name]><&[base]>!"

复制代码

黄色框？

（译者注：这篇脚本范例原文中使用黄色框出，黄色框不存在于之前解释的红蓝绿框含义中，意味不明，也许是笔误。）

先使用指令/warp create test，然后移开一段距离，再使用指令/warp goto test，你会发现你瞬间被传送回了之前站的位置。

要分析这个脚本中发生了什么：

我们检查了输入指令中的第一个参数，
如果第一个参数是create，创建一个标签（flag）且这个标签和输入的第二个参数挂钩，
如果第一个参数是goto，将玩家传送至标签里存储的位置（和输入的第二个参数挂钩）

你也许会注意到如果玩家输入了除了create和goto以外的参数，脚本会崩溃，别急，后面我们会提到如何处理。

请注意我们也一并更新了指令型脚本的usage（指令用法）部分，当然这个更不更新和脚本的执行结果无关，但还是随时保持信息更新比较好。

你应该也注意到指令narrate中包含了不同的颜色代码，来让文本输出的关键内容看起来比较显眼，合理利用颜色代码可以让你的脚本更加用户友好。

处理别的玩家

大部分指令的共同点在于对“别的玩家”进行操作，你也许需要在指令中输入别的玩家的名称，比如上面的warp指令，也许我们想实现通过指令实现，不仅仅把自己而且还能把别的玩家传送至地标的功能。

实现这个功能的指令看起来应该是这样的： /warp player <玩家名> <地标名> 能够实现这个指令的脚本如下所示：

黄色框？

warp_command:
type: command
name: warp
description: 将玩家传送至地标
usage: /warp create [warp-name] | goto [warp-name] | player [player] [warp-name]
permission: dscript.warp
script:
- choose <context.args.first>:
- case create:
- define name <context.args.get[2]>
- flag server warps.<[name]>:<player.location>
- narrate "<&[base]>已创建地标 <&[emphasis]><[name]><&[base]>!"
- case goto:
- define name <context.args.get[2]>
- teleport <player> <server.flag[warps.<[name]>]>
- narrate "<&[base]>已传送至 <&[emphasis]><[name]><&[base]>!"
- case player:
- define playerName <context.args.get[2]>
- define destination <context.args.get[3]>
- define playerToWarp <server.match_player[<[playerName]>]>
- teleport <[playerToWarp]> <server.flag[warps.<[destination]>]>
- narrate "<&[base]>已将玩家 <&[emphasis]><[playerToWarp].name> <&[base]>传送至 <&[emphasis]><[destination]><&[base]>!"

复制代码

黄色框？

不妨利用你服务器里的其他玩家试试这个指令，如果你是在本地开服，那么也可以试试输入自己的玩家名试试。

请注意，在传送脚本中我们并没有直接调用玩家名，我们使用的是变量<server.match_player[]>来找到所需的玩家，请注意这点很重要，尽管Denizen里有一些很强力的转换功能可以做到仅仅提供名字就可以找到对应的对象（针对物品），但这个机制不适用于玩家，实际上，<server.match_player[]>提供了模糊搜索的功能，例如，某位玩家叫bobby，那么实际上变量<server.match_player[bob]> 也是管用的（尽管服务器里并没有玩家叫bob）

添加Tab补全

Tab补全是Minecraft提供的一种指令自动补全机制，增加指令Tab补全可以增强你的自定义指令功能，你可以这样写：

需完善

warp_command:
type: command
name: warp
description: 将玩家传送至地标
usage: /warp create [warp-name] | goto [warp-name] | player [player] [warp-name]
permission: dscript.warp
tab completions:
1: create|goto|player
2: <context.args.first.equals[goto].if_true[<server.flag[warps].keys>].if_false[]>
3: <context.args.first.equals[player].if_true[<server.flag[warps].keys>].if_false[]>
script:
#...下面的脚本内容没有变化

复制代码

需完善

当你尝试在聊天框里输入这个指令时，Minecraft的Tab指令补全列表会自动呼出。

当玩家尝试输入第一个参数时，Tab补全列表会自动展示create、goto和player三个备选参数，其中当前被选中的一个将会高亮显示。

当玩家尝试输入第二个参数时，若第一个参数是goto，Tab列表会尝试获得所有存储在flag中的地标列表，若无，则什么都不会显示，同样地，第三个参数也是一样（如果第一个参数是player的话）

需要谨记，Tab补全的功能只是给出指令建议，对指令和脚本的执行不会有任何作用，想要运行脚本，指令的余下内容你只能自己输入。

你也许会注意到当玩家使用指令/warp player时，尝试Tab补全第二个参数将会导致Tab列表展示的很长，这是一个征象——这个指令开始变得混乱且不易用了，你也许应该把这个指令拆分成好几个功能分开的指令。例如，使用/createwarp <地标名> 来创建地标，使用/warpto <地标名> [玩家名] 来将玩家传送至地标，等等。

不要信任玩家

（译者注：这一段建议和秋风残叶的搬运贴中的教程2.2-1一起阅读）

这些指令看起来很好用——当且仅当玩家们合理使用它们的时候，但实际上，这种好事不是必然的，这里需要告诫大家一条箴言： 永远不要信任玩家。 不要以为你觉得玩家该做什么，玩家就会乖乖地去按照你的计划去做。

很多玩家总是尝试在你的服务器里作弊，而还有一些玩家会在指令使用上犯错误，请记住人无完人，在创建玩家指令时你必须为应对这些情况做好万全准备。

对于我们上文中介绍的warp地标指令，以下是实际执行中可能会产生的问题：

如果玩家尝试传送到一个不存在的地标该怎么办？
如果玩家尝试创建一个已经存在的地标该怎么办？
如果玩家输入了过少参数该怎么办？
如果玩家输入了太多参数该怎么办？
如果玩家输入了非法参数该怎么办？
如果指定的传送玩家不存在或不在线，该怎么办？
如果地标名中有一些特殊符号，类似英文句号.或者空格，该怎么办？

有些问题可能不太严重（例如输入太多参数），但有些问题会导致脚本运行出现错误（例如地标不存在）或者把一些已经存在的东西覆盖掉（例如尝试创建已存在的地标），正因如此，你需要把玩家可能在指令执行中犯的错误全部找出来，并为此做好准备。

让我们看看，一个为应对错误做好万全准备的指令型脚本该怎么写：

可复制

warp_command:
type: command
name: warp
description: 将玩家传送至地标
usage: /warp create [warp-name] | goto [warp-name] | player [player] [warp-name]
permission: dscript.warp
tab completions:
1: create|goto|player
2: <context.args.first.equals[goto].if_true[<server.flag[warps].keys.parse[unescaped].if_null[]>].if_false[]>
3: <context.args.first.equals[player].if_true[<server.flag[warps].keys.parse[unescaped].if_null[]>].if_false[]>
script:
# 如果玩家输入的指令不包含任何参数，可能是因为玩家不知道这个指令怎么用
# 所以你需要在内容输出中告诉他们
- if <context.args.is_empty>:
- narrate "<&[error]>/warp create [warp-name]"
- narrate "<&[error]>/warp goto [warp-name]"
- narrate "<&[error]>/warp player [player] [warp-name]"
- stop
- choose <context.args.first>:
- case create:
# 指令参数计数
- if <context.args.size> < 2:
- narrate "<&[error]>请指定地标的名称"
- stop
- else if <context.args.size> > 2:
- narrate "<&[error]>指令参数过多"
- stop
- define name <context.args.get[2]>
# 不要让玩家创建已经存在的地标
# 使用 ".escaped" 来防止玩家通过命名中的特殊符号造成问题
- if <server.has_flag[warps.<[name].escaped>]>:
- narrate "<&[error]>此地标已存在： <&[emphasis]><[name]><&[error]>!"
- stop
# 你可能还需要一个 'warp delete [name]' 来删除地标
- flag server warps.<[name].escaped>:<player.location>
- narrate "<&[base]>已创建地标 <&[emphasis]><[name]><&[base]>!"
- case goto:
- if <context.args.size> < 2:
- narrate "<&[error]>请指定地标名称"
- stop
- else if <context.args.size> > 2:
- narrate "<&[error]>指令参数过多"
- stop
- define name <context.args.get[2]>
# 必须确认地标是已经存在的
- if !<server.has_flag[warps.<[name].escaped>]>:
- narrate "<&[error]>地标 <&[emphasis]><[name]> <&[error]> 不存在"
- stop
- teleport <player> <server.flag[warps.<[name].escaped>]>
- narrate "<&[base]>已传送至 <&[emphasis]><[name]><&[base]>!"
- case player:
- if <context.args.size> < 3:
- narrate "<&[error]>你需要指定玩家名和地标名"
- stop
- else if <context.args.size> > 3:
- narrate "<&[error]>指令参数过多"
- stop
- define playerName <context.args.get[2]>
- define destination <context.args.get[3]>
# 检测玩家是否输入了非法玩家名
- define playerToWarp <server.match_player[<[playerName]>].if_null[null]>
- if <[playerToWarp]> == null:
- narrate "<&[error]>玩家不存在 '<&[emphasis]><[playerName]><&[error]>'!"
- stop
- if !<server.has_flag[warps.<[destination].escaped>]>:
- narrate "<&[error]>地标 <&[emphasis]><[destination]> <&[error]> 不存在"
- stop
- teleport <[playerToWarp]> <server.flag[warps.<[destination].escaped>]>
- narrate "<&[base]>已将玩家 <&[emphasis]><[playerToWarp].name> <&[base]>传送至地标 <&[emphasis]><[destination]><&[base]>!"
# 若第一个参数非法，输出提示消息
- default:
- narrate "<&[error]>未知参数 '<&[emphasis]><context.args.first><&[error]>'!"

复制代码

可复制

想测试这个脚本，不妨试试胡乱输入一些指令参数，来看看脚本是如何输出内容并阻止你的。

以下是脚本中用到安全检查手段：

检查指令参数列表，以确认玩家没有输入过多或过少参数
检查服务器（server）是否含有/不含有某一标签（flag）以避免出现问题
当错误产生时，立刻终止脚本，并输出警告信息来让玩家知道哪里错了
给Tab补全增加一个空值检查，这样的话即使不存在地标，脚本运行时也不会报错
给match_player增加一个空值检查，以确认要找的玩家是否存在
添加 .escaped参数来让输入的名称中不含有会影响脚本指令运行的特殊符号（比如英文句号）

即使这些检查会使脚本的容量大大增加，但对于玩家来说这些是必要的，你可以在常见错误章节中查看更多内容。

让我看看你的权限

除了确认玩家有没有按部就班地按照你的规划输入指令参数之外，你还要确认玩家是否有权限执行这个指令，原版Minecraft是不存在权限系统的（玩家之上就是OP）但我们有很多权限插件可以帮我们进行权限管理，如果你已经正在开服了，相信你的服里肯定有一款权限插件。

权限检查的总闸就是检查玩家到底能不能使用这个指令，在上文中的所有例子中，我们使用 permission: dscript.warp 来处理，正因为有了这条脚本，那些既不是OP又没有权限dscript.warp的玩家将无法使用这些指令，我们建议给你创建的每一条自定义指令都加上权限限制，即使你本来的目的是把它给全部玩家使用。

权限的名称写什么都可以，你是在创建属于你自己的权限，因此权限名字需要你自己来指定。

我们建议的权限名称格式为 dscript.<指令名> 或者 <脚本名>.<指令名> ，或者类似的名称，毕竟你可能想要权限名称和脚本/指令名称看起来是关联的。

有时，你可能需要更多权限，其管理的不仅仅是使用指令这么简单，比如我们想让所有玩家都可以使用地标指令进行传送，但不允许他们创建新地标或者强制其他玩家进行传送，我们需要在脚本中加入如下权限检查：

可复制

warp_command:
type: command
name: warp
description: 将玩家传送至地标
usage: /warp create [warp-name] | goto [warp-name] | player [player] [warp-name]
permission: dscript.warp
tab completions:
1: create|goto|player
2: <context.args.first.equals[goto].if_true[<server.flag[warps].keys.parse[unescaped].if_null[]>].if_false[]>
3: <context.args.first.equals[player].if_true[<server.flag[warps].keys.parse[unescaped].if_null[]>].if_false[]>
script:
- if <context.args.is_empty>:
- narrate "<&[error]>/warp create [warp-name]"
- narrate "<&[error]>/warp goto [warp-name]"
- narrate "<&[error]>/warp player [player] [warp-name]"
- stop
- choose <context.args.first>:
- case create:
#+ 需要指定一个地标创建权限
- if !<player.has_permission[dscript.warp.create]>:
- narrate "<&[error]>你没有权限使用这个"
- stop
- if <context.args.size> < 2:
- narrate "<&[error]>你需要指定地标名称"
- stop
- else if <context.args.size> > 2:
- narrate "<&[error]>指令参数过多"
- stop
- define name <context.args.get[2]>
- if <server.has_flag[warps.<[name].escaped>]>:
- narrate "<&[error]>此地标已存在 <&[emphasis]><[name]><&[error]>!"
- stop
- flag server warps.<[name].escaped>:<player.location>
- narrate "<&[base]>已创建地标 <&[emphasis]><[name]><&[base]>!"
- case goto:
- if <context.args.size> < 2:
- narrate "<&[error]>你需要指定地标名称"
- stop
- else if <context.args.size> > 2:
- narrate "<&[error]>指令参数过多"
- stop
- define name <context.args.get[2]>
- if !<server.has_flag[warps.<[name].escaped>]>:
- narrate "<&[error]>地标 <&[emphasis]><[name]> <&[error]>不存在"
- stop
- teleport <player> <server.flag[warps.<[name].escaped>]>
- narrate "<&[base]>已传送至 <&[emphasis]><[name]><&[base]>!"
- case player:
#+ 需要指定一个将他人传送至地标的权限
- if !<player.has_permission[dscript.warp.other]>:
- narrate "<&[error]>你没有权限使用这个"
- stop
- if <context.args.size> < 3:
- narrate "<&[error]>你需要指定玩家名和地标名"
- stop
- else if <context.args.size> > 3:
- narrate "<&[error]>指令参数过多"
- stop
- define playerName <context.args.get[2]>
- define destination <context.args.get[3]>
- define playerToWarp <server.match_player[<[playerName]>].if_null[null]>
- if <[playerToWarp]> == null:
- narrate "<&[error]>找不到玩家 '<&[emphasis]><[playerName]><&[error]>'!"
- stop
- if !<server.has_flag[warps.<[destination].escaped>]>:
- narrate "<&[error]>地标 <&[emphasis]><[destination]> <&[error]>不存在"
- stop
- teleport <[playerToWarp]> <server.flag[warps.<[destination].escaped>]>
- narrate "<&[base]>已将玩家 <&[emphasis]><[playerToWarp].name> <&[base]>传送至 <&[emphasis]><[destination]><&[base]>!"
- default:
- narrate "<&[error]>未知参数 '<&[emphasis]><context.args.first><&[error]>'!"

复制代码

可复制

我们使用if指令及has_permission来检查玩家是否有创建地标和传送他人的权限，想要测试这个脚本，你可以让其他玩家执行指令，如果你是本地开服，你可以把你的管理员权限下了再进行测试。

相关的参考文档

第7小章节作者尚未完成。

队列系统（queue system）

原文链接

概览

队列是什么？

对于Denizen而言，“脚本”（scripts）可以指代很多东西，比如一个.dsc文件，或其中包含的一个XX型脚本（比如type:world的触发型脚本），或者脚本中包含的某条可运行的指令，在本章节教程中，我们想将“脚本”的含义固定在第三个含义。一个脚本可以简单如一条单独的narrate指令，或者复杂如一长串可一条一条执行的指令，例如wait指令来让两条指令之间暂停一下，run指令来触发其它脚本，等等。

当你运行一个脚本时，意味着一个“队列”开始了，所谓队列可以被理解为“当前正在进行的脚本”，也许这个概念听起来不易理解，但对于Denizen的运行来说这个概念是相当清楚的。

队列的运行是相互独立的、短暂的、独特的，它们或运行或暂停都是互相独立的，存储的也都是互相独立的临时数据（比如定义definitions）

为了更好地理解队列，不妨让我们用几个例子来讲解一下，下面会给出一些例子，如果你一开始没读懂，先别急，继续往下读，说不定可以在下一个例子里把这个搞懂。

用词说明

当我们谈到某东西“和队列相关联”，我们仍然会使用“脚本”（script）一词，例如我们会说：某个脚本包含有一个定义（哪怕实际上包含有定义的其实是“队列”），此脚本中包含相关指令且将会在该队列中设定该定义，这种说法比“是脚本设置了定义”要好理解一些。唯有要比较“脚本”和“队列”的区别时才会把二者的概念分开，以避免误解。

从/ex指令讲起

不妨让我们先用指令/ex和指令/exs来搞清楚队列到底是什么。

在游戏中，输入以下两个指令，先是第一个：

/ex define example <player.name>

复制代码

再是第二个：

/ex narrate <[example]>

复制代码

你也许会发现指令输出了报错，[example]这个定义根本没有被填入，你在第一个指令里使用define指令创建了一个定义，并在第二个指令里尝试用narrate指令调用这个定义——然而根本不管用。

为什么不管用？因为这两个指令分属于相互独立的“队列”，第一个指令里创建的定义只在第一个指令的队列中有效，无法和第二个指令关联起来。

现在，不妨再试试/exs指令——/ex指令的含义是“执行”（execute），/exs指令的含义是“保留队列地执行”（execute-sustained），其作用是将执行的指令保留在同一个队列里。

先输入： /exs define example <player.name> 再输入： /exs narrate <[example]>

这次你就会发现你的玩家名称正确地被narrate显示了，因为这一次两个指令被运行在了同一队列里，第二个指令可以关联到第一个指令中的定义上。

脚本例子

让我们用一些实际的脚本来区分一下“脚本”和“队列”的不同。

可复制

queue_demo:
type: task
script:
- define choice <util.random_decimal>
- narrate "<queue.id> 是属于脚本 <script.name> 的队列，并选择了 <[choice]>"
- wait 5s
- narrate "<queue.id> 队列仍然记得选择 <[choice]>"

复制代码

可复制

加载这个脚本，并在游戏快速输入两遍/ex run queue_demo

你将会看到如下输出：

在上面的图片里，你可以看到两条队列被启动了，一个标签为QUEUE_DEMO_4_MakeupToday，另一个标签为QUEUE_DEMO_7_ReferenceEfficient，这些ID名称由脚本名称组合而成（每次一个新队列被启动，会有一个从1开始计数的序号生成）还有两个使用生成器随机生成的单词，在控制台debug记录中，你也许会注意到队列的ID也有随机的颜色，和两个随机单词挂钩（“MakeupToday”是白色+品红色，“ReferenceEfficient”是橙色+绿色），这样可以更清晰地在繁杂的debug记录中定位每个队列的位置（当然，你可以在Denizen/config.yml自己设置队列的ID，如果你想的话）

标签是“MakeupToday”的队列选择了一个随机数“0.315...”标签是“ReferenceEfficient”的队列则选择了“0.251...”

两个队列都由同一个名为queue_demo的task任务型脚本触发，但彼此是互相独立的，它们运行开始的时间也有细微不同（取决于你重复两遍触发指令间隔多快），它们各自选择了不同的随机数并存储于各自的choice定义之中，各自等待5秒之后，各自用narrate输出了自己选定的随机数，无论是队列ID、运行时间节点还是随机数的选定，没有一个是一样的。

你也会注意到每次使用指令/ex都会启动各自不同的队列，执行run指令也是分开的，已经执行完毕的队列不会干扰正在执行的队列。

队列，互相独立

译者注：以下内容全都是废话，作者一向擅长用几百几千字解释一件一句话就能解释清楚的事情，只需知道队列（queue）全部都是互相独立的即可。

每个队列都是各自独立的，也就是说无论是运行/启动/终止都是互相独立的，记录数据也是独立的。

★启动互相独立
如同我们前面演示的，你可以使用指令/ex run ...一个脚本数次，用同一个脚本触发不同的新队列数次，即便上一个队列还在运行中，也不会干扰到新被启动的队列。

★运行互相独立
在上面的脚本实例中，我们可以看到两个队列互相等待（wait）的时间也是互相独立的，如果你觉得不够清晰透彻，不妨执行指令/ex run queue_demo 并等上几秒后再执行一次，你将会看到：第一个队列被启动→等待→第二个队列被启动→等待→第一个队列结束→第二个队列结束，结束时间取决于你间隔多久启动第二个队列，，每个队列执行wait的时间都是分开的。

★停止互相独立
每个队列停止互相独立，如上面的例子，第一个队列已经终止，但第二个队列还在运行。
在脚本中你可以随时使用指令stop来终止一个队列，这个指令将终止运行到此处的队列，而同一脚本中的其他队列将会继续运行，直到也运行到stop处停止。

★记录数据互相独立
每个队列相关联的记录数据都是互相独立的，最常被用到的数据就是定义（definitions）——如同上面的例子里一样，定义choice在每个队列里都是不同的。
也就是说，和队列相关联的玩家/NPC也都是互相独立的，同样的脚本可以为不同的玩家运行很多次，每个玩家/每次的队列都是独特的。

这个机制也包含了环境相关数据（context data）例如在触发型world脚本中，同一个事件被触发多次，相关的环境变量都是独立的。

该机制同样包含 save特性。

队列，是临时的

队列，是独特的

队列，是瞬时的

如果一个队列没有使用到会使脚本暂停的机制（例如wait指令），这个队列也许会在一瞬间全部完成，当然这个“一瞬间”不是指一点现实意义时间都不花，但指的是“一点游戏内的时间都不花”，换句话说，在队列正在运行的这段“时间”内，整个Denizen乃至整个Minecraft都是“静止”的，整个服务器都停下以等待队列中全部的指令执行完毕。

但是，若你给了队列一个暂停的机制（例如wait指令），该队列会在瞬间运行至暂停的部分，紧接着进入暂停时间，在暂停时间里服务器的其它机制可以正常运行，包括让其他队列运行指令等等。当暂停时间结束，该队列恢复运行，将继续一瞬间运行剩下的指令，直到队列运行完毕或是遇上下一个暂停。

◆技术向内容1：队列和线程（threads）
如果你有其它编程语言的开发经验，你也许会觉得队列这个东西听起来和“线程”（threads）差不多，没错，这俩概念是相似的，不过最明显的区分是当队列在无暂停的条件下运行时，其它队列都不能同时运行，这与“多线程”的概念相冲突，多线程可以并发工作，同时也必须注意一个线程尝试交互的数据也许会同时被另一个线程占用。

队列在读写数据时完全不用担心占用和冲突问题，但唯一需要谨慎的是执行中使用wait暂停的队列，暂停恢复后的队列尝试交互暂停前的数据——这些数据也许在队列暂停期间就起了变化。例如，你读取了一个材质为“门”的方块，并使用wait进入暂停，再尝试用switch指令来把门打开，可是在队列暂停期间假如有熊孩子玩家把门破坏，结束后再运行的switch指令运行时将出现报错。

◆技术向内容2：即时队列（InstantQueue）和延时队列（TimedQueue）
你也许会在你的debug内容里看到如下内容：Forcing queue (NAME) into a timed queue... 这是因为对于大部分队列来说执行是一瞬间完成的，若执行时遇到了暂停（例如使用了wait），那么它将变成“延时队列”，这两种队列的不同仅在内部机制中有意义，所以看到这种debug内容完全不必要担心，你只需要知道这是正常现象，是内部机制在发挥作用即可。

队列不是一定和脚本挂钩

那个队列在运行吗？

这里有一个关于队列系统更为进阶的例子，它运行了另一个队列，并始终记录着该队列是否还在运行中。

可复制

start_a_queue:
type: task
script:
- run wild_queue save:myqueue
- while <entry[myqueue].created_queue.is_valid>:
- narrate "队列有 <entry[myqueue].created_queue.determination.size> 个输出结果。"
- wait 1s
- narrate "队列已结束并输出了: <entry[myqueue].created_queue.determination.formatted>"
wild_queue:
type: task
script:
- while true:
- determine passively <util.random_boolean>
- if <util.random_chance[20]>:
- stop
- wait 0.5s

复制代码

可复制

使用指令/ex run start_a_queue 来执行一下这个脚本。

这个例子中运行了互相独立的队列，并记录着其是否还在继续运行，以及显示其输出的结果。“wild_queue”这个脚本被用作运行随机的一段时长，以确定一个输出的随机值。

需要注意第一个narrate也许会在很短时间内就有输出“队列已结束...”，若非如此，其输出内容将总是“队列有1个输出结果。”

这是因为run指令运行新队列是立刻的，所以，任务型脚本start_a_queue触发的队列于此处暂停并等待任务型脚本wild_queue运行，直到其也暂停——当wild_queue暂停时，服务器立刻转回start_a_queue的队列并继续运行while指令以及第一个narrate指令，直到运行到它自己的wait指令，直到这个时间节点你的服务器终于可以喘口气干点别的事情，例如运行Minecraft的本身游戏逻辑等等。

如果wild_queue通过了第一个random_chance并停止了，那整个流程将会是：队列start_a_queue运行了wild_queue，而后者开始了一个循环，输出了一个结果并就此停止，输出最后的narrate，最后彻底停止，之后服务器继续运行别的任务。

Denizen足够快！

相关的参考文档

第9小章节作者尚未完成。

脚本和变量，本为一家——指代型脚本

原文链接

注意：这一章内容作者目前标注为PARTIAL，即“没写完”

译者注：原文procedure scripts我目前暂时翻译为“指代型脚本”

简单的范例

以下提供一些指代型脚本的实际运用：

可复制

pretty_name:
type: procedure
script:
- determine <player.name.hex_rainbow>

复制代码

可复制

在游戏中使用指令/ex narrate proc[pretty_name]，会用彩虹色显示你的名字。

可复制

prettifier:
type: procedure
definitions: text
script:
- determine <[text].strip_color.to_titlecase.hex_rainbow>

复制代码

可复制

当你在游戏里使用指令 /ex narrate <player.name.proc[prettifier]> ，它会输出你彩虹色的大写的名字。你也可以试试 /ex narrate "<element[一些文字内容].proc[prettifier]>" ，来让你输入的内容全部大写+彩虹色

相关的参考文档

第11小章节作者尚未完成。

我已经通关了基础篇！

原文链接

我已经通关了基础篇！

我想制作出基于NPC的任务/商店/对话系统

我想成为脚本大师，并用脚本完全掌控服务器

我只是想给服务器添加一些新机制而已

上一篇教程：迈出第一步（点击跳转）下一篇教程：NPC（点击跳转）

来自群组: PluginsCDTribe

[2022.06.06][PCD]Denizen新手教程之三：基础篇

回复: