Choonster

You can read about attributes and modifiers here. You'll probably want to make a capability to manage the bonus health for each player.

In 1.11+, all resource file names must be lowercase and ResourceLocation coerces both the domain and path to lowercase. 1.10.2 allows you to have mixed-case resource file names and ResourceLocations, though the domain is still coerced to lowercase. I recommend using lowercase names anyway, since it will be easier to update to 1.11.2.

No, there's no ItemStack constructor that takes a String or ResourceLocation. Look at ItemMonsterPlacer.applyEntityIdToItemStack to see how it creates the required NBT structure. You can't call the method directly because it's client-only.

Your models don't have to use the item's registry name as their file name, that's just the default model that's loaded when you don't specify anything else. The closing brace on line 5 of your model file closes the "textures" object, but the top-level object is never closed.

I'm not sure what's causing the invisible trees, but I've submitted the PR for BonemealEvent here.

It may help to read Forge's documentation on sides, which explains the difference between physical and logical sides. I'm glad you found my explanation helpful.

Use ModelLoader.setCustomModelResourceLocation to register metadata-based item models. You need to call it in ModelRegistryEvent (if you're registering your Items in RegistryEvent.Register) or in preInit (if you're registering your Items in preInit). This needs to be done from a client-only class. I have an explanation of the model loading process and how ModelResourceLocations are mapped to model files here.

EntityLivingBase#getActiveHand is linked to EntityLivingBase#getActiveItemStack, it only returns the hand that the entity is actively using an item in. BonemealEvent doesn't actually give you the hand holding the bone meal (or the ItemStack), I'll try and submit a PR to fix this.

After changing the > to >= in your code, it correctly dropped a spawn egg in 1.11.2; though the spawn egg didn't have its entity set. I'd recommend using Entity#setDead rather than World#removeEntity. I'd recommend using the entity name NBT tag rather than using the global ID as the metadata, since this is what every version since 1.9 uses. In 1.8.x, set the entity_name tag to the entity's name (EntityList.getEntityString). In 1.9+, set the EntityTag tag to a compound tag with the id tag set to the entity's name (EntityList.getEntityString in 1.9-1.10.2, EntityList.getKey in 1.11+).

I forgot that it was only added in 1.11, so it doesn't exist in 1.10.2.

There is no Player class in Minecraft, you probably imported the one from the IXBM library. As @Kriptikz suggested, EntityPlayer is the class used by Minecraft to represent player entities.

These issues are still present.

RenderGameOverlayEvent#getType returns the ElementType.

When an egg damages an entity, DamageSource#getDamageType will return "thrown", DamageSource#getSourceOfDamage will return an instance of EntityEgg and DamageSource#getEntity will return the entity that threw the egg (if any).

Minecraft doesn't let you control how many levels an enchantment consumes, it's always 1, 2 or 3 depending on which slot of the enchantment table it's in. To add an enchantment, create a class that extends Enchantment and register it like any other IForgeRegistryEntry (i.e. IForgeRegistry#register in RegistryEvent.Register<Enchantment> or GameRegistry.register in preInit). Override Enchantment#getMinEnchantability and Enchantment#getMaxEnchantability to control the enchantablility and XP levels required to apply the enchantment. Create an EnchantmentType with EnumHelper.addEnchantmentType or override Enchantment#canApply/Enchantment#canApplyAtEnchantingTable to control which items the enchantment can be applied to. Override Item#canApplyAtEnchantingTable to control which enchantments can be applied to an item.

You're leaving your texture bound after your HUD is rendered, but GuiIngameForge expects the icons texture to still be bound. Don't subscribe to RenderGameOverlayEvent itself, subscribe to RenderGameOverlayEvent.Post and pick a specific ElementType to render your HUD after. Currently you're rendering your HUD before and after every element. Why not have your HUD extend Gui so you don't need to copy its methods?

