Choonster

Methods that take an EnumHand argument (like Block#onBlockActivated ) are called once per hand.

NBT should only be used to save data, it shouldn't be used to store it at runtime.

Use the Capability system. For examples, you can look at the capabilities provided by Forge (look for usages of CapabilityManager#register ), the capability test mod or my own mod's capabilities (API, implementation).

You shouldn't need to cast the IItemHandler here, you should store it as its actual type in a private field. If you make it visible to other classes (through a getter method), it should only be as IItemHandler . As for how you store the item from Block#onBlockActivated , there are two options: The Block uses a getter method to get the IItemHandler from the TileEntity and the Block handles storing the item The Block tells the TileEntity that it was right clicked (by calling a method) and the TileEntity handles storing the item

Say I was trying to figure out if the player had a level 1/ level 2 buff of speed, how would I do that? I know the speed effect has the potion id 1, but what is the speed 2 id, or the speed 3/4? player.isPotionActive(1); For speed 1 player.isPotionActive(Speed_2)?? Which Minecraft version are you using? In 1.10.2, use EntityLivingBase#getActivePotionEffect to get the active PotionEffect of MobEffects.SPEED , then use PotionEffect#getAmplifier to get the amplifier. Note that amplifiers are 0-based, even though they're displayed as 1-based in-game.

Use EntityLivingBase#isPotionActive , EntityLivingBase#getActivePotionEffect or EntityLivingBase#getActivePotionEffects .

Minecraft uses ResourceLocation s to load assets, which automatically converts your mod ID to lowercase. This means that your assets folder must also be lowercase. Paths on Windows systems are case insensitive, so you may not notice this in the development environment; but paths on Unix-like OSes and in JARs are case-sensitive, so you will definitely notice it in the release environment. This localizes Wand but not TestItem: This localized Wand and TestItem: Are you saving the file as UTF-8 with the BOM? I'm pretty sure Minecraft expects UTF-8 without the BOM.

In your @Mod annotation, set clientSideOnly to true so it's only loaded by the client and set acceptableRemoteVersions to "*" so any remote version (including none) is accepted.

Once you've run a Minecraft/Forge version through the launcher at least once, the Minecraft client itself will be downloaded to the .minecraft/versions directory and Forge and the other libraries will be downloaded to the .minecraft/libraries directory. Why do you need the JAR content?

It's only possible to make a mod that supports several Minecraft versions at once if you don't interact with any part of the Minecraft/Forge code that's changed between versions. In practice, any mod that does something substantial is unlikely to work in multiple versions. The only practical way to support multiple versions is to maintain a separate copy of the code for each one. Git branches are a good way to do this. The exception to this rule is 1.10.2, which is 99% backwards compatible with 1.9.4. This means that most mods built for 1.9.4 will work in 1.10.2. Forge no longer supports 1.7.10 at all (threads about it are locked) and I believe support for 1.8.9 is dwindling. I would recommend updating directly to 1.10.2, the only version that's currently receiving bug fixes and enhancements.

You never account for storedItem being null . You need to check that it's not null before you call a method or access a field on it. Consider using an IItemHandler inventory to store the item, this will handle a lot of the item storage logic for you. If needed, you can extend ItemStackHandler (the standard IItemHandler implementation), override ItemStackHandler#insertItem to check if the ItemStack 's Item is valid before calling the super method (preventing invalid items from being inserted) and override ItemStackHandler#getStackLimit to limit the number of items that can be stored in each slot. Use the INBTSerializable methods implemented by ItemStackHandler to read from/write to NBT. If you want to allow automated inventory access later (by things like Hoppers and Item Conduits), you can expose the IItemHandler as a Capability.

When storedItem.stackSize reaches 0, set the storedItem field to nill .

Open the GuiPlayerTabOverlay class and navigate to the renderPlayerlist method. The first two lines retrieve the List<NetworkPlayerInfo> used to render the overlay.

ItemStack#writeToNBT returns its argument. In TileEntityBonfire#writeToNBT , you're passing the NBTTagCompoud argument to ItemStack#writeToNBT and then storing the return value (i.e. the argument) inside the argument. The NBT serialiser doesn't know how to deal with recursive references like this, so it throws an exception. The solution to this is to call ItemStack#writeToNBT with a new NBTTagCompound or call ItemStack#serializeNBT (implements INBTSerializable#serializeNBT ) which does this for you. In future, post the whole stack trace instead of just a snippet of it.

You should look at how GuiPlayerTabOverlay#renderPlayerlist retrieves the data that it renders. In future, please use [nobbc] [/nobbc] tags when posting code.

Vanilla uses ItemFood#setPotionEffect to set the potion effect of raw chicken and rotten flesh to Hunger, applied on a 30% chance for raw chicken and an 80% chance for rotten flesh. You can call this with 1.0f as the second argument to always apply a potion effect when eating a food item.

BlockContainer overrides Block#getRenderType to return EnumBlockRenderType.INVISIBLE , which prevents the block from being rendered via the model system. This is because vanilla renders a lot of its TileEntity blocks with a TileEntitySpecialRenderer . You could override this to return EnumBlockRenderType.MODEL , but there's no reason to extend BlockContainer at all. Instead, override Block#hasTileEntity(IBlockState) to return true and override Block#createTileEntity to create and return an instance of your TileEntity .

According to the wiki, registry names for blocks, items and entities will be case insensitive and autocomplete will use lowercase letters.

Then you don't know Java well enough to make a mod. Learn Java properly before trying to make a mod.

Create a class that extends Item and overrides Item#onUpdate . In your override, check if the entityIn argument is an instance of EntityLivingBase . If it is, cast it to EntityLivingBase and call EntityLivingBase#isPotionActive to check if it has the MobEffects.WITHER effect active. If it doesn't, create a PotionEffect and call EntityLivingBase#addPotionEffect to add it. Create and register an instance of this class instead of Item .

A ResourceLocation is composed of a domain and a path. A ModelResourceLocation is composed of a domain, a path and a variant. The ModelResourceLocation(String) takes all three as a string in the format "[domain]:[path]#[variant]" . The ModelResourceLocation(String, String) constructor takes the domain and path in the format "[domain]:[path]" as the first argument and the variant as the second argument. The ModelResourceLocation(ResourceLocation, String) constructor takes the domain and the path as the first argument (a ResourceLocation ) and the variant as the second argument (a string). You can set the ModelResourceLocation for an item using ModelLoader.setCustomModelResourceLocation / setCustomMeshDefinition .

EnumChatFormatting was renamed to TextFormatting . This renaming is documented on this issue tracker, which also documents most other renames since 1.9.

You installed a 1.10.2 version of Pixelmon on Minecraft 1.8.9. Mods usually only work in the version of Minecraft they were built for, which will usually be in the file name.

This will be enforced in 1.11, at the moment it's only a recommendation. The domain is already converted to lowercase when you create a ResourceLocation . As diesieben07 said, 1.11 will require all paths in a resource pack (which mod assets are added as) to be lowercase. Correct. Correct. Correct. This isn't currently required, but it may be in 1.11 as SoundEvent s store their name as a ResourceLocation . This isn't required, but the name and values will converted to lowercase when used in a ModelResourceLocation .

You'll have a much easier time if you learn to understand stack traces and exception messages. The crash report told you what where the problem was, you just needed to understand what could cause the problem.