全物品教程·前置知识

2 发布于 2026-10-10, 22:17 No.4
预计阅读约 34.4 分钟

本帖转载整理自 《全物品详细教程》,作者 Inxarion,供服内玩家参考。


书名:《全物品详细教程》

作者:Inxarion

网址:https://ccu-mc.ciki.org.cn/


前置知识

全物品详细教程

本教程旨在帮助你看懂本全物品的各个零部件,因此部分设计思路进行简化,保证可读性。你可以点击
PDF旁边的书签快速跳转对应章节。

配图

前置知识

既然你打算建造全物品,极有可能你已经实装过刷石机、刷沙机、刷铁机、刷冰机等前置机器,对基本
的红石原件有所了解,并清楚物品分类等基本装置背后的原理。下面给出更多必要的前置知识,以便正
式讲解。
这里引用GTMC的相关讲解,国内用户阅读较不方便,所以放在这里#01 更新概念与不同类型的更新
读完前置知识后,你应当解释:

QC与更新理论初步

[1.1 广义更新]

在Minecraft中,方块与方块通过互相“通知”来建立相互的联系。
有一天,你突发奇想——在地上放置了一个音符盒。然后,你又紧邻着音符盒放置了一个红石
块,音符盒发出了悦耳的声音。那么,音符盒是怎么知道自己应该恰好在这个时候发出声音的
吗?难道音符盒会一直给玩家发消息:我要发出声音吗?我要发出声音吗?我要发出声音
吗……这显然是不合理的。实际上,音符盒能够发出声音,是因为红石块在被放置时,“通知”了
音符盒:嘿,这里有点变化,你注意一下。
这种通知行为就称为广义上的更新。
需要注意的是,红石块并不会通知“我是一个红石块”或者“这里从空气变成了红石块”,而是非常
简单地通知:这里有点变化。也就是说,在Minecraft中,更新行为并不包含行为的具体信息。
[1.2 更新的类型]

在Minecraft中,更新有不止一种类型。

让我们继续上文中的例子。这天,你又灵光一现——在地上先放置了一个红石块,然后间隔一
个方块放置了一个栅栏门,在红石块和栅栏门的中间放置了音符盒。你突然发现,音符盒怎么
没有发出声音呢?于是,你右键栅栏门,把栅栏门打开了,但音符盒还是没有发出声音。按理
来说,上文中的“放置红石块”和“栅栏门打开”都是某种变化,它们都应该“通知”音符盒,为什么
音符盒没有如愿地发出声音呢?带着疑惑,你直接把栅栏门破坏掉了,此时音符盒又发出声音
了。
——这是为什么呢?
你于是猜想:“放置红石块”和“栅栏门打开”的“通知”也许有什么差别。
实际上,这两个通知的确是不同的。现如今我们分别称1之为NC更新和PP更新。
此时你又思考:为什么音符盒被放置的时候,不会立即发出声音呢?它难道在“出生”的时候不会
看一看“自己要不要说两句话”吗?——没错,音符盒比较懒,它确实不会“检查自己要不要发出
声音”。
这种在被放置等情况下检查自身的行为,被称为自检。自检可以被视作一种特殊的更新。而音
符盒不会进行自检。
你在先前的学习中又了解到:比较器是一种能够检测容器中物品数量的红石元件,根据容器中
物品数量的多少输出0-15的不同强度高低的红石信号。你想到:当容器中物品数量发生变化
时,容器并没有必要发出NC更新或PP更新,毕竟只是内部物品多少改变了,并不会对周围方块
产生什么太大影响。但你知道比较器却能够及时地改变自身输出的红石信号强度,说明比较器
还是能够收到这种变化的“通知”。这是因为容器在容器中物品数量发生变化时,也会发出一种特
殊的通知。
这样的通知被称为比较器更新。

配图

[1.3 NC更新]

[1.3.1 NC更新的概念与行为]

