QC之源：一个广为流传的误解
「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.2_02)
boolean var6 = var1.hasNeighborSignal(var2, var3, var4) || var1.hasNeighborSignal(var2, var3 + 1, var4);
这里的beta 1.2_02代码来自这个项目 ： https://github.com/modmuss50/secret-example-mod/tree/main ，其目的是使用fabric在beta1.2_02中制作模组。
通过build.gradel中的 https://modmuss50.me/versions/b1.2_02-20110517/b1.2_02-20110517-loom.json 可获取相关minecraft jar的链接：
https://vault.omniarchive.uk/archive/java/misc/b1.2_02-20110517.jar
门的充能检测(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"时，我们希望你也能分享这个未解之谜。