一个潜影盒正好装下半个大箱子
潜影盒能装 27 组物品，所以装满的大箱子正好等于两个潜影盒——而红石计时也有一个与之对应的陷阱，调成 1 刻的中继器实际延迟的是游戏刻 2，也就是 0.1 秒，而不是真正只有一刻那么短暂的这段时间。
一个潜影盒有 27 个槽位，每个槽位放一组物品，所以装满的潜影盒就是 27 组——这个事实大多数玩家都答得上来，可一旦要把一整箱圆石换算成潜影盒，就立刻用错了。
组、箱子、潜影盒
换算链条纯粹是乘法，所以心算很容易，算错也很容易：
| 容器 | 槽位 | 可装组数 |
|---|---|---|
| 潜影盒 | 27 | 27 |
| 单个箱子 | 27 | 27 |
| 大箱子 | 54 | 54 |
因此一个大箱子正好等于两个潜影盒，而不是“大约两个”。如果你要搬运一大箱石头，那就需要两个潜影盒，一点不剩——但前提是每个槽位都装满了可堆叠物品的整组。
计数在哪里失效
堆叠上限因物品而异，而计算器的全部职责就是拒绝默认按 64 算。一个槽位的末影珍珠只能放 16 个，一个槽位的水桶只能放 1 个。把潜影盒装满不可堆叠物品，它装的是 27 个物品，而不是 27 组。潜影盒本身不在乎；在乎的是你的算术。
同样的陷阱也会坑到比较器分类：一个装满水桶的容器会被读成“满”，可实际上几乎没装东西。
红石刻不是游戏刻
计时是这个工具的另一半。红石有自己的时钟：
1 redstone tick = 2 game ticks
1 game tick = 1/20 second所以一档的中继器会把信号延迟 2 游戏刻，也就是十分之一秒。四档中继器就是 8 游戏刻。串联足够多之后，延迟在看得见之前就先听得见了。
活塞、侦测器和比较器各自按自己的节奏响应，把它们混用就会产生那种让门开两次的差一错误。
Java 与 Bedrock 的分歧
上面的刻数比例在两个版本中相同，但红石行为并不相同。准连接（quasi-connectivity）——让活塞能被隔两格的方块充能的机制——存在于 Java 版，而 Bedrock 版没有。零刻脉冲以及相邻元件的精确更新顺序也有差异。一个在 Java 版上快了一刻的电路，在 Bedrock 版上可能根本不会运行。
反过来换算
从物品数换算到潜影盒是带余数的除法，而余数正是浪费你背包空间的部分。每盒 27 组意味着答案通常是一个不满的盒子，而不是向上取整的结果。
用堆叠与红石计算器把物品数量换算成组、箱子和潜影盒——并在游戏刻、红石刻和秒之间换算电路的延迟。