方块在被放置、破坏、或发生能够显著影响周围方块的变化时,会发出NC更新。例如:
方块的放置与破坏
红石粉能量等级发生变化
活塞的推拉*
但一些变化不会发出NC更新,最为常见的有:
可连接方块的连接状态改变,例如玻璃板与其他方块连接、各种墙与其他方块连接
红石粉的连接状态发生变化,例如一个与它南北侧红石粉相连的红石粉又与东侧的一个红
石粉相连接
活板门、栅栏门的开关
发射器、投掷器的激活状态改变(!重要)
漏斗的激活状态改变
一个发出NC更新的“方块”称为更新核,大部分方块发出更新时,更新核是它本身。
更新核发出NC更新时,按照西东下上北南的顺序,依次对更新核西侧紧邻、东侧紧邻……的方
块发出NC更新。这样的更新就是通常意义上的更新。
部分方块在发出NC更新时不只有一个更新核,它们具有特殊的更新核与范围:
红石粉的能量等级变化为二阶毗邻更新[2]。
带有指向的红石元件,例如红石中继器、比较器、侦测器,它们在激活状态发生变化时先
单独更新它们输出端指向的方块,再以输出端指向的方块为更新核发出NC更新,并且在NC
更新时不会更新它们自身方块。
平放的动力铁轨切换激活状态时,先以自身为更新核产生NC更新,再以下方方块为更新核
产生NC更新。
斜放的动力铁轨切换激活状态时,更新顺序为上、中、下、中、下、上(以自身为更新核
产生NC更新简写为中、以上方方块为更新核简写为上、以下方方块为更新核简写为下,详
细解读参见斜向铁轨的更新行为)。

以上是常见且较为典型的例子。更多的特殊情况可以参见Wiki-方块更新
[1.3.2 NC更新的性质、QC激活、BUD装置]

NC更新最典型的性质是能够使BUD装置响应。
一个方块当前的状态与它本应该的状态不同时,这个方块就可以称作是一个BUD装置,即方块
更新检测器(Block Update Detector)。这种方块状态也可以称作是BUD态。
最典型的BUD装置是一个被充能(受到红石信号)但未被激活(未伸出)的活塞。活塞具有特
殊的充能范围,当活塞本身和活塞上方的一个方块(可以为空气)被充能时,活塞就可以被认
为被充能。通过充能活塞上方的空气充能活塞,这种充能方式就称为QC充能。这样被充能的活
塞在受到NC更新后伸出,就称作QC激活。
QC (quasi connectivity) 称为半连接性,活塞、粘性活塞、投掷器、发射器都具有这种性质。
想象一个活塞的斜上方放置了一个红石块,此时这个活塞被QC充能。而红石块的放置只会更新
它毗邻的六个方块,无法更新到活塞,所以没有任何方块通知活塞“这里有一个红石信号”。此时
这个活塞本应伸出,但却因为没有受到NC更新而没有伸出。也就是当前的状态与它本应该的状
态不同,即此时这个活塞处于BUD态,该活塞就构成了一个BUD装置。
此时,如果在活塞边上放置一个方块,方块放置就会发出NC更新。活塞受到NC更新,解除
BUD态。
一个最简单常用的可以自行复位的BUD装置如下:

配图

图中的红石块QC充能下方粘性活塞,当粘性活塞受到NC更新后伸出,红石块不再充能,而后
粘性活塞收回,红石块再次QC充能粘性活塞。
[1.4 PP更新]

[1.4.1 PP更新的概念与行为]

几乎所有的变化都会发出PP更新。除了:
使用命令放置方块
使用调试棒改变方块状态
等极其特殊的情况;但还是有一个特例:
粘性活塞推动正在激活的侦测器,到位时侦测器不发出PP更新。
官方提供的反混淆中PP更新为updateShape ,即更新形状(例如,各种墙的形状、活
板门的开关、红石元件的激活状体改变,都可以称作这里的“形状”),该反混淆名更有
益于理解PP更新。PP更新的命名来源于mcp反混淆中是postPlacement 方法。yarn反
混淆中则称为getStateForNeighborUpdate
和NC更新不同,PP更新的顺序为西东北南下上。
在上文中提到的不会发出NC更新的行为,都是较为典型的发出PP更新但不发出NC更新的行
为。同样,上文中的BUD装置无法用来检测PP更新。
例如这里的栅栏门状态发生变化,发出pp更新,但并不会被活塞BUD装置检测到

