Choonster

Item#setContainerItem sets the container item for that Item instance globally, which means it now returns that item in every recipe rather than just yours. This probably isn't what you want to do. Either specify the recipe in a JSON file (recommended) or specify it in code, don't do both.

You'll need a custom recipe type that implements IRecipe#getRemainingItems to return a list of remaining items, using the container item (ForgeHooks.getContainerItem) for every slot except the one with the potion in it, which you'll use an empty bottle for instead. I recommend extending ShapedRecipes or ShapedOreRecipes so you don't have to re-implement everything yourself. To use this new recipe type from JSON recipe files, you'll need to create a class that implements IRecipeFactory to parse the recipe from the supplied JSON object. Specify this factory class in your recipes/_factories.json file. Look at the CraftingHelper.init method to see the IRecipeFactory implementations for the Vanilla and Forge recipe types.

Set @Mod#acceptedMinecraftVersions to the range of Minecraft versions your mod can run on. The version range format is documented in the doc comment of the VersionRange.createFromVersionSpec method.

You'd need to send your own packet to sync the dropper's inventory contents with the clients tracking it. There's no event fired when the inventory contents change, so you'd need to check every loaded dropper every tick to see if any of its inventory contents have changed since last tick. You should maintain a cache of each dropper's inventory contents using a custom capability. The dropper and other vanilla inventories are synced through Containers, since the inventory contents only need to be known on the client side when a player has the GUI open. This won't work for your purposes since you need to know the inventory contents at all times to render them on the block.

The client and server each have their own copy of the TileEntity, only the server-side TileEntity loads and saves the inventory from NBT. If you want access to the inventory on the client side, you need to sync it with the TileEntity's update packet and update tag.

You probably need to refresh your IDE project. I think the way to do this for Eclipse is by re-running the eclipse Gradle task. If you were using IDEA, you'd just click the Refresh all Gradle Projects button in its Gradle window.

Yes. You don't have to, I only have them there because my buildscript uses those variables. I do recommend doing something similar in your own buildscript. Yes, the source code from the repository will be linked to the JAR in your IDE.

Yes, once you've done that you don't need to manually download the Baubles JAR. Make sure you actually define the baubles_version variable somewhere (e.g. in gradle.properties). This is the tag or commit ID that you want to depend on.

Look at the net.minecraft.world.gen package for Minecraft's world generation classes. Structures like the Stronghold, Mineshaft and Nether Fortress are in the net.minecraft.world.gen.structure package.

You can use any Git repository (like Baubles) as a Maven dependency through JitPack. I do this in my mod here. You can also use CurseForge as a Maven repository through its API (see the Maven section).

Forge can load animations from B3D models, yes. You still need an Animation State Machine file that tells Forge about the clips, states, etc. I haven't used the system myself, you'll need to look at the examples I linked to see how things are done.

If Blender can export its models and animations to the B3D format, you should be able to use them in Forge. Otherwise you'll need to export to JSON models and animation files. You tell the Animation State Machine for the model when to transition to each state, the animation files tell it how to animate each transition.

It will work anywhere the model is rendered. The animation system doesn't let you change the position of the player's arms, though.

It looks like there's no explicit limit, so the limit is probably Integer.MAX_VALUE.

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.