Choonster

You'd need to use an AT or reflection to access the field, yes. I'd personally recommend using reflection to avoid modifying the vanilla code, but either method should work. Another way to gain access to the SoundManager instance without ATs/reflection is by subscribing to SoundSetupEvent and storing the instance. This is probably the best option.

The EventPacket no-argument constructor is private, but it needs to be public so it can be accessed by FML/Netty.

You're trying to access the field through the class (SoundManager) rather than an instance of it (the one stored in the private SoundHandler#sndManager field, you can use Minecraft#getSoundHandler to get the SoundHandler instance). It's not a static field, so you can't do this.

I'm not too sure. Try setting a breakpoint in the first loop in ModelLoader#loadItemModels (for(Item item : items), line 325 in my workspace) with the condition item == <your Item instance> and stepping through the code to see what's going on. If that fails, post your whole mod as a Git repository. Look at my mod and its .gitignore file for an example of the files to include. In the Referenced Libraries (Eclipse) or External Libraries (IDEA) section of the project window, there should be a library called forgeSrc-<forgeVersion>.jar that contains the code and assets from Forge and Minecraft. Eclipse can't actually open most files in JARs by default, you need to associate JSON files with the internal text editor (in Window > Preferences > General > Editors > File Associations) or install a plugin. You also need to install a plugin to view PNG files in JARs. IDEA can open JSON and PNG files in JARs by default and allows you to navigate to a file (including those in JARS) with Ctrl-Shift-N.

I completely missed the fact that this is an Entity rather than a TileEntity. Still, overriding Entity#readFromNBT and Entity#writeToNBT should work (though you're meant to override Entity#readEntityFromNBT and Entity#writeEntityToNBT instead).

That code should work, since TileEntity#writeToNBT writes its data to and then returns its argument.

You need to override Block#isFullCube to return false. This will stop players being pushed out of the block and stop them suffocating in the block.

RegistryEvent.Register and ModelRegistryEvent are both fired before preInit, so they need to be handled by static @SubscribeEvent methods in a class annotated with @Mod.EventBusSubscriber.

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).