需要注意的是,除了放置与破坏方块外,大部分红石元件的NC更新范围和PP更新范围是不一样
的。例如中继器的NC更新范围是输出端及输出端的毗邻(除中继器自身),而其PP更新范围是
自身的毗邻。
PP更新可以理解为自身发生变化的更新,而NC更新可以理解为通知可能需要改变状态的方块的
更新。
同样以中继器为例,中继器的亮灭属于自身发生了变化,通过PP更新通知自身毗邻的方块。而
中继器亮起会充能它输出端的方块,如果输出端的方块能够传递红石信号,这个方块还会再向
它的毗邻传递红石信号;所以说中继器的亮起有可能会影响它输出端的方块以及输出端毗邻的
方块,因此中继器通过NC更新通知可能受到影响的方块检查是否要改变状态。
又例如,当投掷器被激活,投掷物品时,投掷物品这一行为并不会对周围方块造成影响[4],因
此投掷器激活并不发出NC更新。但是投掷器的确改变了激活状态,这种状态改变使得投掷器发
出了PP更新。
这样,PP更新与NC更新的差异以及它们更新范围的不同就易于理解了。
[1.4.2 PP更新的性质]

既然上文中的BUD装置无法检测PP更新,那么什么装置能够检测(响应)PP更新呢?
答案是——侦测器。侦测器长得像脸的一面为检测PP更新的一面,有红色小点的一面为输出红
石信号的一面。

侦测器响应、且仅响应PP更新。但由于大多数情况NC更新总是伴随PP更新的,所以这里的“仅”
可能体现的并不明显。不过我们还是可以通过一些方法来体现:当侦测器直接面向中继器时,
中继器亮灭会激活侦测器;但如果侦测器面向中继器输出端指向的方块(空气),中继器的亮灭
则不会激活侦测器。这里也很好理解:当中继器指向一个空气时,空气不会有任何变化,因此
侦测器自然也不会响应了。
通过BUD装置与侦测器的配合使用,我们可以很方便的在不翻阅源码的情况下测出各个红石元
件的NC更新范围和PP更新范围。
计划刻初步

在Minecraft中有大量的事件需要处理,这些事件被按顺序放在一个大循环里,我们称这个循环
为游戏主循环,在不使用 /tick 命令,游戏正常运行的情况下,这个主循环总是以约 每秒20次
的间隔循环,我们称这个最短间隔为 GameTick ,简称 gt。
这意味着:

  1. 1gt = 0.05秒
  2. 即使Minecraft算力充足,在不到0.05秒内计算完了游戏在本gt需要计算的全部内容,也会停
    止计算直到下一gt到来。
    因此,玩家定义了两个指标以衡量游戏是否卡顿,分别是 TPS 和 mspt。TPS全称 Tick Per
    Second 指的是每秒钟游戏执行了多少游戏刻。通常而言,这个数值是20,但当游戏卡顿时,其
    将会低于20。而mspt,全称 Millisecond Per Tick,指的是当前游戏执行每一刻所需要花费的毫
    秒数,数值越低则游戏卡顿越低。
    值得注意的是,mspt总是与TPS保持着如下关系:
    当mspt低于50时,TPS为20
    当mspt大于50时,TPS =
    在游戏中,绝大部分红石元件的响应是有延迟的。元件的宏观延迟我们在此处将其单位定义为
    gt,部分元件的延迟如下:
    中继器:2~8gt
    比较器:2gt
    侦测器:2gt

[2.1 刻内时序的观测]

这天小B做了一个装置:
请各位猜猜按下按钮会发生什么?

  1. 什么都不会发生
  2. 左边活塞伸出了
  3. 右边活塞伸出了
  4. 两个活塞同时推出
  5. 游戏崩溃
    于是小B按下了按钮
    左……左边的活塞伸出了!!!!!!

