American2050 Posted November 7, 2020 Posted November 7, 2020 (edited) I'm having an issue with the rendering of a simple texture that worked perfectly as expected in 1.12.2 but on 1.16.3 it looks just weird. The .json on models/item is: { "parent": "item/generated", "textures": { "layer0": "machinecards:items/frame" } } The texture is attached. In 1.12.2 the item class extended Item and implemented IHasModel. Not sure if that means anything or not since I don't remember how Forge 1.12.2 worked. But I think IHasModel was a default thing to do for items? Any idea how to "fix" this so it renders again as it used to in 1.12. Thanks in advance. Edited November 7, 2020 by American2050 Quote
ChampionAsh5357 Posted November 7, 2020 Posted November 7, 2020 1 hour ago, American2050 said: In 1.12.2 the item class extended Item and implemented IHasModel. Not sure if that means anything or not since I don't remember how Forge 1.12.2 worked. But I think IHasModel was a default thing to do for items? No, it wasn't. It was propagated by someone which caused the following response on the Common Issues and Recommendations thread "Using an interface (usually called IHasModel) on your Item and/or Block classes to denote that they are capable of registering a model is an anti-pattern and not necessary. All items require a model to be registered for them and usually no type-specific information from the item is needed, only the registry name, which is accessible for all items by default." As for the issue above, that's just how minecraft constructs their quads for generated item models if I'm not mistaken. If you would like to 'fix' the issue, then use a model creator (e.g. Blockbench) to create the model yourself and use that as the parent. 1 Quote
American2050 Posted November 7, 2020 Author Posted November 7, 2020 33 minutes ago, ChampionAsh5357 said: No, it wasn't. It was propagated by someone which caused the following response on the Common Issues and Recommendations thread "Using an interface (usually called IHasModel) on your Item and/or Block classes to denote that they are capable of registering a model is an anti-pattern and not necessary. All items require a model to be registered for them and usually no type-specific information from the item is needed, only the registry name, which is accessible for all items by default." As for the issue above, that's just how minecraft constructs their quads for generated item models if I'm not mistaken. If you would like to 'fix' the issue, then use a model creator (e.g. Blockbench) to create the model yourself and use that as the parent. I see. Thanks a lot. And one question. How would I "register" for the items the different models (States) it can have. I tried looking at the vanilla Clock but on Items, it's just a generic Item without anything special on it. (I'm guessing Vanilla is changing the texture from some event class). How should I implement multiple models for my item and change between them. Quote
ChampionAsh5357 Posted November 7, 2020 Posted November 7, 2020 14 minutes ago, American2050 said: How should I implement multiple models for my item and change between them. Either create multiple items if there is no reason to store them in one specific place or register a property using ItemModelProperties::registerProperty. From there, the predicate system has not changed from previous versions. 1 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.