[SOLVED][1.8] Prevent ModelBakery from trying to register default item model?

[coolAlias]

I have an item that is using a vanilla texture / model and I don't want to register a custom one; this works, but the ModelBakery still tries to load an item model based on my item's unlocalized name, spamming my console with messages like this:

 

[17:41:42] [Client thread/WARN]: Unable to load item model: 'dynamicswordskills:item/dss.skilldiamond' for item: 'dynamicswordskills:dss.skilldiamond'
java.io.FileNotFoundException: dynamicswordskills:models/item/dss.skilldiamond.json
at net.minecraft.client.resources.FallbackResourceManager.getResource(FallbackResourceManager.java:70) ~[FallbackResourceManager.class:?]
at net.minecraft.client.resources.SimpleReloadableResourceManager.getResource(SimpleReloadableResourceManager.java:67) ~[simpleReloadableResourceManager.class:?]
at net.minecraft.client.resources.model.ModelBakery.loadModel(ModelBakery.java:260) ~[ModelBakery.class:?]
at net.minecraft.client.resources.model.ModelBakery.loadItemModels(ModelBakery.java:307) [ModelBakery.class:?]
at net.minecraft.client.resources.model.ModelBakery.loadVariantItemModels(ModelBakery.java:105) [ModelBakery.class:?]
at net.minecraft.client.resources.model.ModelBakery.setupModelRegistry(ModelBakery.java:88) [ModelBakery.class:?]
at net.minecraft.client.resources.model.ModelManager.onResourceManagerReload(ModelManager.java:29) [ModelManager.class:?]
at net.minecraft.client.resources.SimpleReloadableResourceManager.registerReloadListener(SimpleReloadableResourceManager.java:124) [simpleReloadableResourceManager.class:?]
at net.minecraft.client.Minecraft.startGame(Minecraft.java:470) [Minecraft.class:?]
at net.minecraft.client.Minecraft.run(Minecraft.java:325) [Minecraft.class:?]
at net.minecraft.client.main.Main.main(Main.java:117) [Main.class:?]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.7.0_25]
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) ~[?:1.7.0_25]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) ~[?:1.7.0_25]
at java.lang.reflect.Method.invoke(Unknown Source) ~[?:1.7.0_25]
at net.minecraft.launchwrapper.Launch.launch(Launch.java:135) [launchwrapper-1.11.jar:?]
at net.minecraft.launchwrapper.Launch.main(Launch.java:28) [launchwrapper-1.11.jar:?]
at net.minecraftforge.gradle.GradleStartCommon.launch(GradleStartCommon.java:78) [start/:?]
at GradleStart.main(GradleStart.java:45) [start/:?]
[17:41:43] [Client thread/INFO]: Created: 512x512 textures-atlas
[17:41:44] [Client thread/WARN]: Missing model for: dynamicswordskills:item/dss.skilldiamond

 

 

I made a little interface that I use in my item classes to register textures:

@Override
@SideOnly(Side.CLIENT)
public void registerRenderer(ItemModelMesher mesher) {
// textureName in this particular instance is a vanilla texture's name such as 'wooden_sword', but could also be mymodid:sometexture
ModelBakery.addVariantName(this, textureName);
mesher.register(this, 0, new ModelResourceLocation(textureName, "inventory"));
}

 

I had to add a 'variant name' even for a single item as well, otherwise it would give me the exact same message as above a second time which I suspect is when I register the item model myself with a different name than that found in the item registry. I wonder if there is a way to avoid having to do that, too.

 

So basically I don't want Minecraft / Forge to load default models for me, because they are not correct and even when the default names are used, I still have to explicitly register model resource locations. I really dislike this new resource management system, probably because I'm not clever enough to see how it is an improvement in any way...

[perromercenary00]

ñaa

 

you have to deal whith it

i been leaving a dummy  json whith the name of mi items just to not see the error in the output of eclipse

 

in the other hand it makes more clean the code of the items and blocks you have not to deal whith gl11 or tesellators for simple rotations or scalations all that goes now in the json

 

but idunat know how to do a animation whith sen or cos andd a oot of thinks i like would be documented or at least a few examples there scatter in the code

 

 

[coolAlias]