根据前两天看01-刻与刻间时序学到的知识:他进行了以下计算:
这个中继器延迟2gt,那个比较器延迟2gt……?哇两个活塞应该同时推出!那为什么只
推出了一个活塞呢?明明是同一gt却有个先后顺序,gt不是最小单位了?
面对这样的疑问,聪慧至极的小B给出了惊人的结论:游戏出bug了!
当然不是这样的!所有的玩家都应该建立一个这样的一个观念:在 Minecraft 中,大多数游戏逻
辑是运行在单线程中的,这意味着从逻辑层面上看,事件的执行必定是有顺序的,而非严格意
义上的同时!
于是一切都解释的通了,在同1gt内必v定存在某种更加精细的时序,我们称在1刻内的精细时序
为刻内时序。正如前文所提到的,进行如上的明明理论上是同一gt发生但偏偏有个先后顺序的
测试,便完成了一次刻内时序的观测。
这里还有个例子: 当按下按钮,两个装置分别出现了以下症状:
明明在同一gt内,加个中继器就大有不同,怎么有这么诡异的事情!为什么呢?本篇就将简要
的探讨以上现象!
什么你问这玩意有什么用?
多的是呢!上到极为复杂的红石装置,下至最最基本的精确时序分析,都用得上。刻内时序理
论的研究也在很大程度上促进了红石研究!包括但不限于推动上限检测,BED等听起来高大上
的红石装置和理论。
这里选取一段Void先生写的文字:

... 因此,刻内时序的学习之所以必要,不仅仅是为了解决设计中遇到的问题、解释以
前无法解释的经验结论。更重要的是,有很多人轻视刻内时序的学习,不愿意学习刻
内时序而将其仅仅视为一个问题的来源,在红石设计中常常遇到刻内时序导致的问
题,却殊不知刻内时序是红石设计中最强大的工具之一,善用刻内时序的知识可以大
大精简红石电路的设计,并提高红石机器的性能。刻内时序知识的缺乏使得许多人从
一开始就不知道这件工具是可以利用的,这个情景从社区的良性发展的角度,是需要
尽力避免的。
[2.2 微时序理论]

[2.2.1 微时序的阶段划分]

1gt就像现实世界中的一天,而在一天之内,我们又会有一定顺序的安排:起床、早饭、午饭、
晚饭、睡觉……在Minecraft中,以1gt为最小单位的时序称为宏观时序,而某1gt内的更加细分
的时序就称为微时序。
在前文中我们知道,MC执行任何东西总是有优先顺序的,我们通过源码、实验等途径发现——
Minecraft在1gt内总是大致按照以下顺序执行固定的事件:

  1. World Tick Update ,简称WTU,中文译作世界时间更新。游戏内存在一个和世界绑定的
    计时器,在世界创建时被初始化为0。在本游戏阶段内,该计时器自增1。我们称第n刻,也
    就是包含使得世界计时器增加到n的那个世界事件更新计划的刻。
  2. Schedule Tick / Tile Tick / Next Tick Entry* ,简称TT/NTE,中文译作计划刻,大部分具
    有延迟执行行为的元件都是由计划刻控制的。(在此处提及NTE和Next Tick Entry的错误译
    名旨在帮助各位读者看懂部分早期的其他文档,不希望各位继续使用这两个名字。)*
  3. Chunk Tick ,简称CT,中文译作区块刻。区块刻由分为天气和随机刻(Random Tick)。
    在此阶段内,游戏先处理雷、雪等天气事件;然后处理随机刻:当在存在玩家在一定距离
    内时,会发生作物生长、草方块蔓延、水结冰等随机刻事件。在每个区块刻阶段,游戏遍
    历玩家附近的所有区块,然后在这些区块里面随机选取方块,执行这些事件。
  4. Block Event ,简称BE,中文译作方块事件。最重要的在方块事件阶段运作的元件是活
    塞。当活塞发现自己的实际状态和供能状态不符的时候,会添加一个方块事件。在某个方
    块事件之外添加的方块事件,会等到下一个方块事件阶段执行;在方块事件阶段内添加的
    方块事件,会在本个方块事件阶段执行。
  5. Entity Update ,简称EU,中文译作实体运算。实体需要每刻都主动进行运动、实体 AI 等
    行为。所有的实体行为,比如生物运动、TNT 爆炸、怪物攻击,都发生在这个阶段。非玩
    家踩下压力板、绊线使得它们产生红石信号,也发生在这个阶段。