ModelLoader.setCustomModelResourceLocation is the recommended way to register metadata-based item models. You need to call it in ModelRegistryEvent (if you're registering your Items in RegistryEvent.Register) or in preInit (if you're registering your Items in preInit). ModelLoader.setCustomModelResourceLocation calls ModelBakery.registerItemVariants for you, which tells Minecraft to load the model. ItemModelMesher#register doesn't do this. I have an explanation of the model loading process and how ModelResourceLocations are mapped to model files here. The client should work in single player even if you register the models from common code (i.e. not server-only or client-only), but this will crash the dedicated server. The FML log (logs/fml-client-latest.log) should tell you exactly what went wrong when loading your item models, post it. That's the only official documentation, but there's various bits of unofficial documentation floating around (e.g. my model loading process document or williewillus' primers, both on Gist).

In setCompostLevel, you're only setting READY to false when the existing LEVEL value is 0; you should set it to false when the new LEVEL value is 0 instead. Make sure you still set the new LEVEL value, even when it's 0. You're explicitly boxing, unboxing and casting the primitive values you pass to IBlockState#withProperty and receive from IBlockState#getValue; but there's no need to do this. Java will automatically box and unbox primitive values for you, there's no need to do it yourself. These methods are generic, so they will always use the IProperty's generic type argument as the parameter/return type without the need for casting.The only reason you see this in the vanilla code is because the compiler automatically generates it. Why are you calling World#setBlockState with flags to prevent the comparator output updating and then updating the comparator output manually? Just use the overload without the flags parameter. Why do you handle LEVEL >= 2 and LEVEL == 1 separately in onBlockActivated while doing exactly the same thing for both? You can use ItemHandlerHelper.giveItemToPlayer to insert an item into a player's inventory and drop the remainder on the ground; this saves having to call InventoryPlayer#addItemStackToInventory and EntityPlayer#dropItem.

That should work, I can't see any obvious errors. Could you post your whole Block class and the FML log (logs/fml-client-latest.log)?

There should be a very minimal performance hit if you're using a non-ticking TileEntity to store a value for a baked model. Using a ticking TileEntity or a TESR would be more expensive. Halving the integer property would allow you to store both values in the metadata.

Did you re-run the setup task (setupDecompWorkspace) like the comment tells you to? Did you refresh your IDE project (re-run the eclipse task or click the Refresh all Gradle Projects button in IDEA's Gradle window)? If you did and you got an error, post the Gradle log. You don't need to change any hashes.

I don't know exactly how to do this myself, but I suggest you look at FancyMissingModel to see how it renders text in a baked model.

To store multiple values in a single integer, you need to use bitwise operations. There are a lot of resources available that explain these, in addition to the vanilla code that uses them. I just realised that your integer property appears to have 11 values, which means that you can't store both it and the boolean property in the metadata. Metadata is limited to 4 bits (2^4 [16] potential values), but the highest value of the integer property (10) already occupies all 4 bits. You'll need to store one of the values in a TileEntity instead of the metadata. If you still need it to determine the block's model, you can keep the property and set it from the TileEntity's value in Block#getActualState instead of storing it in the metadata. You'll also need to override TileEntity#getUpdateTag and TileEntity#getUpdatePacket to sync this value to the client. Override TileEntity#onDataPacket to read the NBT data from the packet and call World#notifyBlockUpdate to redraw the chunk containing the block (so it draws the model for the new value). Call World#notifyBlockUpdate whenever this value changes to send the update packet to the client. You can see some examples of this here: Block classes: Coloured Rotatable , Coloured Multi-Rotatable TileEntity classes: Coloured Rotatable, Coloured Multi-Rotatable Blockstates files: Coloured Rotatable, Coloured Multi-Rotatable These blocks store their colour in the metadata and their facing(s) in the TileEntity.

Have you overridden Block#getStateFromMeta and Block#getMetaFromState to convert both properties to metadata and back?

1.0 is 100% drop chance, anything greater than that will be dropped even if the entity wasn't recently hit by a player and won't be damaged before it's dropped.