Choonster

I remember having similar issues converting the Vanilla transform format to the Forge format back in 1.8.9, I never fully figured out how to solve them. You could try calling TRSRTransformation.blockCenterToCorner or TRSRTransformation.blockCornerToCenter on the TRSRTransformation to see if that produces the correct values, but I'm not sure if it will. Maybe someone with more knowledge of the model system can help here.

Yes, Forge's TRSRTransformation (used in Forge's blockstates format) is different to Vanilla's ItemTransformVec3f (used in Vanilla item models). I don't fully understand the model system, but I think you can use the TRSRTransformation(ItemTransformVec3f) constructor to convert an ItemTransformVec3f to a TRSRTransformation. You can then use TRSRTransformation#getTranslation, TRSRTransformation#getLeftRot, TRSRTransformation#getScale and TRSRTransformation#getRightRot to get the values for the "translation", "rotation", "scale" and "post-rotation" keys in the blockstates file. Forge has a method to convert an entire ItemCameraTransforms object into a Map<ItemCameraTransforms.TransformType, TRSRTransformation> (PerspectiveMapWrapper.getTransforms(ItemCameraTransforms)), but I don't think you want to use this because it converts each TRSRTransformation from centre-block to corner-block and Forge's blockstates loader applies the same conversion when loading the TRSRTransformations from the blockstates file (so you'd apply the conversion twice, probably resulting in incorrect values).

Yes, it also allows the mod that adds the command to cleanly handle the logic for each sub-command without jamming them all into one class. CommandTreeBase is relatively new (added in commit 4e3b6b0 on 2016-09-13), so some mods may be using their own similar implementation for commands with sub-commands.

If the other mod's command extends CommandTreeBase, you could use CommandTreeBase#addSubcommand to add a sub-command to it.

You have two classes registering entities for the same mod, each with their own ID counter. This means that you register two entities with ID 1, two entities with ID 2, etc. When you spawn an entity on the server, FML sends the ID to the client so it can spawn the entity. If you have multiple entities with the same ID, the client will spawn a different entity to the server. Either register all of your entities in the same class or use the same ID counter for both classes. Why are you maintaining your own ID to name maps? Why do you have copies of EntityRegistry.addSpawn/removeSpawn? You cannot reference client-only classes (like models) in common code, you need to use proxies. You should be registering IForgeRegistryEntry implementations (Block, Item, Biome, etc.) in the corresponding registry events rather than in preInit. Doing this will make it easier to update to 1.12.x, where GameRegistry.register is private. In future, please post one class per code block or post your code using Gist/Pastebin (one class per file in a Gist or one class per Pastebin paste). Alternatively, create a Git repository for your mod and push it to a site like GitHub.

Forge's blockstates file doesn't use that format for display transformations, only Vanilla item models do. I briefly explain display transformations in Forge's blockstates format here: In addition to specifying a base TRSRTransformation in the "transform" object, you can specify a TRSRTransformation for each ItemCameraTransforms.TransformType ("thirdperson_righthand", "firstperson_lefthand", "gui", etc.). The complex example I linked in the quoted post uses this to specify a TRSRTransformation for "thirdperson" (which Forge treats as an alias of "thirdperson_righthand") and "gui".

You're calling Gui#drawTexturedModalRect once when the GUI is first opened, which does nothing. You need to call it every frame (in your override of GuiScreen#drawScreen).

JSON recipes were only added in 1.12, you're using 1.11.2.

Not supported doesn't mean that it's not possible to make mods for 1.7.10, it just means that you won't get help with it on this site.

I'm not familiar with the plugin, do you not have access to the Gradle window?

The damage hasn't been calculated when AttackEntityEvent is fired, use LivingHurtEvent instead.

Run the build task from IDEA's Gradle window or the command line. The compiled JAR will be in build/libs.

You didn't answer diesieben07's question. Did you build the JAR using IDEA's build system or did you build it using the build Gradle task? Only the latter is correct.

Item#setDamage sets the ItemStack's damage to the specified amount. You call it with 1, so it sets the ItemStack's damage to 1. The method you want is ItemStack#damageItem, which increments the ItemStack's damage by the specified amount. Calling with 1 will add 1 to the damage. Side note: Don't use Item#setDamage directly, use ItemStack#setItemDamage when you want to set the ItemStack's damage instead.

Then you'll need to handle each recipe class individually. For Vanilla's shaped/shapeless recipes, look for a field containing the collection of ItemStack ingredients. For Forge's ore recipes, look for a field containing the collection of Object ingredients. Each Object can be either an ItemStack or a List<ItemStack>. I strongly recommend updating to 1.12.1.

Which version of Minecraft are you using? In 1.12+, use IRecipe#getIngredients to get a list of Ingredients in a recipe and Ingredient#getMatchingStacks to get a list of ItemStacks matched by an Ingredient. IRecipe#getIngredients returns an empty list for special recipes with harcoded ingredients (e.g. RecipeBookCloning, RecipeFireworks, etc.), it only returns a non-empty list for recipes that use a collection of Ingredient objects (e.g. ShapedRecipes, ShapelessRecipes, ShapedOreRecipe and ShapelessOreRecipe).

The model you specified in the blockstates file doesn't exist.

Items and blocks no longer have textures, they now have models. Use RenderItem#getItemModelWithOverrides to get the model for an item.

Create a regular ItemStackHandler to store the inventory and use this in your Container. Create an IItemHandlerModifiable wrapper class that stores another IItemHandlerModifiable and delegates all methods to it except IItemHandler#extractItem. Implement this to always return ItemStack.EMPTY, preventing extraction from the wrapped inventory. Create an instance of this that wraps the regular ItemStackHandler and then expose this via your TileEntity's override of ICapabilityProvider#getCapability.

Forge has a model animation system, but unfortunately there's not much documentation on it. It was introduced in this commit, which briefly explains the purpose of some of the classes. The grammar of the Animation State Machine files is documented here. Forge has an example here (assets), there are also some examples linked here. This can animate JSON and B3D models, but unfortunately it can't animate OBJ models.

The root of the repository should be the root directory of your mod, i.e. where build.gradle and the src directory are. See my mod and its .gitignore file for an example of the repository structure to use and the files to include.

The model file you've told Minecraft to use doesn't exist.

Override TileEntity#shouldRefresh to return true only when the Block changes. This will allow the TileEntity to remain intact when the state changes but the Block is still the same.

You need to pass the entity's ID (Entity#getEntityId) as one of the int arguments of EntityPlayer#openGUI. In your GUI handler, use World#getEntityByID to get the entity from its ID.

Everything is in the source code. World generation isn't handled by the Block class, it's handled by dedicated world generation classes. If you look for usages of Blocks.DIAMOND_ORE, you'll see that it's used in BiomeDecorator#decorate to create a WorldGenMinable instance. This is later used in BiomeDecorator#generateOres to generate veins of Diamond Ore.