Dynamic Item Registry

[cossacksman]

As of yet I've hated the messy standards of MinecraftForge development and I've taken to a more dynamic method of approaching item registry; my items do work and they're in the game with textures, localized names and all of the qualities I've given them but as soon as it comes to using them (for instance returning them when breaking a block) Forge fails to accept returning a new instance, for example..

 

        @Override
public Item getItemDropped(int metadata, Random random, int fortune)
{
	return new myClass();
}

 

I'll give you my registration in a spoiler but as I say, it registers fine but only seems to be able to be used if I use a static instance of it, if anyone has come across something similar it would be much appreciated if you could share what you found!

 

 

 

package com.cossacksman.qrpower.common;

import com.cossacksman.qrpower.common.blocks.WirelessAdapter;
import com.cossacksman.qrpower.common.items.WirelessReceiver;

import cpw.mods.fml.common.registry.GameRegistry;
import cpw.mods.fml.relauncher.Side;
import cpw.mods.fml.relauncher.SideOnly;
import net.minecraft.block.Block;
import net.minecraft.creativetab.CreativeTabs;
import net.minecraft.init.Items;
import net.minecraft.item.Item;

public class RegistryHandler 
{
public static CreativeTabs creativeTab;

public static Block[] blocks = {
	new WirelessAdapter()
};

public static Item[] items = {
	new WirelessReceiver()
};

public static void init()
{		
	creativeTab = new CreativeTabs("QRPower") {
		@Override
		@SideOnly(Side.CLIENT)
		public Item getTabIconItem() { return Items.ender_pearl; }
	};
}

public static void registerBlocks()
{
	for (Block block : blocks) {						
		GameRegistry.registerBlock(block, block.getUnlocalizedName());
	}
}

public static void registerItems() 
{
	for (Item item : items) {
		GameRegistry.registerItem(item, item.getUnlocalizedName());
	}
}
}

 

 

 

And I'll throw in the item class I'm testing with

 

 

 

package com.cossacksman.qrpower.common.items;

import com.cossacksman.qrpower.QRPower;
import com.cossacksman.qrpower.common.RegistryHandler;

import net.minecraft.item.Item;

public class WirelessReceiver extends Item
{
public WirelessReceiver ()
{		
	maxStackSize = 32;
	setUnlocalizedName("WirelessReceiver");		
	setCreativeTab(RegistryHandler.creativeTab);
	setTextureName(QRPower.MODID + ":" + "wirelessReceiver");
}
}

 

 

 

Edit: I can get around this by using the exact same method in a HashMap but I'd prefer not to.

[Draco18s]

Items are singletons, if you want to drop an item you need to pass a reference to the same Item you registered.

 

        @Override
public Item getItemDropped(int metadata, Random random, int fortune)
{
	return MyMainModClass.myCoolItem;
}

[cossacksman]

I feared as such, as much as I hate to say it I may stick with using a HashMap (Technically an anonymous class derived from HashMap) for now then, likely if I encounter more issues I'll just have to stick to the old true and tested method. Thanks for the heads-up on the singleton pattern used here.

[stucuk]

I don't understand your dismay. Items / Blocks are not actually Items / Blocks. They are types. Blocks.stone defines the type of block that is stone. Items.stick defines the type of item that is a stick. Every time you create a new Item / Block instance you define a new type.

I think your wording is a bit confusing. The word "Type" generally in programming means the type of object/variable (As in what class it is or if its an integer/string/etc).

 

There is only ever one single instance of each Block/Item Class which is what you register. Every Block/Item in the world only uses that one single instance (Which is why you can never store any information in the Block/Item class directly since its shared). With TileEntities on the other hand you have one instance per Block in the world which exists(Which is why you can store information in them directly since it isn't shared).

 

So in short, you only need 1 instance of a Block which you then give to other code which requires a block as an input. The Block is just a shared instance that contains no personal information about the block.

[jabelar]

Basically it is correct use of the English word "type" even if it isn't really correct for computer language definition of "type".

 

However, since we're discussing computer programming probably better to stick to the classic definitions ...

 

But it is difficult sometimes to explain to people the concept of why Items and Blocks are singletons without resorting to the English definition of the world type. Because the end result is you want to create a "type" of ItemStack and you do that by associating it with the relevant Item. So the Item associated defines the "type".