元件种类
运行阶段
命令方块运行指令
计划刻TT
中继器、比较器、红石火把、侦测器的亮灭
计划刻TT
红石粉、铁轨改变状态
瞬时
栅栏门、活板门改变状态
瞬时
6. Block Entity / Tile Entity ,简称TE,中文译作方块实体。有部分方块需要每刻运行自己相
关的逻辑,这些事情发生在方块实体阶段。漏斗会在方块实体阶段吸取物品、传输物品;
被活塞推动的方块,会变成移动中的方块(b36),它们会在自己创建后的前两次方块实体
阶段进行推动实体的逻辑,并且在第三次方块实体阶段变回普通的方块。
7. Async Task / Network Update ,简称AT/NU,中文译作异步事件。也可称为Player
Action/玩家操作。玩家操作实际上是从客户端发往服务端的网络数据包。在每一刻的结
尾,服务端会统一执行所有在这一刻内收到的 玩家操作数据包。
这些是在平常分析时主要涉及的游戏阶段,后文中我们也会围绕这些事件展开叙述。
[2.2.2 瞬时]

在上文中,我们认识到1gt内又划分成了不同的阶段。就像早饭只能在早上吃、午饭只能在中午
吃一样,Minecraft中的许多事件只能遵循一定的顺序,发生在特定的阶段。但还有一些“立刻响
应”的事件,就像我们渴了就可以立刻去喝水,而不关心早上、中午、还是晚上。
如果一个方块的行为可以在任意阶段发生的、只由方块更新触发,那么这个方块就称为瞬时元
件。
举例来说,红石粉亮灭是瞬时的。如果玩家关闭了一个拉杆,那么可以导致红石粉在玩家操作
阶段熄灭;如果活塞推走了一个红石块,就可以导致红石粉在方块事件阶段熄灭。
[2.2.3 延时]

既然有瞬时事件,就必然有“延时”事件。举例来说,如果玩家放置了一个红石块,红石块激活了
一个中继器,这个中继器就会在2gt后亮起。中继器亮起的这一行为具有延时,且由游戏控制
(由计划刻控制),在特定阶段发生(计划刻阶段),中继器就不是瞬时事件。
在接下来的几部分中,我们将详细地展开这些不同的游戏阶段。
[2.3 常见元件的运行阶段]

元件种类
运行阶段
漏斗因红石信号改变状态
瞬时
漏斗吸收、传递物品
方块实体TE
音符盒、钟因红石信号改变状态
瞬时
音符盒、钟发出声音
方块事件BE
发射器、投掷器因红石信号改变状态
瞬时
发射器发射/投掷器投出物品
计划刻TT
红石灯的亮起
瞬时
红石灯的熄灭
计划刻TT
按钮、压力板、绊线的亮起
瞬时[1]
按钮、压力板、绊线的熄灭
计划刻TT
重力方块判定下落、创建实体
计划刻TT
重力方块下落、到位
实体运算EU
活塞推出或收回
方块事件BE
b36[2] 推动实体
方块实体TE
b36 自然到位
方块实体TE
b36 被粘性活塞收回到位[3]
方块事件BE
[2.4 刻内时序基础分析]

在这里,我们给出一个基本的例子。
下图中,所有的命令方块内指令都为time query gametime

刻数
阶段
事件
0
AT
玩家拉下拉杆
0
AT
第一个活塞添加方块事件
1
BE
第一个活塞推出
3
TE
第一个红石块到位
3
TE
命令方块计划在4刻(延迟1刻)运行
3
TE
第二个活塞添加方块事件
4
TT
第一个命令方块读数4
4
BE
第二个活塞添加方块事件
6
TE
第二个红石块到位
7
TT
第二个命令方块读数7
刻数
阶段
事件
0
AT
玩家关闭拉杆
0
AT
第一个活塞添加方块事件
1
BE
第一个活塞收回
1
BE
第一个红石被撤去
上升沿 (拉下拉杆,粘性活塞推出):
下降沿 (拉回拉杆,粘性活塞收回):

