Choonster

ContainerEnchantment#canInteractWith checks if the block at its position is Blocks.enchanting_table and the player is within 8 blocks of it, so it can't be used with your block. You need to create your own Container that extends ContainerEnchantment and overrides canInteractWith to check for your block instead. You also need to create your own GuiContainer class that renders like GuiEnchantment but uses your Container instead of ContainerEnchantment .

Those are the flags for World#setBlockState . Vanilla seems to use the same values for World#notifyBlockUpdate ; but as I pointed out, only RenderManager (the client-side IWorldEventListener ) checks if flag 8 is set. PathWorldListener (the common IWorldEventListener ) and WorldManager (the server-side IWorldEventListener ) ignore the flags completely.

You'll need an IModel and ItemOverrideList as I said in my previous post. Probably an ICustomModelLoader as well. You'll also need a texture for each digit so you can generate the BakedQuad s for the number. I don't know that much about the rendering system, so I can't help you much more than this.

Vanilla mostly uses 3 but it looks like the only place the argument is actually used is in RenderGlobal#notifyBlockUpdate , which only checks if (flags & != 0 . This is false for 3, but true for Integer.MAX_VALUE . I don't fully understand the rendering code, but it looks like this value controls whether the RenderChunk updates now ( true ) or later ( false ).

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.