[1.10.2][SOLVED] Better way of registering models for items and blocks?

[imacatlolol]

I'm having issues getting some of my models to work. I've decided that the best thing I can do is change how I register models.

 

At the moment, I use something like this and I load it in the initialization phase:

public static void registerRender(Item item) {
    Minecraft.getMinecraft().getRenderItem().getItemModelMesher().register(item, 0, new ModelResourceLocation(item.getRegistryName(), "inventory"));
}

public static void registerRender(Block block) {
    Minecraft.getMinecraft().getRenderItem().getItemModelMesher().register(Item.getItemFromBlock(block), 0, new ModelResourceLocation(block.getRegistryName(), "inventory"));
}

What would be a better alternative?

[Draco18s]

Yes.

https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/hardlib/client/ClientEasyRegistry.java#L120

[imacatlolol]

Yes.

https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/hardlib/client/ClientEasyRegistry.java#L120

Ha, that's much better, thanks!

[yooksi]

At the moment, I use something like this and I load it in the initialization phase:

Aren't models suppose to be registered in the pre-initialization phase?

[Draco18s]

At the moment, I use something like this and I load it in the initialization phase:

Aren't models suppose to be registered in the pre-initialization phase?

 

The way he was doing it, no.  ModelLoader.customModelLocation, yes.

[yooksi]

At the moment, I use something like this and I load it in the initialization phase:

Aren't models suppose to be registered in the pre-initialization phase?

 

The way he was doing it, no.  ModelLoader.customModelLocation, yes.

Hm, okay, I don't know much about registering models that way. Isn't the use of ModelLoader.setCustomModelResourceLocation over getItemModelMesher().register recommended by Forge conventions? At least I recall reading about that more then once here.

[Draco18s]

Hm, okay, I don't know much about registering models that way. Isn't the use of ModelLoader.setCustomModelResourceLocation over getItemModelMesher().register recommended by Forge conventions? At least I recall reading about that more then once here.

 

Yes, because using the ModelMesher directly has issues.  Which is why the ModelLoader method exists.

[derf6060]

What issues does getItemModelMesher() have over ModelLoader.setCustomModelResourceLocation. I've used getItemModelMesher since 1.8 came out and I have not had any issues with it so far.

[Draco18s]

From what I understand it has to be called in Init, but before some things and after others and was just prone to problems that if not properly dealt with would cause issues.

 

You might have code that works fine in 1.8, but you should update to using ModelLoader.setCustomModelResourceLocation on newer version of MC anyway.

[derf6060]

I'm actually using forge 1.10.2 and it works fine. Also I took a look at the ModelLoader to see what it is doing. It stores all of its values into 2 maps and defers the registration. After the initialization stages (I'm not real sure what stages it could be after or before post) forge calls onRegisterItems which registers both maps to ItemModelMesher.

 

That a pretty nice and clean way to handle it. I'm going to change over thanks for the explanation.

[derf6060]

Oh lol when I changed to it all item models didn't load so don't call that method during the initialization stage. It defers the model registration before initialization stage happens so make sure to pass all model information during pre initiliaztion stage lol.

[Draco18s]

Something something there will be problems.

[derf6060]

lol, oh yes there will be problems if you call the old way in pre initialization for example the client exploding or models not loading correctly. That pretty all the issues I ran into while using the old method of loading them models. The method is just the opposite. Its needs to be handled in pre initialization with the added benefit of adding information the the ModelBakery too. So you don't have to worry about variants it is already handled for you for the most part lol.

[yooksi]

lol, oh yes there will be problems if you call the old way in pre initialization for example the client exploding or models not loading correctly. That pretty all the issues I ran into while using the old method of loading them models. The method is just the opposite. Its needs to be handled in pre initialization with the added benefit of adding information the the ModelBakery too. So you don't have to worry about variants it is already handled for you for the most part lol.

 

Are there any advantages of using the old method over the new one?

[derf6060]

Well the old method has one major problem. If you had model variants you would have to explicitly register them with ModelBakery. The new method automatically registers all moddles with the ModelBakery which is fine. The old method also had issues if you called it in pre initialization method which either didn't load the models or other strange issues like the client blowing up on me one or twice because I didn't put them in the Initialization phase. Thats pretty much sums up the differences between the old way and the new way.

[yooksi]

Well the old method has one major problem. If you had model variants you would have to explicitly register them with ModelBakery. The new method automatically registers all moddles with the ModelBakery which is fine. The old method also had issues if you called it in pre initialization method which either didn't load the models or other strange issues like the client blowing up on me one or twice because I didn't put them in the Initialization phase. Thats pretty much sums up the differences between the old way and the new way.

 

All really good reasons to start using the new method.