Choonster

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.

If the tick is happening on the server side and the Phase is correct (it doesn't really matter whether it runs in START or END as long as you pick one), increment your tick counter and check if the appropriate amount of ticks have passed. If you don't check the side and Phase , the handler will be called twice per tick per side for every player. You can't store the tick counter as a field of your event handler, since the same handler will be called for every player on the server. The more players there are, the more often one of them (there's no guarantee as to which one) will take damage. Event handlers are essentially singletons like Block s or Item s, so you can't store data for a specific object in their fields. The Entity#ticksExisted field stores the number of ticks the entity has been alive for. Use this instead of maintaining your own tick counter.

EntityLiving#tasks is initialised in the EntityLiving constructor, so you can add tasks in the constructor of your entity class (if you're spawning your own entity) or after the entity has been constructed (if you're spawning an existing entity with new AI tasks). If you're dealing with entities being spawned from external code (e.g. vanilla or other mods), you can't add tasks in EntityEvent.EntityConstructing as it's called from the Entity constructor before the EntityLiving constructor has run. The first event fired after the EntityLiving constructor has run is EntityJoinWorldEvent , which is the earliest you can add tasks in this situation.

Ah, I assumed you were using an IDE project generated by ForgeGradle. If you've created the project yourself it probably doesn't have the dependencies specified by ForgeGradle. If your mod and the mods it depends on (if any) aren't using any access transformers, you can find the compiled forgeSrc library in the Gradle cache: ~/.gradle/caches/minecraft/net/minecraftforge/forge/<forge_version>/<mcp_mappings_channel>/<mcp_mappings_version>/forgeSrc-<forge_version>.jar (replace ~ with %USERPROFILE% on Windows) If you are using access transformers, you can find the compiled forgeSrc library in your ForgeGradle workspace: <workspace_dir>/.gradle/minecraft/forgeSrc-<forge_version>-PROJECT(<project_name>).jar In both cases, the JAR containing the source code will be in the same directory with the -sources classifier.

Don't manually open any JARs. Your IDE project has a forgeSrc library as a dependency, this contains the Minecraft/Forge classes with the source code attached to them. Simply open a class in this library and your IDE will show you the deobfuscated source code. The JAR you tried to open is using SRG (semi-obfuscated) names, hence the srgBin classifier. build/tmp contains temporary files created by the build process, you should never need to use any of these files.

Block is a singleton, there is a single instance per block type shared between all blocks of that type. This means that you can't store per-position data in fields of your Block (or the position itself). Most methods of Block include the BlockPos of the block that's currently being affected/queried (or whatever it is that the particular method does).

Are you looking at the code in your IDE or manually opening a JAR? Your IDE should show you the deobfuscated source code when you open a vanilla class.

You didn't post the FML log or the crash report.

As it says on the Minecraft Forum thread and the download page:

You're confusing the blockstates format and the item model format. You can also use Forge's blockstates format instead of the vanilla format. Either use a blockstates file and move your model to models/block instead of models/item or set your OBJ model as the parent of your JSON item model.

You need to register your biome with GameRegistry.register in preInit, just like every other singleton class that implements IForgeRegistryEntry .