Choonster

RenderItem#renderQuads uses the quad's tint index to get the colour from ItemColors (i.e. the IItemColor registered for the Item ). If anaglyph mode is enabled, TextureUtil.anaglyphColor is used to translate the colour into an anaglyph colour. I don't know enough about the rendering system to say what happens when a colour is applied to a quad without a texture.

There don't seem to be any errors in the log, I'm not too sure what's going wrong.

The tint index is passed to IBlockColor / IItemColor so they know which part of the model is being coloured and can return the appropriate colour based on that. I believe the TextureAtlasSprite is a location on the block texture sheet to render on the quad (i.e. the quad's texture).

Create a class that extends EntityItem and overrides isEntityInvulnerable to return true . This makes the item entity immune to all damage. In your Item class, override the following methods: Item#hasCustomEntity to return true Item#createEntity to create an instance of your EntityItem class with the specified location and ItemStack Item#getEntityLifespan to return Integer.MAX_VALUE This will spawn an invulnerable EntityItem with a lifespan of 2^31-1 ticks or approximately 3.4 years. If you want an item that actually never expires, you'll need to override EntityItem#onUpdate to do exactly the same thing as the existing method and its super method but not check the age/lifespan.

Have you definitely got the built JAR in the server's mods folder? If you open the built JAR in an archive viewer (e.g. 7-Zip) or Java decompiler (e.g. Bytecode Viewer), are all of your compiled classes present? Does the FML log (logs/fml-server-latest.log) mention your mod? If you're not sure, upload it to Gist and link it here. In future, please use Gist or Pastebin to post logs/crash reports (if applicable) and code with syntax highlighting rather than posting screenshots. To get syntax highlighting on Gist, give each file the appropriate extension (.java for Java code). To get syntax highlighting on Pastebin, select the language from the dropdown at the bottom of the page.

Are there any errors in the log? Upload the full FML log (logs/fml-client-latest.log) to Gist and link it here.

What you've posted should work in 1.8.

The ItemCameraTransforms.TransformType enum describes the valid transform types for items. HEAD is used to render the item on entity heads, GROUND is used to render the item as an EntityItem and FIXED is used to render the item in item frames.

Like I said, what diesieben07 is talking about doesn't exist in 1.8. It was added in 1.8.9. This is how I register the Render for my arrow entity in 1.8.9. This uses Java 8's method references, you'd use an anonymous class instead if you were targeting Java 6/7. This is how I register it in 1.8.

From the EAQ:

The OP is still using 1.8 rather than 1.8.9, so IRenderFactory and the corresponding registration don't exist for them. I would suggest updating to 1.8.9 or 1.9 and using the method diesieben07 mentioned.

The new stacktrace confirmed that it's caused by not being able to find the model file rather than being caused by something like a syntax error within it. However, I'm not too sure why it's not loading any of your assets. You could try exiting IDEA, deleting your project by running gradlew cleanIdea from the command line and then re-importing build.gradle into IDEA; though I can't guarantee that this will fix anything. You may not always be able to find tutorials for the latest version of Minecraft since they're just written by random members of the community. 1.9 is still quite new, so it may take a while for new tutorials to be made and old ones to be updated. A lot of core concepts have remained the same across many versions of Minecraft, so even older tutorials may still partially work. 1.8 introduced the model system for blocks and items, it's still mostly similar in 1.9. The registry system has been overhauled in recent 1.9 versions of Forge, but it looks like you're already using the new system. You can find Forge's official documentation here. This isn't a comprehensive guide to every part of Minecraft/Forge, but it does cover a few of the major concepts. Sometimes you just have to read through the Minecraft/Forge code to figure out how various parts of it work.

What diesieben07 said is correct, but I suspect it may not be the cause of this particular error. Forge improved the error reporting for item model loading in 1.9-12.16.0.1837-1.9 (this commit), update to the latest version of Forge and post the new error.

It sounds like you're using a static field instead of an instance field. We can't do much more than guess without seeing your code. If you want more help, upload the TileEntity class to Gist/Pastebin with syntax highlighting and link it here.

ItemAxe can no longer be used with custom ToolMaterial s due to hardcoding the attack damage/speed for each ToolMaterial and using the ToolMaterial 's ordinal as an array index. See this issue for more details and an explanation of what the current plans to fix this are. In the meantime, extend ItemTool and use Item#setHarvestLevel to set the tool class to "axe" and the harvest level to the ToolMaterial 's harvest level. Some issues with your code that aren't directly related to axes: Use the new GameRegistry.register method instead of GameRegistry.registerItem / registerBlock . If you can't see it, update Forge. Don't use unlocalised names as registry names, the registry name methods were introduced in 1.8.9 to stop people doing that. If an Item should have the same registry and unlocalised names, set the registry name ( IForgeRegistryEntry#setRegistryName or one of the overloads from IForgeRegistryEntry.Impl ) and then set the unlocalised name to the full registry name ( IForgeRegistryEntry#getRegistryName ). This also applies to Block s. As an example, setRegistryName("foo"); setUnlocalizedName(getRegistryName().toString()) results in the registry name being modid:foo and the full unlocalised name being item.modid:foo.name . Most of my mod's Item s use this method to set their registry and unlocalised names, but some have completely separate registry and unlocalised names that they set manually (e.g. records). Don't use ItemModelMesher#register to register models, use ModelLoader.setCustomModelResourceLocation / setCustomMeshDefinition in preInit. Don't use unlocalised names for model registration. The default model for every Item is the one with its registry name.

There's also a reference for the grammar of the Animation State Machine files used by the system here.

Every sound name in your sounds.json file is automatically prefixed with your mod ID. The registry name and sound name of your SoundEvent should be the same ResourceLocation , which should include your mod ID. You can see my mod's SoundEvent registration here and the sounds.json file here.

I can't help you much further, but I did find this Gist a while back that explains the grammar of the Animation State Machine files.

It was a missing [nobbc][/quote][/nobbc] tag in my post, nothing to do with the code.

You haven't created a new array for RGB here, it's pointing to the same array as DEFAULT_RGB . Any changes made through RGB will be visible from DEFAULT_RGB and the RGB field of all other instances of this class. Either create the default array in the RGB field's initialiser or use Arrays.copyOf to create a copy of the DEFAULT_RGB array and assign this to RGB . Edit: Add missing closing tag.

The subclasses of PlayerUseItemEvent are only fired for items that used while right click is held, e.g. charging/firing bows, eating food, blocking with swords. PlayerInteractEvent is fired with Action of RIGHT_CLICK_BLOCK when the player right clicks a block. KeyBinding s are client-only, but any persistent changes to the world (e.g. placing blocks) must be made from the server side. You need to send a packet to the server when the player right clicks a block with the key held. When the server receives this packet, check if the player is allowed to place the block (e.g. the target position is in range, the player has unlocked this ability) and then place it. This site explains networking, including how to use the Simple Network Wrapper (which you'll need to use here).

I suggest you share your findings so other people with the same problem can find the solution.

That should work, yes. That is indeed redundant. As the name suggests, PlayerTickEvent is only fired for players.

If you're not using the latest version of Forge, update. Recent versions overhauled the registry system, adding the GameRegistry.register method to register any IForgeRegistryEntry object (e.g. Block , Item , BiomeGenBase ).

Post your new code.