Choonster

PlayerEvent.HarvestCheck isn't fired for blocks with a Material that doesn't require a tool (e.g. Material.WOOD ). To make logs require a tool to harvest, you need to subscribe to PlayerEvent.BreakSpeed (to slow down the breaking) and BlockEvent.HarvestDropsEvent (to remove the drops). I do something similar here, but this completely stops logs from being broken without the correct tool rather than just slowing it down and removing the drops.

The documentation explains WorldSavedData in more detail.

Update Forge.

Cryptbin refuses to load for me, I suggest uploading your log to Gist instead.

You've somehow managed to create two compiled classes annotated with @Mod using the same mod ID. Only one of these is present in your source code, so I suggest running the clean Gradle task and then re-running Minecraft. Your item/model registration code is quite messy and outdated. I explain how to properly register items and their models in 1.9 here.

I haven't found a way to generate JavaDoc for the mod and its libraries (including Forge) at the same time, but I don't really know much about the javadoc tool. You can probably generate JavaDoc for Forge by cloning the Forge repository, checking out the appropriate branch/commit, setting up the workspace and IDE project and then using your IDE's JavaDoc generation tool.

In 1.8.9, EntityPlayer#getItemInUse is client-only. You'll need to use reflection to get the value of EntityPlayer#itemInUse instead. In 1.9, EntityLivingBase#getActiveItemStack (the replacement for EntityPlayer#getItemInUse ) is usable from both sides.

Forge does have an animation system for baked models in the net.minecraftforge.client.model.animation package, though there's not a lot of documentation for it.

If you don't want to use JSON models, create your models in a mainstream 3D modelling program and export them as OBJ/B3D.

There are doc comments in the code itself, but Forge no longer offers a Javadoc download. You can generate one locally if you need to.

ServerConfigurationManager was renamed to PlayerList . You can see other name changes in 1.9 by searching here.

The vanilla bow uses ItemBow#findAmmo instead of InventoryPlayer#consumeInventoryItem . I created this method for my mod's bows to do the same thing using the IItemHandler API.

Model registration should be handled in your client proxy or a dedicated class called from it. Referencing client-only classes in a class loaded on both sides can easily crash the dedicated server with a ClassNotFoundException if you're not careful. diesieben07 has a post on why you shouldn't use @SideOnly here.

Set the ItemBlock 's registry name to the Block 's registry name. To handle custom ItemBlock classes, you can use a Function<Block, ItemBlock> argument (i.e. a function that takes a Block and returns an ItemBlock ) as a factory for the ItemBlock instance. I do this here.

Yes, create an IStateMapper and register it by calling ModelLoader.setCustomStateMapper . You can either implement IStateMapper yourself or create a StateMap.Builder , call StateMap.Builder#ignore for each property you want to ignore and then call StateMap.Builder#build .

Your block has two properties ( facing and triggered ), but your blockstates file only specifies variants for one of them ( facing ). You need to include both properties in your blockstates file.

Look at how BlockSapling or BlockDaylightDetector override Block#getBoundingBox .

Create a static final AxisAlignedBB field with the block's bounds and override Block#getBoundingBox to return it.

Call setBlockBounds in your constructor. Look at the method definition in the Block class for the arguments.

Item#getRegistryName already includes your mod ID. Don't add it again.

Refresh the project from the Gradle window (this is needed after running setupDecompWorkspace to allow the project to use the new Forge version), then synchronise the project from the Project window (this is needed after running genIntelliJRuns to bring up the prompt to reopen the IDE and use the new run configurations). You then need to edit the run configurations to use the classpath of the <ProjectName>_main module.

The RenderItem instance is created between preInit and init, so it can't be used in preInit. Instead of using ItemModelMesher#register , use ModelLoader.setCustomModelResourceLocation / setCustomMeshDefinition . These must be called in preInit. Never use getUnlocalizedName().substring(5) in your code. Registry names are IDs, they must not change. Unlocalised names can change at any time. The default model loaded for every Item is the one with its registry name, so use Item#getRegistryName as the default model location.

Right click somewhere in the Project window, then select Git > Repository > Branches in the context menu. Select the branch to checkout from the popup menu that appears.

Clone the repository, then checkout the desired branch using a Git client (e.g. IntelliJ IDEA, GitHub Desktop, command-line Git).

So equipping a vanilla saddle on a vanilla horse shows your subtitle? I can't reproduce this. In the process of writing a reply, I looked at your GitHub repository and noticed you'd already done it. If you encounter further problems with Git, try looking for the solution first. If you can't find it, post here and I may or may not be able to help you. Any further questions not directly related to the custom entity should probably be posted in a separate thread.