Choonster

If you're just recolouring a greyscale texture with a single colour, you don't need to generate a texture. Simply override Block#getBlockColor , Block#getRenderColor and Block#colorMultiplier . If the colour should be determined at runtime, store it in a field.

See this thread.

See this thread.

You never initialise the myStacks field. You also never read it from or write it to NBT, do this using the INBTSerializable methods implemented by ItemStackHandler . I suggest you remove the ItemStack array field and the IInventory methods.

You never initialise the myStacks field. You also never read it from or write it to NBT, do this using the INBTSerializable methods implemented by ItemStackHandler . I suggest you remove the ItemStack array field and the IInventory methods.

I think this is caused by your getMetaFromState method. Metadata should simply be radius - 1.

I think this is caused by your getMetaFromState method. Metadata should simply be radius - 1.

Don't implement IItemHandler on your TileEntity , create a field storing an implementation of it (e.g. ItemStackHandler ) and expose it as a capability (by overriding the ICapabilityProvider methods inherited by TileEntity ). I do this in [url=https://github.com/Choonster/TestMod3/blob/d326040ffd81cf942de5ddaebc9c5ed866f1dd33/src/main/java/com/choonster/testmod3/tileentity/TileEntityItemHandler.java]TileEntityItemHandler[/url] .

Don't implement IItemHandler on your TileEntity , create a field storing an implementation of it (e.g. ItemStackHandler ) and expose it as a capability (by overriding the ICapabilityProvider methods inherited by TileEntity ). I do this in [url=https://github.com/Choonster/TestMod3/blob/d326040ffd81cf942de5ddaebc9c5ed866f1dd33/src/main/java/com/choonster/testmod3/tileentity/TileEntityItemHandler.java]TileEntityItemHandler[/url] .

Yes, the class I linked does that. IRecipe#getRecipeOutput returns the recipe's output, but each recipe type has a separate way to get the input.

Yes, the class I linked does that. IRecipe#getRecipeOutput returns the recipe's output, but each recipe type has a separate way to get the input.

Override Block#getBlockLayer to return CUTOUT or TRANSPARENT . The Grey Ghost explains each layer here. Block#isOpaqueCube is used by Block#doesSideBlockRendering / Block#shouldSideBeRendered to determine whether the faces of adjacent blocks should be rendered (opaque blocks block rendering, transparent blocks don't).

I have a class that replaces vanilla/Forge recipes here, though it's for 1.7.10. Each recipe class needs to be handled individually and I specifically prevent it from replacing subclasses because they may have their own custom behaviour.

I have a class that replaces vanilla/Forge recipes here, though it's for 1.7.10. Each recipe class needs to be handled individually and I specifically prevent it from replacing subclasses because they may have their own custom behaviour.

I can't see any obvious errors in your code, try stepping through the IInventory methods or the NBT reading/writing methods in a debugger and see if anything goes wrong. Side note: You shouldn't be using IInventory in 1.8.9+, you should be using the IItemHandler capability. I have an example of a chest that uses IItemHandler here (all other classes used are in the same repository). This includes the naming and loot generation features of vanilla chests, but not the animated model. You also shouldn't be using the deprecated GameRegistry.registerBlock or registering your blocks in init. Use GameRegistry.register in preInit to register all IForgeRegistryEntry implementations (e.g. Block , Item , Biome , SoundEvent ). This won't register an ItemBlock for your Block , you need to do that yourself.

I can't see any obvious errors in your code, try stepping through the IInventory methods or the NBT reading/writing methods in a debugger and see if anything goes wrong. Side note: You shouldn't be using IInventory in 1.8.9+, you should be using the IItemHandler capability. I have an example of a chest that uses IItemHandler here (all other classes used are in the same repository). This includes the naming and loot generation features of vanilla chests, but not the animated model. You also shouldn't be using the deprecated GameRegistry.registerBlock or registering your blocks in init. Use GameRegistry.register in preInit to register all IForgeRegistryEntry implementations (e.g. Block , Item , Biome , SoundEvent ). This won't register an ItemBlock for your Block , you need to do that yourself.

EntityLivingBase#getItemStackFromSlot

EntityLivingBase#getItemStackFromSlot

In 1.9, block/block defines the standard display transformations for block models. This is extended by all full cube models (e.g. block/cube and block/cube_all ). Similarly, item/generated extends builtin/generated and defines the standard display transformations for simple item models. You only need to define display transformations yourself when your model has a custom shape or you want it to be displayed differently to normal models.

In 1.9, block/block defines the standard display transformations for block models. This is extended by all full cube models (e.g. block/cube and block/cube_all ). Similarly, item/generated extends builtin/generated and defines the standard display transformations for simple item models. You only need to define display transformations yourself when your model has a custom shape or you want it to be displayed differently to normal models.

As it says in the error message, it's using the JAVA_HOME environment variable; not PATH . Set this to your JDK path.

As it says in the error message, it's using the JAVA_HOME environment variable; not PATH . Set this to your JDK path.

Do you actually understand what your code is doing? You're creating a new ItemStack of MAItems.SoulHarvester and then immediately checking if it's an ItemStack of MAItems.SoulHarvester . This will always be true , so it's completely pointless. You need to get the entity that did the killing from the DamageSource and then check its held item (like diesieben07 told you in the first reply). For random chances, use Random#nextInt to generate a random number, then check if it's in a specific range; e.g. random.nextInt(100) < 10 will be true 10% of the time.

Do you actually understand what your code is doing? You're creating a new ItemStack of MAItems.SoulHarvester and then immediately checking if it's an ItemStack of MAItems.SoulHarvester . This will always be true , so it's completely pointless. You need to get the entity that did the killing from the DamageSource and then check its held item (like diesieben07 told you in the first reply). For random chances, use Random#nextInt to generate a random number, then check if it's in a specific range; e.g. random.nextInt(100) < 10 will be true 10% of the time.

How you add functionality depends on the functionality you're adding. In this case, there's no event for block collisions so you'll need to subscribe to either PlayerTickEvent (fired only for players, make sure you check the event's Phase before running your code) or LivingUpdateEvent (fired for all living entities). In your event handler, iterate through all blocks inside the entity's bounding box (see Entity#doBlockCollisions ) and check if each one is a rose bush before damaging the entity.