附加包教程：40.版本兼容性

Cat_A***

前言

我知道的几乎所有的附加包相关内容都讲完了，这是这个系列停更的主要原因。不过时不时突然冒出来一期总是好的，这证明了这个系列还没有完结，我也没有失踪。 有时，我们看到了想玩的附加包，但它只支持1.17-1.19，甚至1.16以下；而由于某些原因，我们又想在1.20这样的高版本上运行它。如果这个附加包只有资源包，甚至只是纹理包，那么问题一下子会小很多。 但如果还有行为包，那么就出现了问题。这时，我们可能会无视版本要求，把最高支持到1.19的附加包强制装到1.20版本。于是，游戏就会做出一系列改变...

版本适配

游戏确实考虑到了这种情况，所以在manifest.json里有一个叫min_engine_version的数组，定义了这个附加包本来应该在哪个版本运行。比如附加包应该在1.19版本运行，游戏却是1.20版本；此时游戏会切换“引擎”，对于附加包来说，游戏版本本身被降低到了1.19。 如果你导入了一个1.17的世界模板，那么这个世界的高度限制甚至是256，而不是384！同时，1.18及以后的方块、物品、生物、地物等等都会消失不见，相当于你在玩1.17的MC。 可以看出，一般地，低版本附加包直接装到高版本没什么问题。但如果是带脚本的行为包（相当于插件加行为包），那情况可能会不同：清单文件中的脚本模块名称可能会更改，此时脚本可能不能运行。 那么理论上，只要清单文件中的min_engine_version填写正确，是基本不会出现问题的。但有时这个数组填写不正确，或是被修改了，就会导致一系列问题。 一切看起来都很好。但是，还有一种情况：附加包是1.20版本的，但你只有1.19版本。这时，如果直接导入，绝对会导入失败，因为包要求的游戏版本太高了。试想一下，让1.19版本的MC使用1.20版本的“引擎”，这根本不可能，因为1.19版本的MC并不知道1.20版本的MC会更新什么。 这种情况想要让附加包正常运行就无比复杂了，不是单纯修改min_engine_version那么简单，这个数组中的数字也不能轻易向下改。但如果你就是想在1.19玩1.20的附加包，那也不是绝对不行——只是非常、非常复杂罢了。 我们不得不引进另一个情况：min_engine_version只是定义了附加包该在哪个版本运行，附加包中各文件也有它们自己的版本，且这个版本不必与min_engine_version的版本一样。各文件中的版本，被叫作“格式版本”，定义了这个文件是在哪个游戏版本写成的。

格式版本

要知道，在不同的版本中写一个功能相同的方块有不同的写法。这是因为Mojang会在更新中更改组件的名字，比如minecraft:aim_collision已经被改成了minecraft:selection_box。有些严重的更改甚至会推翻以前的组件重做，或者把一些组件整合到一起。1.19与1.20相比，方块组件的名称大致相同，但物品组件却大相径庭。 如果想让一个1.20的附加包在1.19工作，那就需要把附加包里所有文档的格式版本通通降到1.19，就连组件也要全部更改。所以，一般我们不考虑把附加包降级，只考虑把游戏升级——因为附加包的降级太难了，也没有必要。 不过这又引出一个问题：现在大部分附加包都是用1.19及以前的功能做的，但是开发者想用1.20的功能，那就必须把min_engine_version向上提。但是提上去之后，发现还需要把文档的格式版本升级，还是需要用新版语法代替旧的。这一步在游戏里体现为，游戏会读取内容，临时把它升级到最新版本，但是不修改文件，只是让临时升级出的内容运作。 那么格式版本有必要升级吗？其实方块的格式版本有好多还停留在1.16.100，升级难度巨大。不升级其实也能用，只不过让游戏临时升级而已。但我还是倾向于升级，手动且永久地升级。原因在于，新的格式版本能访问新的特性，例如1.20.30里的方块特征；而旧版本迟早会淘汰掉，一篇文档保持在最新版本才有参考的必要。 但是物品的改动虽大，却也不是不能接受。成百上千个物品文档，花费几个小时，也能提升到1.20.50的版本。

后记

所以附加包的版本兼容性原则如下： 1.尽最大可能在规定版本使用带脚本的附加包； 2.低版本附加包大多数情况可以在高版本使用； 3.高版本附加包不能在低版本使用； 4.宁可升级游戏，也不降级附加包； 5.虽然话是这么说，但为何不试试呢？万一，我是说，万一成功运行了呢？保留一点希望总是好的，对吧。 本期讲了附加包与游戏的兼容关系，下期讲附加包与附加包的兼容关系——也就是，“为什么这两个附加包死活不能一起运行？”

第三十九期 第四十期 第四十一期

心***

6666666666666666

心***

666666666666