Choonster

You'll need to read this variable from the crafting player (ForgeHooks.getCraftingPlayer) in the appropriate methods to determine the return value. You can either hardcode the variable, value and result or allow them to be specified via the JSON recipe file (possibly via the existing recipe conditions system, like I do in the class Draco18s linked). For a dynamic input item, you'll need to create your own Ingredient implementation and override Ingredient#apply to check the variable and return true or false depending on its value and the ItemStack argument. For a dynamic output item, you'll need to create your own IRecipe implementation (probably extending an existing one like ShapedOreRecipe/ShapelessOreRecipe) and implement IRecipe#getCraftingResult to check the variable and return the appropriate item. For a dynamically unlocked recipe, you'll need to create your own IRecipe implementation and implement IRecipe#matches to check the variable and return false if it's not the right value. That class allows for load-time conditions to enable/disable an Ingredient, which isn't quite what the OP wants.

For vanilla liquid blocks (which extend BlockLiquid), use BlockLiquid.getFlowingBlock and BlockLiquid.getStaticBlock to get the flowing and static Blocks for the specified Material. For modded fluid blocks (which usually implement IFluidBlock and extend BlockFluidBase), there's only one Block.

You'd have to make your own Item like the spawn egg that only spawns one entity type rather than whatever's specified in the NBT. I'd recommend reworking your code to use an ItemStack rather than just an Item.

The Item is just "Spawn Egg". If you want "Spawn Egg of Mini Zombie", you need an ItemStack.

@Mod.EventBusSubscriber registers the Class with the event bus, so only static @SubscribeEvent methods will be called. Your RegistryEvent.Register handlers in CommonProxy and ClientProxy are non-static, so they will never be called. There's no need to handle Block/Item registration in your proxies, do it in common classes (e.g. DMBlocks/DMItems). There's no reason to have a common proxy class, since proxies are for sided code. Common code belongs in your @Mod class or other common classes. Always annotate override methods with @Override so you get a compilation error if they don't actually override/implement a super method.

An Item instance only represents an item type, in this case the spawn egg. To store any more data (e.g. the entity spawned by the egg), you need the metadata/NBT of an ItemStack. You create an ItemStack with the NBT data required to spawn a "thewizardmod.MiniZombie" entity but then immediately discard it by returning the Item from the method rather than the ItemStack. Which version of Minecraft are you using? If you're using 1.9-1.11.2, ItemMonsterPlacer.applyEntityIdToItemStack is a client-only method that can't be used from common code. If you're using 1.11+, "thewizardmod.MiniZombie" is in the wrong format for a mod entity's registry name; it's a ResourceLocation so it should be lowercase and in the format "modid:entity_name".

The Forge documentation is community maintained and so far nobody has suggested or written any documentation on reflection. If you create an issue or PR in the documentation repository, this may be added. You're still only checking the MCP name, you need to supply both the MCP and SRG names for reflection to work inside and outside of the development environment.

You need to use the forge:fluid model. Use Forge's blockstates format to set the "fluid" custom property to the name of your Fluid. I use this blockstates file to define the models for my mod's fluid Blocks/ItemBlocks and these methods to register them.

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