[1.7.2] Render Custom Block Model as Item

[MasterVentris]

So I have created this jar model, and I would like it to be a 3D jar as an item in your hand and in inventories. As you can see I just get the untextured block.

 

I have seen in some example ClientProxy classes a method "MinecraftForgeClient.registerItemRenderer(<stuff>)" which looks like it does what I want. Has anybody used this who can explain how I use this method, and what else I need to put in other classes to make it work?

 

Thanks.

 

 

[Eternaldoom]

You need an item renderer class, and then in your ClientProxy:

        MinecraftForgeClient.registerItemRenderer(Item.getItemFromBlock(Your.Block), new ItemRendererYourItemRenderer(new YourTileEntityRenderer(), new TileEntityYourTileEntity()));

[MasterVentris]

Thanks for your help, with that and the following video by Vswe I have managed it.

 

 

[Mitchellbrine]

Just wondering... how else did you succeed to do this with Eternal's help? I try but I keep getting a flat icon instead of an untextured block.

[Eternaldoom]

Do you have an ItemRenderer class? If you make one, it shouldn't matter that the icon is flat, since you won't see it.

[Mitchellbrine]

I have an ItemRenderer class, my whole code worked back in 1.6.4, but now it seems to be flat-texturing. I got rid of any IIconRegister(s) and .setBlockTextureName("blahblahblah"), but it still does it.

[Mitchellbrine]

Nevermind, got it to work. Had some proxy issues with code order. Fixed, but still have a bug of it being rotated 180 degrees wrong.

[Father Of Time]

Nevermind, got it to work. Had some proxy issues with code order. Fixed, but still have a bug of it being rotated 180 degrees wrong.

 

Good afternoon,

 

I don't suppose you would be able/willing to specify on what issues you were having in your proxy; I am experiencing the exact same issue as you were (itemrender is being register, but it's using a flat 16x16 square with my texture on it as appose to the model) even though I am 100% certian the item renderer is being register. Also, further investigating I discovered that my renderItem method within my item renderer is never being called. You can see a visualization of this issue toward the end of this youtube video I recorded this morning:

 

 

Any thoughts on how I can resolve this issue? Just like with you it worked perfectly fine in 1.6.4, but in 1.7 it's a no go and the problem is persistant.

 

Thank you in advance to everyone in advance for your time and attention to this matter.

 

EDIT:

 

In heinsight I thought I should show you the code behind my problem, kind of hard to assist with a solution without it. 

 

I have a server proxy (common proxy) and a client proxy. The client proxy extends my server proxy, which is registered in my mod main class as follows:

 

//Server/Client stuff
    @SidedProxy(clientSide="org.moltenenterprises.dystopia.ProxyClient", serverSide="org.moltenenterprises.dystopia.ProxyServer")
    public static ProxyServer proxyServer;

 

Then in my mods initialization I call a "initialize" function inside my server proxy, which in turns calls those functions on both the client and server proxy (due to the client proxy extending the server proxy).

 

proxyServer.performRegistrations();

 

    public void performRegistrations(){
    	registerTileEntities();
    	registerTileEntitySpecialRenderer();
    	registerItemRenderers();
    	registerEntityRenderer();
    	registerFluids();
    	registerEntities();
    	registerTickHandlers();
    }

 

    @Override
    public void registerItemRenderers(){
    	MinecraftForgeClient.registerItemRenderer( Item.getItemFromBlock( BlockRegistry.blockGerminator ), new ItemGerminatorRenderer() );
    	MinecraftForgeClient.registerItemRenderer( Item.getItemFromBlock( BlockRegistry.blockATM ), new ItemATMRenderer() );
    }

 

Which registers the following item renderer:

 

package org.moltenenterprises.dystopia.blocks.germinator;

import org.moltenenterprises.dystopia.BlockRegistry;

import net.minecraft.client.renderer.tileentity.TileEntitySpecialRenderer;
import net.minecraft.item.Item;
import net.minecraft.item.ItemStack;
import net.minecraftforge.client.IItemRenderer;

public class ItemGerminatorRenderer implements IItemRenderer {

private final ModelBlockGerminator model;

public ItemGerminatorRenderer(){
	this.model = new ModelBlockGerminator();
}

@Override
public boolean handleRenderType( ItemStack itemStack, ItemRenderType type ){
	return true;//return itemStack.getItem() == Item.getItemFromBlock( BlockRegistry.blockGerminator );
}

@Override
public boolean shouldUseRenderHelper( ItemRenderType type, ItemStack item, ItemRendererHelper helper ){
	return true;
}

@Override
public void renderItem(ItemRenderType type, ItemStack item, Object... data){
	model.render( null, 0.0F, 0.0F, 0.0F, 0.0F, 0.0F, 0.0F );
	System.out.println( "REACHED!!!!!!!!!!!!!!!!!!!!!" );
}
}

 

