考虑到现在吧里缺少对黑石理论系统的讲解，故发此贴，以减少新人研究黑石现象所走的弯路，推动黑科技的发展。
注1：黑石指的是红石的黑科技
注2：本文默认基于minecraft1.8

要谈到时序，我们首先要关心的东西是：延时刻！
在一个世界中，方块就是它的id加上4bit附加值罢了。除了随机方块刻和实体等向它发出的世界之外，它像个木头一样一动不动。那怎么实现“在几gt后处理什么事情”呢？答案就是通过延时刻（next tick entry）
注：next tick entry是mcp反混淆出来的名称，但我觉得这名字很不咋地...“to-do list element”都比这强。
这个方块会在世界专用的延时Set里添加一个延时标记。这个标记所含有的数据有：
它所标记的时间，延时标记的优先级，它的方块坐标与方块ID，和表示它进入延时Set顺序的一个数字id。
但需要注意的是，这个数字在重启游戏时是会重置的。
在延时刻的时候，mc会把当前tick的延时标记拿出来，复制到一个列表里，再去遍历它。这个列表的顺序是：优先级小的在前。如果两个标记优先级一样，则添加到延时Set越早越靠前。而在正常运行情况下，不会有什么别的线程来捣乱，id是完全不重复的。所以
延时标记的更新顺序和hash无关！
延时标记的更新顺序和hash无关！
延时标记的更新顺序和hash无关！
接下来的内容就需要mc截图了，等会儿去拿电脑

更

快更

接下来要讲的是BUD
——狭义和广义上的BUD
——BUD传感器、BUD现象和BUD态
BUD（Block Update Detector）即方块更新感应器。名副其实，作为一种可以检测方块更新的传感器，其能够将方块的更新转化为红石电路中信号的变化。BUD也因为与一些现象联系紧密，故其本身的概念也得到了引申。观察不同种类的BUD，不难发现他们都有一个显著的共同特征：所有的BUD中都存在有处于亚稳态的方块。这里所谓的亚稳态，是指方块处于这样一种状态：虽本身无任何变化，但却极易受到外界的干扰从而造成自身的改变。因此，BUD有时也被用来指代方块处于这种亚稳态的现象；这种亚稳态，有时也被称作BUD态。
所以，狭义上的BUD是指可以检测方块的更新变化并将这个变化以某种形式输入红石系统的传感器，而广义上的BUD则是指方块处于亚稳态，可以对方块更新做出某种反应的现象。
综上，我们平时常说的BUD可能会有如下几种不同的意思：
1）传感器。可以检测方块更新，并将方块的更新变化输入红石系统。
2）现象。方块处于亚稳态，可以对方块更新做出某种反应的现象。
3）亚稳态。虽本身无任何变化，但却极易受到外界的干扰从而造成自身改变的一种状态。外界的干扰从而造成自身改变的一种状态。
上面是nenn@正正正正正好 的bud贴。https://tieba.baidu.com/p/3410685042 由于他的帖子实在太触，所以我只会讲一些比较鲜为人知的bud现象。

今天就更到这里了。
作业1：为什么会一个灯亮一个不亮？
作业2：为什么前两个中继器不停变化状态，但最后一个中继器没有任何反应？

没错！自身造成的短路和时钟造成的短路有一个很大的区别。
按照mojang的意图，当一个火把熄灭时短路了，它会给自己添加一个8秒的延时标记，以实现一段时间后重新亮起。它的代码上的顺序，也就是先把自己放置为熄灭的红石火把，再添加延时标记。
但是别忘了，这个放置的过程需要产生方块更新！也就是说，它使得红石粉熄灭了。然后方块更新传递到自身。自己发现应该亮起但是熄灭了，就添加了一个2gt的延时标记（这里没有对短路的要求）。
一个坐标的方块是不允许有两个延时标记的。所以，新添加的8秒后的延时和方块更新导致添加的2gt延时产生了冲突，添加失败！而在2gt后，由于还在短路，火把连亮起都不行，更别提添加延时标记了！
换句话说，自己充能自己和时钟影响自己之间的最大区别就是，只有自己充能自己造成短路后，在放置熄灭的红石火把和添加延时标记之间才能改变自己是否应该亮起。（也因为红石粉是无延迟元件）

