「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

奇怪的是,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”时,我们希望你也能分享这个未解之谜。


<
Blog Archive
Archive of all previous blog posts
>
Blog Archive
Archive of all previous blog posts