刻数
阶段
事件
1
BE
第二个活塞添加方块事件
1
BE
第二个活塞收回
3
TE
两个红石块到位
4
TT
两个命令方块都读数4
(改自void的例子)
[3.1计划刻的概念与内容]

在Minecraft中,我们常常见到许多红石元件在被触发后并不是立即变化的,例如中继器、比较
器。这些元件总是在被触发后延迟一段时间,再发生变化。
让我们以一个生活中的例子来看。上午,你收到了一封邮件,于是你计划下午去处理这封邮
件,然后定了一个闹钟。到了下午,闹钟响了,你想到自己要处理邮件了,于是打开邮箱开始
处理邮件。
必须要注意的是:这个“闹钟”并没有任何“文字注释”。它只负责在你的手机中、在正确的时
间、提醒你一个人“有事情”。至于具体是什么事情,闹钟并不关心。 这个闹钟包含且只包含这
些内容:
什么时候响
这是第几个闹钟
有多重要
在谁的手机上响
提醒谁
计划刻就是这样一个“闹钟”。红石元件在被触发后,为自己添加了一个计划刻。当计划刻执行
时,就像是闹钟响了,红石元件就变化了。
由计划刻控制行为的红石元件,也就称为计划刻元件

[3.1.2 计划刻的内容]

像上文中的闹钟一样,计划刻只包含这些内容,我们称之为一个计划刻的信息结构:
执行时间triggerTick :在何时执行,或称延迟多久后执行[1]
子顺序subTickOrder :计划刻添加顺序
优先级priority :计划刻有多优先
位置pos :执行的坐标
方块种类type :哪一方块种类执行这个计划刻
位置和方块种类都是易于理解的属性。毕竟,方块自己的计划刻不能由其他方块乱执行 (如果
你恰好在方块执行计划刻前把它推走或破坏掉换成其他方块的话) 、也不能在世界里到处乱
跑。
执行时间,指的是宏观时序上计划刻的执行时间,也就是计划刻应该在哪一gt执行。例如,一
个1挡位的中继器被触发后添加2gt后的计划刻,2gt后,该计划刻就会被执行。我们通常说的“计
划刻元件的延迟”就是指计划刻在多少gt后执行。
子顺序,指的是相同时间内的计划刻添加顺序。例如,在同一gt内,中继器A先被触发,中继器
B后被触发。那么,在子序列中,中继器A就在中继器B前面。
优先级,指的是计划刻的优先程度。优先级是一个-3~3的整数[2],其中数值越小,优先级越
高。也就是说,在同一gt内,优先级为-3的计划刻总是比优先级-2、-1、0的计划刻更先执行。
通常在讨论优先级时,“优先级更高”和“优先级数值更低”的意思是相同的。为了避免由
“优先”这一概念和“优先级数值”造成的歧义,我们更推荐读者在向其他人说明时使用“某
一元件的计划刻更优先”来表述。
同样的,就和上文中的闹钟一样:计划刻只是一个“提醒方块有事要做”的闹钟,它并不关心方
块实际要做什么。一切执行计划刻时的行为都由方块自身控制,“执行计划刻的行为”并不在“计
划刻的信息结构”中。
而当我们说“某一元件已存在一个计划刻时”,指的就是在当前位置、存在一个方块类型和当前方
块相同的、且还没有被执行的计划刻。[3]

[3.1.3 计划刻的执行顺序]

在前两篇中,我们已经学过了宏观时序的分析,并且认识了微时序。我们知道,宏观时序总是
优于微时序的,计划刻也是同理。对于执行时间不同的计划刻,执行时间早的计划刻总是更先
执行。对于执行时间相同的计划刻,优先级更优先的计划刻总是更先执行。对于优先级相同的
计划刻,子序列更小的、也就是更早添加计划刻的总是更先执行。
所以,在比较计划刻执行顺序时,我们可以遵循这样的逻辑:

  1. 比较宏观时序,宏观时序更早即更先执行。
  2. 比较计划刻优先级,优先级更优先即更先执行。
  3. 比较计划刻添加顺序(子顺序),计划刻添加更早即更先执行。
    这就像比数字一样,宏观时序就是百位,优先级就是十位,添加顺序就是个位。
    [3.1.4 计划刻顺序的实例]

