Choonster

Post the new blockstates file and FML log.

The only methods you need are ReflectionHelper.findField and ReflectionHelper.findMethod, which replace Class#getDeclaredField and Class#getDeclaredMethod respectively. The parameters of ReflectionHelper.findField are fairly obvious and the parameters of ReflectionHelper.findMethod are documented in its doc comment.

It doesn't look like there were any changes to the field between 1.12 and 1.12.1. Which environment did the error occur in? If it was outside of the development environment, it happened because you didn't check for the SRG name of a field (you check the MCP name twice). You should use Forge's ReflectionHelper class instead of the Class methods when reflecting Vanilla fields/methods as it allows you to supply both the SRG and MCP names of the field/method instead of requiring you to manually check both. You should also look up the Field/Method object once and store it in a field instead of looking it up every time as this is the slowest part of reflection. I recommend doing this in the initialiser of a private static final field.

It will be a file with the same name as the installer in the same directory as it.

The x and y properties in blockstates files can only rotate the model in increments of 90°, but your is_on=true,facing=east variant tries to rotate the model by 99°. This causes the NullPointerException in the TRSRTransformation constructor.

FMLServerStartedEvent is fired when the server starts. TickEvent.ServerTickEvent is fired twice per tick while the server is running (once at the start with Phase.START, once at the end with Phase.END). PlayerEvent.PlayerLoggedInEvent is fired when a player logs in. FMLServerStoppedEvent is fired when the server starts. FMLServerStartedEvent and FMLServerStoppedEvent are FML lifecycle events, so you subscribe to them using @Mod.EventHandler in your @Mod class (like FMLPreInitializationEvent). TickEvent.ServerTickEvent and PlayerEvent.PlayerLoggedInEvent are regular events, so you subscribe to them using @SubscribeEvent in a class registered with the Forge event bus (either manually or with @Mod.EventBusSubscriber). To run Python files, you'll need to use something like Jython.

Have you scrolled all the way to the bottom of the versions list when creating/editing a launcher profile?

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.