However, the REACHED print statement you see above is never triggered... ever... Which is odd because if I put a print statement in the constructor of the ItemRenderer it does get called, and since the only place the itemRenderer is being instatiated is within the ItemRenderer registration (code above) I'm assuming it's registering properly...

 

There is only one thing that comes to mind that may be causing this issue... How the "Block" classes Equals() and Hashcode() methods are written... If you look at the new registration of ItemRenderers:

 

    	MinecraftForgeClient.registerItemRenderer( Item.getItemFromBlock( BlockRegistry.blockATM ), new ItemATMRenderer() );

...

    private static IdentityHashMap<Item, IItemRenderer> customItemRenderers = Maps.newIdentityHashMap();

    /**
     * Register a custom renderer for a specific item. This can be used to
     * render the item in-world as an EntityItem, when the item is equipped, or
     * when the item is in an inventory slot.
     * @param itemID The item ID (shifted index) to handle rendering.
     * @param renderer The IItemRenderer interface that handles rendering for
     * this item.
     */
    public static void registerItemRenderer(Item item, IItemRenderer renderer)
    {
        customItemRenderers.put(item, renderer);
    }

 

It simply stores the Item class as a key and the renderer as the value in a map. Now my past experience leads me to believe this may be the problem because comparing two like classes via hash and equals comparing (which is what is done when using contains or get on a map)  usually returns false because of how they compare the two objects. I am beginning wondering if the item that is being passed to the following method isn't equaling the one used during registration being passed in:

 

    public static IItemRenderer getItemRenderer(ItemStack item, ItemRenderType type)

    {

        IItemRenderer renderer = customItemRenderers.get(item.getItem());

        if (renderer != null && renderer.handleRenderType(item, type))

        {

            return renderer;

        }

        return null;

    }

 

...

 

    MinecraftForgeClient.registerItemRenderer( Item.getItemFromBlock( BlockRegistry.blockGerminator ), new ItemGerminatorRenderer() );

 

I don't suppose that anyone spots a solution to my issue with this additional information? Again, thank you in advanced for your input on the matter.

[TheGreyGhost]

Hi

 

If that is the problem, I'd suggest you add a breakpoint to the vanilla code for when it tries to find the renderer

MinecraftForgeClient::
    public static IItemRenderer getItemRenderer(ItemStack item, ItemRenderType type)
    {
        IItemRenderer renderer = customItemRenderers.get(item.getItem());
        if (renderer != null && renderer.handleRenderType(item, type))
        {
            return renderer;
        }
        return null;
    }

If you compare item with the customItemRenderers it should hopefully be clear what's going on.

 

-TGG

[Father Of Time]

If that is the problem, I'd suggest you add a breakpoint to the vanilla code for when it tries to find the renderer

...

If you compare item with the customItemRenderers it should hopefully be clear what's going on.

 

-TGG

 

Good afternoon TheGreyGhost,

 

Absolutely, that is exactly what I plan to do when I get home from work to hopefully shed some light on this issue; I just figured I would make this post to:

1) see if anyone can spot the issue before I get home to save myself a little digging

2) to document the issue if one exist so that others suffering from the same problem can find a remedy.

 

I will do as you have suggested and report back with my findings.

 

Thank you for your contribution to this issue. 

 

[Father Of Time]

Good afternoon all,

 

It appears that there may actually be a bug within the way custom item renderers are registered with Forge recommended build 1024. Again, I find it easier to show my issue rather than trying to explain it so I recorded the issue which can be found at the following link:

 

 

I don't suppose anyone notices an error with my methodology do they?

[TheGreyGhost]

Hi

 

A question - did you inspect customItemRenderers at your breakpoint to see whether your custom Item was in there?

-> if the customItemRenderers doesn't have any Germinator at all, there's something wrong with the registration

-> if the customItemRenderer has a Germinator but it's not the same object as the Item you're passing in (check the object address / ID) then you've registered something but it's not the right one.

 

I think hashCode and equals are not overridden for Items so the map will only match if the references are to the same object.

 

-TGG

[sequituri]

If your item is a block, then you have to specify your ItemBlock when you register the block, otherwise the system will create an ItemBlock for you and render that with default rendering.

 

Register as an Item if you want to use a custom item renderer. Render as a block if you want the block rendering as an item. I create a new ItemBlock subclass for every block on which I want to get rendering control over.

Then call the GameRegistry.registerBlock(myblock, MyItemBlock.class, "my_ore", myMod.MODID, (new Object[]{}));

 

Then in my ItemBlock class I can handle rendering and everything as the Item.