那么,让我们来看看实际的例子。
已知在图示情况下,比较器的优先级为0,中继器的优先级为-1。比较器和中继器的延迟都为
2gt。

  1. 如果在不同gt下,先按下比较器的按钮,再按下中继器的按钮,哪一个音符盒会先响起?

  2. 如果在同一gt内,先按下比较器的按钮,再按下中继器的按钮,哪一个音符盒会先亮起?
    答案:

  3. 比较器先亮起。因为宏观时序上,比较器先亮起,而后间隔一定gt中继器才亮起。

  4. 中继器先亮起。因为在计划刻上,虽然比较器比中继器先添加计划刻,但是中继器的优先
    级为-1,比比较器的优先级0更优先,而计划刻优先级>计划刻添加顺序,所以中继器先亮
    起。
    [3.2 常见的计划刻元件]

[3.2.1 中继器]

中继器和比较器统称为红石二极管或红石门(Redstone Gate)
在刻与刻间时序中,我们已经初步认识了中继器和比较器。现在,让我们深入中继器的计划刻
行为。
若中继器被锁定,则不会添加计划刻,也不会在执行计划刻时改变任何状态。 若中继器未被锁
定,则具有以下行为:
添加计划刻行为:
当中继器受到NC更新时,它会检查自身状态。若自身不存在计划刻,且应当改变状态 (即
自身没有亮起,但输入端有红石信号;或自身亮起,但输入端没有红石信号),那么添加计
划刻。
中继器添加的所有计划刻的延迟都为中继器挡位*2 gt ,除了下面这种情况:
当中继器被放置时,它会检查自身状态,若应当改变状态,则添加1gt后的计划刻。
执行计划刻行为:
若中继器亮起,则立即熄灭。
若中继器未亮起,则立刻亮起。这一步不受输入端信号影响。
若此时没有输入信号,则再添加计划刻(用于熄灭)。
举个例子:
从表现上来看,举例来说,如果给一个2挡位中继器一个时长<=4gt [5]的信号,中继器的行为如
下:
受到NC更新,添加计划刻
4gt后,执行计划刻

检测到自身未亮起,于是立即亮起
检测到输入端无红石信号,添加计划刻(用于熄灭)
再4gt后,执行计划刻
检测到自身亮起,于是立即熄灭
这一例子中包含了中继器的全部计划刻行为。
特殊的优先级变化:
若中继器指向一个横放的红石二极管或指向一个红石二极管的输入端,则计划刻的优先级
为-3 。
否则,若中继器添加计划刻时处于亮起状态(即这一计划刻是用于熄灭的),则计划刻的优
先级为-2 。
否则,计划刻的优先级默认为-1 。
[3.2.2 比较器]

添加计划刻行为 :
当比较器受到NC更新时,它会检查自身状态。若自身不存在计划刻,且应当改变状态 (即
自身没有亮起,但输入端有红石信号;或自身亮起,但输入端没有红石信号),那么添加计
划刻。
比较器添加的所有计划刻的延迟都为2gt ,除了:
当比较器被放置时,它会检查自身状态,若应当改变状态,则添加1gt后的计划刻。
执行计划刻行为:
比较器在执行计划刻时,实际上只做了一件事情:
根据比较器现在的输入状态和比较器模式,更新自己的输出能量等级。
这里的输出能量等级指的就是比较器经过计算后得出的输出能量等级 (具体计算方法见后文)。
而这里的更新包括了更新能量等级和发出更新两件事。并且对于比较器来说,从表观上可能会
有输出能量等级不发生变化的情况,但实际上此时比较器依然“更新”了自己的输出能量等级。
比较器还有相对复杂一点的更新行为——

