Choonster

Yes, the JAR without a suffix is the compiled mod.

EnderIO has an experimental 1.8.9 version, the source of which is available on GitHub. I think the proper way to do this is with a custom IModel and ItemOverrideList , like Forge's ModelDynBucket . For a limited number of variants (e.g. a single bar with 10 steps), you can do what RFTools does: manually create the textures and then use them with standard models. Edit: Added a missing word.

Use World#notifyBlockUpdate . You can see an example of this here.

Ex Astris requires Java 7 or newer, you're using Java 6. Java 6 and 7 are both very outdated at this point, you should be using Java 8.

You need to add the srcCompat and targetCompat (not sourceCompatibility and targetCompatibility ) properties in the main body of build.gradle, after the buildscript and plugins blocks. You can see an example of this here.

Use Item#setMaxDamage to set the maximum damage of an item. To stop an item from providing AttributeModifier s, you can set the "AttributeModifiers" key of the ItemStack 's compound tag to an empty list tag. You'll probably want to do this in either LivingUpdateEvent (to affect all living entities) or PlayerTickEvent (to affect players). You can probably just modify the entity's held items and not worry about their inventory.

The big red text on the home page says to post fml-client-latest.log, not latest.log.

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.