Choonster

It's a vanilla method that returns the greatest int less than or equal to the double argument. It's equivalent to calling Math.floor and casting the result to int .

Should the PR be closed, then?

Use ICommandSender#addChatMessage (implemented by EntityPlayer ) to send an ITextComponent chat message. The main implementations of ITextComponent are TextComponentTranslation (a translation key and format arguments) and TextComponentString (a string).

EntityLivingBase#getActiveHand only tells you which hand the entity is continuously using an item like a bow or shield from. It returns null if the entity isn't using an item. Item#onItemRightClick gives you the EnumHand containing the item as an argument, use this. I would also suggest switching your inventory to the IItemHandler capability. This will prevent having to read the contents from and write them to NBT every time you interact with the inventory.

There's an active pull request to add this here, it hasn't yet been merged.

Block#getMobilityFlag controls the reaction of the block to being pushed by pistons. By default, it returns Material#getMobilityFlag for the Block 's Material . Either use a Material with the appropriate EnumPushReaction or override the method to return the appropriate EnumPushReaction .

You can also register an IStateMapper using MoadelLoader.setCustomStateMapper to ignore the BlockLiquid.LEVEL property in your blockstates file. Create an instance of StateMap.Builder , call StateMap.Builder#ignore to ignore the property and then call StateMap.Builder#build to create the IStateMapper .

I am guessing that I have to declare my recipe as an IRecipe and then make it override IRecipe#getCraftingResult , correct? If so, I don't know how to do this, any examples? You'll probably want to create a class that extends an existing implementation of IRecipe like ShapedOreRecipe and then override IRecipe#getCraftingResult to call the super method, add the NBT and return the ItemStack . Use GameRegistry#addRecipe(IRecipe) to add an instance of this recipe class.

Ah, you are right. Now that I checked it again getColorFromItemstack does get properly called even when the item is in the crafting output grid. I must have been setting my debug breakpoints in wrong places, because I could have sworn it was never called. However, my next problem is that because I store the colour values (or to be more precise dyeColor metadata values) in item NBT, I am unable to retrieve them when crafting because the item did not have a chance to initialize it's NBTTagCompound. I do the initialization when the ItemCraftedEvent is fired. I would like to do the initialization in getSubItems but unfortunately that is not called until after the item has been crafted (pulled out of the crafting output slot). Any idea on how I should handle this? Set the NBT from IRecipe#getCraftingResult instead of ItemCraftedEvent . Events should generally only be used when dealing with things from vanilla or other mods, overriding the appropriate method should be preferred.

The colour returned by IItemColor is always used to render the item's model, regardless of where it is. You can see this by crafting a leather helmet with dye, the output item will be rendered with the appropriate colour. Post your Item and IItemColor .

Your block's model will be rendered with water surrounding it if its Material is Material.WATER. A lot of vanilla code expects blocks that use Material.WATER to have the BlockLiquid.LEVEL property, so your block needs to include this. It doesn't need to be saved to the metadata, just set the default value to 0 and override Block#getMetaFromState to ignore it. You can see an example of this here.

The registry name is a ResourceLocation , the domain of which ( ResourceLocation#getResourceDomain ) is the mod ID. You don't need to resort to string parsing.

You need to use IThreadListener from the network thread to schedule a task to run on the main thread. Forge's documentation explains this here.

You're missing an NBT tag. If you look at EntityFireworkRocket#handleStatusUpdate , you'll see it gets the "Fireworks" compound tag from the ItemStack 's compound tag before passing that to World#makeFireworks and ParticleFirework.Starter .

Vanilla already has an item cooldown system: CooldownTracker . I suggest you look for usages of this in vanilla code, e.g. ItemEnderPearl .

forge:multi-layer requires you to use Forge's blockstates format to specify the models it should combine, but you can use submodels instead of multipart blockstates.

I posted this in your other thread:

You can use the forge:multi-layer model to combine other models that are rendered in different layers. I explain this in more detail here.

As long as you register the event handler before the event is fired, it doesn't really matter when you do it. You can annotate a class containing static @SubscribeEvent methods with @Mod.EventBusSubscriber to have it automatically subscribed to the Forge event bus at mod construction time (i.e. before preInit and before the registry events are fired). On the rare occasion that you need non-static event handler methods or a different event bus, you can still manually register your event handler.

I don't know this in every situation, the itemSlot method argument will sometimes be passed as -1. Vanilla never calls Item#onUpdate with a negative slot number. Is the method being called from another mod?

You don't need to know whether the stacks are equal to each other (i.e. same Item , metadata, NBT and capabilities), you need to know whether they're the same object (i.e. use == ). You already know which slot the item is in, so you shouldn't need to scan every inventory slot; just check that slot of each section. You can do that (and PlayerInvWrapper does), but I'm not using that myself because I need to access each section separately.

I don't know what CombinedInvWrapper and RangedWrapper are, can you give me a simpler explanation? I am not a really experienced modder. CombinedInvWrapper combines multiple IItemHandler inventories into one. RangedWrapper exposes a range of slots from an IItemHandler inventory.

The difficulty is that Item#onUpdate will be called for items in any of the player's three inventory sections (main, armour and off hand), so you need to check which section it's in before trying to interact with that section. You can do this by checking if the ItemStack in the provided slot of the inventory section is the same as the provided ItemStack . I do this here. This doesn't handle the item being in the player's off hand. I see you use IItemHandler to interact with player inventory. What are the advantages of manipulating the inventory that way over using PlayerInventory? It allows you to simulate inventory changes and treat it the same as any other inventory, e.g. use it in a wrapper like CombinedInvWrapper or RangedWrapper .

This thread inspired me to fix the item I linked earlier to properly handle the off hand. You can see the new implementation here and here. I now use the latter method for all inventory handling in my Item#onUpdate implementations.

The difficulty is that Item#onUpdate will be called for items in any of the player's three inventory sections (main, armour and off hand), so you need to check which section it's in before trying to interact with that section. You can do this by checking if the ItemStack in the provided slot of the inventory section is the same as the provided ItemStack . I do this here. This doesn't handle the item being in the player's off hand.