It may make the code nominally cleaner, but it clutters up the project with redundant json files that could have all been handled by a single (and simple) IItemRenderer in the past.

 

So no one knows of any way to disable the ModelBakery from trying to find a json for every single Item that is registered to the GameRegistry?

[Anon10W1z]

I also have this problem, and I've looked in vanilla code to see if there was a workaround. I could not find one

[coolAlias]

Consider a vanilla example - dye.

// Item.java initializes the base Item with generic names:
registerItem(351, "dye", (new ItemDye()).setUnlocalizedName("dyePowder"));

// Items.java gets the generic instance and assigns it a reference
dye = getRegisteredItem("dye");

// ModelBakery.java attaches a list of all the subtypes, which are the 'real' items
this.variantNames.put(Items.dye, Lists.newArrayList(new String[] {"dye_black", "dye_red", "dye_green", "dye_brown", "dye_blue", "dye_purple", "dye_cyan", "dye_silver", "dye_gray", "dye_pink", "dye_lime", "dye_yellow", "dye_light_blue", "dye_magenta", "dye_orange", "dye_white"}));

// RenderItem.java registers each variant:
this.registerItem(Items.dye, EnumDyeColor.BLACK.getDyeDamage(), "dye_black");

The result of that is exactly what I want - no need for a 'dye.json' because that generic item doesn't really exist, but is useful within the code for retrieving the base version of the item.

 

However, there doesn't seem to be any way to specify variant names for custom items - using the ModelBakery#addVariantName method added by FML/Forge, the names are ADDED to what is already there, and whatever we register the item as to the GameRegistry seems to be automatically registered as a variant by FML, which is exactly what I don't want to happen.

 

Am I just missing something plain as day, or is it really designed to be this way?

[Anon10W1z]

I would try RenderItem.registerItem, specify metadata 0 and one normal model name, e.g. 0, "dye_black"

[coolAlias]

I would try RenderItem.registerItem, specify metadata 0 and one normal model name, e.g. 0, "dye_black"

That's a protected method. I could use reflection to gain access to it, but there must be a better way - it's not like dyes are a unique case, certainly not amongst mods, so it would make sense that FML has some way to support this, but I just can't seem to find it.

 

EDIT: I believe the issue stems from line 757 in GameData within the #registerItem(Item item, String name, int idHint) method, which is called by the GameRegistry when an item is registered:

((RegistryDelegate.Delegate<Item>) item.delegate).setName(name);

 

Then in ModelBakery, the following code adds all of the delegated item names to the variantNames:

for (Entry<net.minecraftforge.fml.common.registry.RegistryDelegate<Item>, Set<String>> e : customVariantNames.entrySet())
{
     this.variantNames.put(e.getKey().get(), Lists.newArrayList(e.getValue().iterator()));
}

 

The advantage of this is that if you register your item with the same name you will use for the texture, you don't have to do anything else, but there does not seem to be a way to avoid it, which doesn't make any sense given the existence of items such as dye.

[Anon10W1z]

I would go ahead and use reflection for RenderItem.registerItem. If there was another way, you or I would've found it by now.

[SuperKamiCatbug]

I had a similar situation with a metadata block. The different metadata values each had a different model, so I added them as variants but it was still looking for a json with the default name. I figured that it might just add a "default" variant using the unlocalized name when no other variants are specified, though I wasn't sure where in the code to look for where that would be happening (looks like you found where that is though). So I tried moving my variant additions from init to preinit, and it stopped looking for the "default" variant.

[coolAlias]

Well I'll be... I was doing it during the FMLInitializationEvent, since that's the first place it seems possible to register renderers (at least for items - mc.getRenderItem() is null during pre-init).

 

Anyway, adding the variant names during pre-init got rid of those annoying messages. Thanks!

 

EDIT 2: Actually, ignore the comment below. Adding variant names in the constructor is not only bad OOP, but ModelBakery is also client side only, so it would crash if run on a server. I need to go to bed

 

EDIT: To keep the code cleaner, I decided to put it at the end of my Item class constructor and that seems to work just as well:

public CustomItemClass(args[]) {
super();
// assign any class fields, then add variant name(s) at end:
ModelBakery.addVariantName(this, "actual_texture_name");
}

[SuperKamiCatbug]

Well I'm glad my meager amount of mod coding experience was helpful