用时间轴来描述的话:
自己造成的短路:
自己所在方块被充能
火把熄灭
产生方块更新
红石线熄灭
自己所在方块失去充能
收到方块更新
发现自己应该亮起
添加延时标记2gt
添加延时标记8s，添加失败
2gt后，短路，无反应
外部造成的短路:
自己所在方块被充能
火把熄灭
产生方块更新(无任何影响)
添加延时标记8s

接下来的bud是锁比较器bud。要想知道什么是锁比较器bud，首先得知道什么是比较器: https://tieba.baidu.com/p/4198137589 以前，人们认为这是贴图错误。在@zat喵 的这个贴里面，他提出了一些新的猜想(虽然还没有贴图错误的说法更偏近正确一点)，但者提出了一个新的黑科技，引发了我们对于它的一些兴趣。接下来的讲解无图，以后可能会补。

锁比较器可以算作一个人为的称呼。它的本质是信号为0的，激活了的比较器。可能这有一些矛盾?但不要忘了，在mc里这些都是由变量来表示的。是否激活保存在方块元数据里，信号强度保存在方块实体里。因为信号强度加上强模渣模千千万万，16bit是无论如何表示不了的。所以说，方块元数据上是否激活，和信号强度上是否有信号，是完全不同的两个概念。"贴图错误"，贴图，其实反映的是方块的元数据。

那么，这种情况是如何产生的呢?这源于mojang对是否激活的计算。为了直观理解并便于分析，我将会把简化的伪代码发在下面，省去了一些无关的细节:
当收到方块更新{
如果当前方块不在延时列表里{
计算应该输出的信号强度;
获取tileentity内的当前信号强度:
计算是否应该激活;
获取方块元数据内是否是激活状态;
如果其中有一处不同，那么添加一个延时标记(2gt)
}
}
当收到延时更新{
储存当前的信号强度(设为a)
把信号强度设为计算出来的信号强度
如果a和现在的信号强度不同或者比较器处于比较模式{
把激活状态设置为算出来的激活状态
产生方块更新
}
}

其中最关键的，计算是否应该激活的代码，是这样的:
获取输入端(比较器正后方)的信号强度
如果大于等于15，则是true
如果等于0，则是false
否则，返回后方的信号强度是否大于等于侧边的信号强度。
从这里也能看出来了，在减法模式下，若两边信号相等，虽然输出信号为0，却仍然是激活状态!

接下来，我们模拟一下制造锁比较器的过程:
第一步，在比较器后方提供信号(以后均默认强度为15)，比较器亮起
第二步，在侧边提供信号。虽然比较器是减法状态，输出信号为0，但比较器仍是激活状态。
第三步，移除后方的信号。添加到延时列表。收到延时信号时，由于信号强度没有变化，仍是激活状态。
第四步，移除侧边的信号。比较器添加延时标记，但仍无动作。
这样，我们就得到了一个锁比较器。

那么，锁比较器有什么用？
根据以上提供的代码，当它收到方块更新时，它会添加延时标记。然后在2gt后收到延时标记时，它却什么也不会做。
可不可以将其理解为一个自复位BUD？
当给它一个方块更新时，它会有2gt的"进入延时列表"的改变，然后在2gt后恢复。
方便起见，我们把进入延时列表和未进入延时列表这两种状态分别称为“标记态”和“BUD态”。

很容易想到，当在标记态给比较器一个红石信号时，它不会延时2gt，而是延时到锁比较器的标记态结束。
一次标记态的长度永远是等于2gt的，所以在锁比较器的标记态提供信号相当于减少了延迟！
那么，如果不停地给BUD态的锁比较器更新的话，不就可以做到无延迟比较器？！
是的，但是有一个问题:如果在标记态之后0gt时给予信号，将会延迟2gt，如果在标记态后1gt时给予，将会延迟1gt，如果在标记态结束前给予信号，将会延迟0gt。
合理地控制优先级，可以避免延迟2gt的情况。
但是如此，还是有延迟1gt和延迟0gt两种可能性。所以，建议在这两种情况下使用锁比较器减少比较器的延迟:
1.可以预测信号将会在比较器标记态的第几gt处传来的情况
2.只需要尽可能减少延迟，减少多少无关紧要的情况。
这就是锁比较器bud的理论介绍~