TeaCon 茶后谈第 247 期

八年前的 2014 年 8 月 29 日，当时的林业（Forestry for Minecraft）维护团队成员之一的 CovertJaguar（同时也是 Railcraft 的原作者，参见「茶后谈#9」、「茶后谈#109」）创建了一个标题为「Kill MJ Support and remove all dependence on Buildcraft API」（「移除对 MJ 的支持和对 BuildCraft API 的依赖」，即 ForestryMC/ForestryMC#161，如下图）的 issue ticket。彼时，BuildCraft 的原作者 SpaceToad 于 2014 年年初突然宣布回归 BuildCraft 的开发，并在当年四月底前后开始着手编写一套全新的 MJ API，力图为开发者提供更「灵活」的选择。然而，在迭代了几个版本之后，有开发者发现：这套全新的 API 没有正确处理旧版 MJ API（即「茶后谈#24」中提及的由 CovertJaguar 修改后的那一版）的向后兼容，开发者被迫必须在这两套 API 中二选一，而无法同时兼容。更为致命的是，这些开发者还在新版 MJ API 中发现了一些致命错误，使得其完全无法正常使用。CovertJaguar 认为在这样的情况下，继续维持一个「和 RF 在同一级别上」，但「明显更复杂」且「有各种 bug」的 API 的兼容不再可取，建议「立即移除全部对 MJ API 的兼容」并「提供对 RF API 的原生支持」，还建议编写一套内部使用的能量传输机制供引擎和机器使用，以避免对 RF API 的硬依赖。CovertJaguar 还提到了 RailCraft 稍后也会如此跟进。由此，林业成为了「MJ 三巨头」中第一个正式开始考虑「放弃 MJ」的模组，并在大约一个月的时间内完成了放弃 MJ API 兼容并提供原生 RF API 兼容的转变。本文部分内容转述自 asie 的博文 https://blog.asie.pl/2015/01/buildcraft-history-and-design/，在此向其表示由衷的感谢。【本期编辑：3TUSK】