1.1. 依赖于具体情况的物品模型

这里讲述的内容只适用于物品模型;方块模型若需要类似的效果,可能需要使用 Forge BlockState V1。
原版的物品模型都很简单,绝大多数物品的外貌也都是几个大版本下来都雷打不动的。但 Mod 不一样,很多时候我们都会发现“我们的物品的模型需要随着物品的某一数据的改变而改变”。有没有办法实现这个效果呢。

1.1.1. 依赖于损害值的物品模型

可以说是所有情况中最简单的一种,多见于 meta hack。

// 还记得这个方法吗?第二个参数就是 metadata。之前我们写了 0,因为物品没什么特别的。
// 对于这个情况,只需在调用的时候传入别的 metadata 并指定合适的模型位置就可以了。
ModelLoader.setCustomModelResourceLocation(myItem, 0, targetModelResourceLocation);

1.1.2. Property Override

但不是所有的时候我们都有 metadata 可以用。比如工具,它实际上没有 metadata,但它有耐久。如果我们希望一个工具的耐久会决定其外观该怎么做?最简单的方法就是 Property Override。
这是原版物品模型的一个机制,允许物品模型根据一个浮点数(准确地说是一个 float)的值来决定该使用什么模型。举个例子,对于有耐久度设定的工具来说,可以考虑这么做:

{
    "parent": "minecraft:item/handheld",
    "textures": {
        "layer0": "..."
    },
    "overrides": [
        {
            "predicate": { "damage": 0.5 },
            "model": "..."
        }
    ]
}

这样,在这个工具只剩下一半耐久的时候,它就会使用另外一个模型。
这个 predicate 是原版提供的。它有一个“缺陷”:这里的 0.5 是精确匹配的。也就是说,当这个值是 0.49 或 0.51 的时候它都不会改变模型——实际上,这个“缺陷”正好给地图制作者和服务器插件开发者提供了契机,因为利用这个特性可以用来给原版“新增一堆物品”。
不过这里讲的是 Forge Mod 啊,既然这个 predicate 满足不论我们的需求,那我们自己写一个不就好了。为此你需要的类叫做 IItemPropertyGetter

public class MyEpicTool extends Item {
    public MyEpicTool() {
        super();
        // 必要的初始化,请按需添加
        this.addPropertyOverride(new ResourceLocation("my_mod", "test_damage"), new IItemPropertyGetter() {
            @Override
            @SideOnly(Side.CLIENT)
            public float apply(ItemStack stack, @Nullable World world, @Nullable EntityLivingBase entity) {
                return 0F;
            }
        });
        // 是的,这里可以用 lambda,但这里仍然使用匿名内部类的原因是那个 @SideOnly,它的含义在后面的章节会讲到。
    }
}

你应该发现了,你可以利用的东西不止当前的 ItemStack 对象,还有当前的 World 和持有它的实体。为什么不是 EntityPlayer?因为能拿东西的实体多了去了,僵尸和骷髅都可以。我们只需要在这里实现我们需要的逻辑就好,然后让模型用这个 predicate:

{
    "...": "...",
    "overrides": [
        {
            "predicate": { "my_mod:test_damage": 0.1 },
            "model": "..."
        },
        {
            "predicate": { "my_mod:test_damage": 0.2 },
            "model": "..."
        }
    ]
}

尽管如此,它的局限依然很大——比如返回的值必须在 [0, 1] 之间。而且这只是一个 float,面对其他不能完美转化的数据它就束手无策了。

1.1.3. ItemMeshDefinition

如果我要依赖的数据是字符串一类的东西该怎么办?是时候让 ItemMeshDefinition 登场了。
ItemMeshDefinition 是一个原版类,允许某个物品只根据 ItemStack 提供的信息返回不同的 ModelResourceLocation。一个 ItemStack 里有什么?物品类型、数量、metadata(或损害值)甚至是 NBT 数据。理论上应该足够满足各种奇怪的需求了。

@SubscribeEvent
public static void onModelRegistration(ModelRegistryEvent event) {
    // 理论上这个也可以用 lambda。
    ModelLoader.setCustomMeshDefinition(new ItemMeshDefinition() {
        @Override
        public ModelResourceLocation getModelLocation(ItemStack stack) {
            return aCertainLocation;
        }
    });
}

和方块模型类似,使用 ItemMeshDefinition 时必须能提前知道所有可能的返回值,并告知 Minecraft 加载对应的模型。尝试返回一个 Minecraft 没有加载的模型的位置会导致实际显示为紫黑块。这也意味着:它不能用来动态生成模型。

@SubscribeEvent
public static void onModelRegistration(ModelRegistryEvent event) {
    // 第二个参数是 var-arg,类型 ModelResourceLocation。
    // 注意这里使用了原版的 ModelBakery,而非 Forge 的 ModelLoader。
    ModelBakery.registerItemVariants(myItem, ...);
}

1.1.4. 重新实现 ItemOverrideList

这一手段虽然仍然是基于原版类的,但有鉴于它牵扯到的其他信息,它有自己的独立章节。请直接前往那里获取有关信息。