比较器模式
计划刻行为
更新行为
比较模式
充能属性改变
NC->PP->NC
比较模式
充能属性未改变
NC
减法模式
充能属性改变
NC->PP->NC
减法模式
能量等级改变,充能属性未改变
NC
减法模式
充能等级和能量属性均未改变
不更新
比较器发出更新的行为:

  1. 在执行计划刻时,若比较器的充能属性改变 (即自身由熄灭变为亮起,或由亮起变为熄
    灭),则先发出NC更新,再发出PP更新。
  2. 如果比较器为比较模式,或比较器为减法模式且自己的输出能量等级发生变化,则发出NC
    更新。
    举例来说,就是:
    首先,这段内容全部建立在比较器确实执行了计划刻的前提下——
    只要比较器为比较器模式,就算它的输出等级不改变,包括由0变成0,也会有一次NC更
    新。
    如果比较器的输出能量等级由0(熄灭)变为1、2、3、4、5……14、15(亮起),或者由
    亮起变成熄灭,那么它会先发出一次NC更新,再发出一次PP更新,最后又发出一次NC更
    新。
    如果比较器为减法模式,它的输出能量等级由1、2、3、4、5……变成任意一个其他的能量
    等级,只会有一次NC更新。
    这些行为在一些特殊的布线中可能会有所应用。如果读者对这部分的理解感到困难,可以暂时
    只记忆比较器最常规的用法——即比较信号大小并判断是否输出、检测容器容量和减法模式,
    或者直接查表。
    比较器输出能量等级计算
    如果信号输入是红石粉或者其他比较器,则继承输入的能量。
    如果是容器,请查看此部分内容比较器信号强度计算。

输入端
输出
比较器输入端直接与容器相连
只计算容器的输入,忽略红石信号
比较器输入端隔着实体方块检
测容器
当红石信号为15时,输出15信号强度,其他情况优先计算
容器输入
特别的,当同时有容器信号和红石信号输入时,比较器会根据情况优先选择不同的信号输入来
计算输出,这一现象也被称为容器屏蔽。
案例(木桶中均没有物品):
特殊的优先级变化:
若比较器指向一个横放的红石二极管或指向一个红石二极管的输入端,则计划刻的优先级
为-1
否则,计划刻的优先级默认为0
至此,我们已经可以分析上一章中的案例

配图

左侧
右侧
gt0
按钮按下红石粉激活 侦测器
添加2gt计划刻
按钮按下红石粉激活 侦测器添加2gt计划刻
gt2
侦测器亮起 侦测器添加2gt计
划刻(优先级0) 比较器添加2gt
计划刻(优先级-1)
侦测器亮起 侦测器添加2gt计划刻(优先级0) 比较器添
加2gt计划刻(优先级0)
gt4
比较器计划刻优先级-1,侦测器
计划刻0,比较器计划刻先执
行,比较器亮起 侦测器熄灭
由于侦测器和比较器优先级相同,侦测器计划刻先添
加,先执行侦测器计划刻,侦测器熄灭 比较器执行
计划刻,由于此时侦测器已经熄灭,所以比较器不亮
起
[3.2.3 侦测器]

添加计划刻行为:
侦测器在受到面前的方块发出的PP更新后,如果自身未亮起且当前位置不存在自身的计划
刻[6],则添加2gt后的计划刻。
执行计划刻行为:
若自身未亮起,则亮起,发出PP更新,再添加2gt后的计划刻,最后发出NC更新。
若自身亮起,则熄灭。

[3.2.4 红石火把]

添加计划刻行为:
红石火把在受到NC更新后,如果自身亮起但应当熄灭且当前位置不存在自身的计划刻,则
添加2gt后的计划刻。
执行计划刻行为
如果自身亮起但应当熄灭,则熄灭。
如果自身燃尽,则熄灭[7],并添加160gt后的计划刻。
如果自身熄灭但应当亮起,且没有燃尽,则亮起。
应当熄灭/亮起:红石火把所附着的方块是否为实体方块且受到红石信号。
燃尽:如果红石火把在160gt内亮起了8次,那么自身燃尽。
红石火把燃尽后,你可以通过破坏再重新放置一个红石火把来让它“亮起”,或者等到160gt后火
把执行计划刻自行亮起。

喜欢这篇内容?点赞支持作者,获得更多创作动力

评论 (0)

还没有评论,来抢沙发吧~

请登录后发表评论