3,417
个编辑
→注册IRecipe
| （未显示同一用户的14个中间版本） | |||
| 第7行： | 第7行： | ||
== IRecipe接口中的方法 == | == IRecipe接口中的方法 == | ||
=== boolean matches(InventoryCrafting inv, World worldIn) === | === boolean matches(InventoryCrafting inv, World worldIn) === | ||
这个方法用于判断合成原料是否“匹配上了”——换言之，就是判断玩家放入合成界面的ItemStack及它们的摆放方式是否可以合成一个新ItemStack。例如，在原版的有序合成定义的逻辑中，木棍上面放煤炭或木炭，就是“匹配上了”——这样摆放就可以合成火把。但是，如果在把木棍换成木板——那不好意思，匹配不上，那就合成不了任何东西<ref>严格来说火把的配方是以.json文件的形式呈现的——这一点相信读者们都知道，而原版的有序合成的相关代码只是读取.json文件中的内容，并反序列化为一个IRecipe，这里这么说只是方便读者理解。</ref>。 | |||
这个方法传入了两个参数：第一个是InventoryCrafting类型的，你可以把这个类理解为“合成容器”，原版MC中合成容器有两种：一是工作台中3×3大小的合成容器，二是玩家背包里的2×2大小的合成容器；你可以从该参数中拿到合成容器的长、宽，以及该容器中放入的ItemStack。第二个参数是World类型的，代表玩家当前所处的world实例，这没什么好说的。 | |||
原版的ShapedRecipes和ShapelessRecipes类对于该方法的实现写的比较抽象，不过既然我们都要重新实现IRecipe了，不妨把这两个类抛开，把目光着眼于RecipeRepairItem这个类——看看这个类是怎么实现的该方法。 | 原版的ShapedRecipes和ShapelessRecipes类对于该方法的实现写的比较抽象，不过既然我们都要重新实现IRecipe了，不妨把这两个类抛开，把目光着眼于RecipeRepairItem这个类——看看这个类是怎么实现的该方法。 | ||
| 第20行： | 第20行： | ||
这个方法用于获取合成配方的输出（outputs）——同样是一个ItemStack对象。 | 这个方法用于获取合成配方的输出（outputs）——同样是一个ItemStack对象。 | ||
同时我们注意到这个方法传入的参数只有一个<code>InventoryCrafting inv</code> | 同时我们注意到这个方法传入的参数只有一个<code>InventoryCrafting inv</code>。我们得再通过和上一部分相同的方法把合成容器中的ItemStack信息转移到一个集合中——这里算是MC一个小小的设计失误之处吧。或者你也可以写一个private方法，以把从InventoryCrafting对象中提取ItemStack信息并存储到集合中的代码封装起来，以便多次调用。 | ||
=== boolean canFit(int width, int height) === | === boolean canFit(int width, int height) === | ||
这是一个用于检验合成容器“装不装得下”该合成表的方法，width和height这两个参数代表合成表的长和宽，读者只需根据自己的需求，对这两个参数做个判断就好了。 | |||
读者可能会有疑问：这一部分的判断放到前面的matches方法中不行吗？当然不行。因为那个方法适用于检验合成容器中的ItemStack本身是否满足该IRecipe的合成条件；如果满足了，再进行canFit这个方法的检验。即——就算这些ItemStack可以合成出新的ItemStack，你合成容器能不能装得下这个合成表那还是个问题。 | |||
不过原版也就只有两种合成容器，因此这个方法在原版MC中的意义也不是很大。 | |||
=== ItemStack getRecipeOutput() === | === ItemStack getRecipeOutput() === | ||
读者可能会觉得这个方法和前面的getCraftingResult方法在作用上重复了，的确，可以近似认为这两者的作用是相同的，所以返回和getCraftingResult返回值相同的值就可以了。 | |||
=== default NonNullList<ItemStack> getRemainingItems(InventoryCrafting inv) === | === default NonNullList<ItemStack> getRemainingItems(InventoryCrafting inv) === | ||
这个方法用于决定：合成完后，哪些物品会留在合成容器之中。很多模组中的一些有流体桶参与的合成表，合成完后会自动返还空桶，利用的就是这个方法。 | |||
这个方法的默认实现是：返还所有有容器（Container）的ItemStack的容器。比如对于岩浆桶来说，桶即是它的容器。其实这一默认实现足以适用于绝大部分情况了。 | |||
=== default NonNullList<Ingredient> getIngredients() === | === default NonNullList<Ingredient> getIngredients() === | ||
Ingredient类其实和ItemStack类很相似，甚至它的构造器就接受一个ItemStack对象，只是该类封装了一些和合成有关的东西。 | |||
该方法的默认实现为返回一个元素为<code>Ingredient.EMPTY</code>的NonNullList——说是“NonNullList”，其实只是其中的值不为null，但代表的含义还是“没有物品”。 | |||
=== default boolean isDynamic() === | === default boolean isDynamic() === | ||
默认实现为<code>return false;</code>。 | |||
该方法意为“合成表是否为动态的”，那当然要返回<code>return true;</code>了，如果不是动态的，又何必重新实现IRecipe接口呢？写个.json文件不就得了。 | |||
=== default String getGroup() === | === default String getGroup() === | ||
该方法用于获取配方所在的“组别”，什么叫“配方所在的组别”？以.json文件形式添加的配方中，有这么一个“group”键，值的格式为“modid:examplegroup”。该方法的返回值的作用就类似于这个键值对。如果你没什么特别的需求，这个方法就可以不Override了。 | |||
== 注册IRecipe == | |||
是的，IRecipe需要注册——而且走的是Forge的注册表系统。因此： | |||
public class MyCustomRecipe implements IRecipe | |||
{ | |||
private ResourceLocation regName; | |||
... | |||
@Override | |||
public IRecipe setRegistryName(ResourceLocation name) | |||
{ | |||
this.regName = name; | |||
return this; | |||
} | |||
@Override | |||
public ResourceLocation getRegistryName() | |||
{ | |||
return this.regName; | |||
} | |||
... | |||
} | |||
= | @Mod.EventBusSubscriber(modid = [Your MODID]) | ||
public class RecipeLoader | |||
{ | |||
@SubscribeEvent | |||
public static void register(RegistryEvent.Register<IRecipe> event) | |||
{ | |||
event.getRegistry().register([Your IRecipe Instance].setRegistryName(new ResourceLocation(...))); | |||
} | |||
} | |||
== 注释与外部链接 == | == 注释与外部链接 == | ||