「QuasiConnectivity（半连接性）这个特性是与活塞一同引入游戏的，因为它直接复制了门的代码，这是一个bug，但后来因玩家要求被官方认可并保留了下来。」

不知道从什么时候开始，大多数Minecraft玩家心中都埋下了这样的印象。

无论是贴吧的帖子，还是B站；无论是中文圈还是海外社区，这种说法都广为流传。听起来也确实合理：

“活塞是一个多方块结构，当时唯一有类似结构的红石元件就是门。于是开发者复制了门的代码并修改，却忘记删除‘下半门检测上半门充能’的逻辑，从而意外地引入了QC。”

但是——

事情真的有这么简单吗？

. . .

---

01｜误解

受QC影响的方块目前已知只有四种：门、发射器、活塞、投掷器。

根据Minecraft Wiki的记录我们可以整理出这样一个加入顺序：

• 门：Infdev 2010 加入
• 发射器：Beta 1.2加入
• 活塞：Beta 1.7加入
• 投掷器：正式版 1.5加入

令人意外的是，发射器在Beta 1.2中就已经具备QC特性。这比活塞要早了几乎半年。

更重要的是，反编译Beta 1.7版本中活塞与门的代码后可以发现，它们的充能检测逻辑完全不同，几乎看不出复制粘贴的痕迹。也就是说，QC并不是活塞带来的“bug”。

发射器的充能检测(beta1.7)

boolean var6 = 
var1.isBlockIndirectlyGettingPowered(var2, var3, var4) || 
var1.isBlockIndirectlyGettingPowered(var2, var3 + 1, var4);

门的充能检测(beta1.7)

boolean var8 = 
var1.isBlockIndirectlyGettingPowered(var2, var3, var4) || 
var1.isBlockIndirectlyGettingPowered(var2, var3 + 1,var4);

活塞的充能检测(beta1.7)

private boolean func_31041_f(World world, int x, int y, int z, int excludeDirection) {
return
(excludeDirection != 0 && world.isBlockIndirectlyProvidingPowerTo(x, y - 1, z, 0)) ||
(excludeDirection != 1 && world.isBlockIndirectlyProvidingPowerTo(x, y + 1, z, 1)) ||
(excludeDirection != 2 && world.isBlockIndirectlyProvidingPowerTo(x, y, z - 1, 2)) ||
(excludeDirection != 3 && world.isBlockIndirectlyProvidingPowerTo(x, y, z + 1, 3)) ||
(excludeDirection != 5 && world.isBlockIndirectlyProvidingPowerTo(x + 1, y, z, 5)) ||
(excludeDirection != 4 && world.isBlockIndirectlyProvidingPowerTo(x - 1, y, z, 4)) ||
world.isBlockIndirectlyProvidingPowerTo(x, y, z, 0) ||
world.isBlockIndirectlyProvidingPowerTo(x, y + 2, z, 1) ||
world.isBlockIndirectlyProvidingPowerTo(x, y + 1, z - 1, 2) ||
world.isBlockIndirectlyProvidingPowerTo(x, y + 1, z + 1, 3) ||
world.isBlockIndirectlyProvidingPowerTo(x - 1, y + 1, z, 4) ||
world.isBlockIndirectlyProvidingPowerTo(x + 1, y + 1, z, 5);
}

}

---

02｜时间线

既然原有理论不再可信，我们不妨回顾几个关键红石元件的时间线，试图寻找更合理的解释：

• 2009年5月，Notch在开发日志中提及对“活塞”的兴趣，并提出了Pulley1和Pulley2的概念。
• 2011年1月，发射器随Beta 1.2加入游戏，它已经带有QC特性。与此同时加入的红石元件还有音符盒，但音符盒并没有类似行为。
• 2011年3月，第三方mod作者Hippoplatimus发布了Pistons Mod，首次实现了活塞，该mod被jeb看好，获得并整合了该mod的代码进入Minecraft。
• 2011年6月，Jeb在Twitter上公布了游戏内活塞的早期版本截图。
• 2011年7月，活塞随Beta 1.7加入Minecraft，具有QC。
• 2013年3月，正式版1.5推出，投掷器加入，具有QC。

奇怪的是，Pistons Mod中的代码中，也出现了能够导致QC的额外充能检测逻辑。但这段逻辑，与Beta 1.7版本中官方活塞所用的QC实现方式又完全不同。

PistonMod中的活塞充能判断(beta1.3)

boolean var6 =
var1.q(var2, var3, var4) ||
 var1.q(var2, var3 + 1, var4);

这意味着：.

第三方mod作者Hippoplatimus在自己的活塞实现中独立写入了会造成QC的逻辑，而Mojang在重写并合并了其逻辑结构的情况下仍然保留了QC机制。

似乎难以“巧合”或“失误”来解释。这样一看，：QC似乎一开始就是一个“设计”，而不是一个“bug”。

---

03｜所以？

令人遗憾的是，这篇文章并无法为你揭示QC的确切来源。

因为即便整理了所有目前可查的信息，我们仍无法100%还原这段设计背后的完整思路。

至少我们已经知道：

那个“活塞抄了门”的解释，是错误的。

也许，QC的起源，终究会被时间的尘埃掩埋在Minecraft的开发历史中。

但我们希望，这篇文章至少能带给你一点启发：去质疑被视为理所当然的，去审视被众人接受的，去追寻那些仍未知的。 某日，有人像你请教"QC"时，我们希望你也能分享这个未解之谜。