用户:MashKJo/1.12.2模组开发笔记/IRecipe接口详解

几乎所有1.12.2的模组开发教程都会介绍新的自定义工作台配方（广义）的添加方法——只需要在resources/assets/modid/recipes路径下撰写一些.json文件就好了。实际上这说明这块内容确实很简单——因为大部分教程别说讲到方块实体了，能讲到附魔、药水效果这种比物品、方块稍微难一点的东西就算是谢天谢地了。毕竟照着规定的格式写.json文件谁不会呢？

不过你有没有想过——原版当中某些配方似乎并不是简单地通过撰写.json文件来实现的。比如你可以将两把不是满耐久的钻石镐叠加，合成为一把新的钻石镐，其耐久结合了合成前那两把钻石镐的耐久。这种配方的实现显然并非依靠.json文件吧？

这就要请出我们今天的主角了——IRecipe接口（net.minecraft.item.crafting.IRecipe）。

IRecipe接口中的方法

boolean matches(InventoryCrafting inv, World worldIn)

这个方法用于判断合成原料是否“匹配上了”——换言之，就是判断玩家放入合成界面的物品及它们的摆放方式是否可以合成一个新物品。

这个方法传入了两个参数：第一个是InventoryCrafting类型的，你可以把这个类理解为“合成容器”，原版MC中合成容器有两种：一是工作台中3×3大小的合成容器，二是玩家背包里的2×2大小的合成容器；你可以从该参数中拿到合成容器的长、宽，以及该容器中放入的ItemStack。第二个参数是World类型的，代表玩家当前所处的world实例，这没什么好说的。

原版的ShapedRecipes和ShapelessRecipes类对于该方法的实现写的比较抽象，不过既然我们都要重新实现IRecipe了，不妨把这两个类抛开，把目光着眼于RecipeRepairItem这个类——看看这个类是怎么实现的该方法。

具体的代码实现，读者可以自行去查看，由于Minecraft EULA的限制，笔者就不在这里直接贴代码了，只说说大体的实现思路：

大致思路是：先创建了一个List<ItemStack>集合。再通过inv.getSizeInventory()拿到了放入合成容器中的ItemStack数量，再通过一个for循环把合成容器中的ItemStack添加到新定义的集合中去。这个时候读者可能就会想：判断一下该集合的长度是否等于2，不就可以返回boolean值了？是这样没错，不过我们还得加点判断——修复工具的这个配方中，工具种类总得相同吧！所以得加个ItemStack对应的Item两两之间是否相等的判断。因为Item对象是基于享元模式的，因此直接用==判断即可。

ItemStack getCraftingResult(InventoryCrafting inv)

这个方法用于获取合成配方的输出（outputs）——同样是一个ItemStack对象。

同时我们注意到这个方法传入的参数只有一个InventoryCrafting inv。我们得再通过和上一部分相同的方法把合成容器中的ItemStack信息转移到一个集合中——这里算是MC一个小小的设计失误之处吧。

boolean canFit(int width, int height)

这是一个用于检验合成容器“装不装得下”该合成表的方法，width和height这两个参数代表合成表的长和宽，读者只需根据自己的需求，对这两个参数做个判断就好了。

读者可能会有疑问：这一部分的判断放到前面的matches方法中不行吗？当然不行。因为那个方法适用于检验合成容器中的ItemStack本身是否满足该IRecipe的合成条件；如果满足了，再进行canFit这个方法的检验。即——就算这些ItemStack可以合成出新的ItemStack，你合成容器能不能装得下这个合成表那还是个问题。

不过原版也就只有两种合成容器，因此这个方法在原版MC中的意义也不是很大。

ItemStack getRecipeOutput()

读者可能会觉得这个方法和前面的getCraftingResult方法在作用上重复了，的确，可以近似认为这两者的作用是相同的，所以返回和getCraftingResult返回值相同的值就可以了。