Choonster

Use ModelLoader.setCustomModelResourceLocation or ModelLoader.setCustomMeshDefinition in preInit instead of ItemModelMesher#register in init. ModelBakery.registerVariantNames takes arguments in the same format as ModelBakery.addVariantName ( "modid:modelName" ), but expects either ResourceLocation s or ModelResourceLocation s instead of String s.

If you use ItemColored for the block's item form, Item#getColorFromItemStack is overridden to call Block#getRenderColor with the state corresponding to the item metadata.

World#setBlockState and World#getBlockState only operate on property values that are stored in metadata. If you want to store more than 16 unique value combinations, you need to store the data in a TileEntity (or derive it from the location, e.g. neighbouring blocks) and then retrieve it in Block#getExtendedState / Block#getActualState .

You're returning true (item is valid for slot) when there's already an item of that type in the inventory and false (item isn't valid for slot) when there isn't.

Use ModelLoader.setCustomModelResourceLocation / ModelLoader.setCustomMeshDefinition in preInit to set the model used by an Item . This can either be an existing model like minecraft:diamond_sword or your own model that uses the same textures as the existing one ( minecraft:items/diamond_sword ).

ItemStack#getIsItemStackEqual is client-only, using it in common code will crash the dedicated server. If you only care about the Item , use ItemStack#getItem and compare the Item s directly. If you care about the Item and metadata, use ItemStack.areItemsEqual . If you care about the Item , metadata and NBT, use ItemStack.areItemStacksEqual . Nope http://pastebin.com/HkrTfcia That is a NullPointerException .

If you look at assets/minecraft/models/block/grass.json, you'll see that it sets the "tintindex" property for the "up" face of the first element (the base cube) and all faces of the second element (the side overlay). This allows the textures of those faces to be coloured and is passed as the renderPass argument of Block#colorMultiplier(IBlockAccess, BlockPos, int) .

Vanilla handles the FOV modification for the bow in AbstractClientPlayer#getFovModifier , this also fires FOVUpdateEvent .

Do you have missing texture errors in the log? Your model's texture paths don't have a resource prefix, so it's trying to load them from the minecraft domain.

You need to subscribe to FOVUpdateEvent to modify the FOV like the vanilla bow does if the player is using your bow. You can see how I do this here.

Ah, that makes things trickier. You may be able to use ISmartItemModel to render the bar, but I don't know enough about rendering or the model system to help you any further.

Use SlotItemHandler instead of Slot .

For BlockLiquid , metadata 0 is a source block. Forge's Fluid system doesn't specify that fluids must have a source block ( BlockFluidClassic does, but BlockFluidFinite doesn't) , but IFluidBlock#drain should return a FluidStack with FluidContainerRegistry.BUCKET_VOLUME as the amount if a bucket can be filled from the block. Make sure you call IFluidBlock#canDrain first and call IFluidBlock#drain with false as the doDrain argument.

Override Item#showDurabilityBar to return true when the current RF is less than the maximum and Item#getDurabilityForDisplay to return the percentage of the durability bar to fill (i.e. (maxRF - currentRF) / maxRF ).

WorldSavedData is loaded on demand and should be available as soon as the World has been constructed, but TileEntity#readFromNBT is called before the TileEntity exists in any World .

Yes, it's called by Chunk#setBlockIDWithMetadata , which is called by World#setBlock . This is used to place blocks in the world by everything except the initial terrain generation ( BiomeGenBase#genTerrainBlocks ), which deals with raw Block and metadata arrays that later become an actual Chunk . No, the TileEntity is only created after Block#onBlockAdded is called. If you use per-dimension WorldSavedData , you can store the positions of each block instead of the TileEntity objects.

No. That's a static method that takes three arguments and does absolutely nothing. You need to call the getX , getY and getZ methods on the BlockPos you get from the MovingObjectPosition . Calling methods is a very basic concept in Java. If the ray trace doesn't hit anything, the returned MovingObjectPosition will be null . If it hits an entity instead of a block, the BlockPos will be null . This means that you need to check that the MovingObjectPositon isn't null and that it hit a block (the MovingObjectPosition#typeOfHit field is MovingObjectPosition.MovingObjectType.BLOCK ) before you try to get the BlockPos from it.

getBlockPos returning null wouldn't cause an error on that line. The error is happening because the value you're calling getBlockPos on ( objectMouseOver ) is null .

You can probably take a similar approach to the one I recommended in this thread.

Do you understand why that's causing an error and how you can solve this? That's definitely not right. I didn't tell you to copy-paste the methods and fields into your own class, I told you to call the existing methods.

This is a NullPointerException , which I explained in a previous post. How about you read that and figure out for yourself what's causing the error? We can't do all of your debugging for you.

That's one of the methods you need to call, yes.

On the server side, every EntityPlayer is an instance of EntityPlayerMP (or a subclass of it).

Vec3i has getX , getY and getZ methods that return the x, y and z coordinates respectively. These are getter methods, a very common pattern in Java. There's not much we can do to help you if you can't understand us and don't know Java.

I can't spoon feed you every piece of information. At some point, you're going to have to learn Java properly if you want to make a mod.