02 初窥刻内时序
1 刻内时序的观测
这天小 B 做了一个装置：
请各位猜猜按下按钮会发生什么？
- 什么都不会发生
- 左边活塞伸出了
- 右边活塞伸出了
- 两个活塞同时推出
- 游戏崩溃
于是小 B 按下了按钮
左…… 左边的活塞伸出了！！！！！！
根据前两天看学到的知识：他进行了以下计算：
这个中继器延迟 2gt，那个比较器延迟 2gt……？哇两个活塞应该同时推出！那为什么只推出了一个活塞呢？明明是同一 gt 却有个先后顺序，gt 不是最小单位了？
面对这样的疑问，聪慧至极的小 B 给出了惊人的结论：
游戏出 bug 了！
当然不是这样的！所有的玩家都应该建立一个这样的一个观念：在 Minecraft 中，大多数游戏逻辑是运行在单线程中的，这意味着从逻辑层面上看，事件的执行必定是有顺序的，而非严格意义上的同时！
于是一切都解释的通了，在同 1gt 内必定存在某种更加精细的时序，我们称在 1 刻内的精细时序为刻内时序。正如前文所提到的，进行如上的明明理论上是同一 gt 发生但偏偏有个先后顺序的测试，便完成了一次刻内时序的观测。
这里还有个例子：
当按下按钮，两个装置分别出现了以下症状：
明明在同一 gt 内，加个中继器就大有不同，怎么有这么诡异的事情！为什么呢？本篇就将简要的探讨以上现象！
什么你问这玩意有什么用？
多的是呢！上到极为复杂的红石装置，下至最最基本的精确时序分析，都用得上。刻内时序理论的研究也在很大程度上促进了红石研究！包括但不限于推动上限检测，BED 等听起来高大上的红石装置和理论。
这里选取一段 Void 先生写的文字：
...
因此，刻内时序的学习之所以必要，不仅仅是为了解决设计中遇到的问题、解释以前无法解释的经验结论。更重要的是，有很多人轻视刻内时序的学习，不愿意学习刻内时序而将其仅仅视为一个问题的来源，在红石设计中常常遇到刻内时序导致的问题，却殊不知刻内时序是红石设计中最强大的工具之一，善用刻内时序的知识可以大大精简红石电路的设计，并提高红石机器的性能。刻内时序知识的缺乏使得许多人从一开始就不知道这件工具是可以利用的，这个情景从社区的良性发展的角度，是需要尽力避免的。
2 微时序理论
2.1 微时序的阶段划分
1gt就像现实世界中的一天，而在一天之内，我们又会有一定顺序的安排：起床、早饭、午饭、晚饭、睡觉…… 在 Minecraft 中，以 1gt 为最小单位的时序称为宏观时序，而某 1gt 内的更加细分的时序就称为微时序。
在前文中我们知道，MC 执行任何东西总是有优先顺序的，我们通过源码、实验等途径发现 ——Minecraft 在 1gt 内总是大致按照以下顺序执行固定的事件：
这些是在平常分析时主要涉及的游戏阶段，后文中我们也会围绕这些事件展开叙述。
2.2 瞬时
在上文中，我们认识到 1gt 内又划分成了不同的阶段。就像早饭只能在早上吃、午饭只能在中午吃一样，Minecraft 中的许多事件只能遵循一定的顺序，发生在特定的阶段。但还有一些 “立刻响应” 的事件，就像我们渴了就可以立刻去喝水，而不关心早上、中午、还是晚上。
如果一个方块的行为可以在任意阶段发生的、只由方块更新触发，那么这个方块就称为瞬时元件。
举例来说，红石粉亮灭是瞬时的。如果玩家关闭了一个拉杆，那么可以导致红石粉在玩家操作阶段熄灭；如果活塞推走了一个红石块，就可以导致红石粉在方块事件阶段熄灭。
2.3 延时
既然有瞬时事件，就必然有 “延时” 事件。举例来说，如果玩家放置了一个红石块，红石块激活了一个中继器，这个中继器就会在 2gt 后亮起。中继器亮起的这一行为具有延时，且由游戏控制（由计划刻控制），在特定阶段发生（计划刻阶段），中继器就不是瞬时事件。
在接下来的几部分中，我们将详细地展开这些不同的游戏阶段。
2.4 常见元件的运行阶段
2.5 刻内时序基础分析
在这里，我们给出一个基本的例子。
下图中，所有的命令方块内指令都为 time query gametime
上升沿 （拉下拉杆，粘性活塞推出）：
下降沿 （拉回拉杆，粘性活塞收回）：
（改自 void 的例子）
Footnotes
-
但是压力板的亮起只能由实体运动触发，所以实际上只能在实体运算或玩家操作；类似地，按钮只能被玩家或者箭矢按下，所以也限制在这两个阶段。
-
b36 : minecraft:moving_piston, 移动中的活塞。
-
当粘性活塞收回的时候前方是 b36，则会立刻将其到位，也就是所说的粘性活塞短脉冲。