Choonster

Both of the proxy classes you posted reference a class called RegistryHandler. Neither of them reference Entity303Registry. You haven't posted a class called Entity303Registry.

How did you set up the workspace? Forge's documentation explains how to do it properly here.

All you need to do is call the UniversalBucket.getFilledBucket method. Pass the UniversalBucket instance (from the ForgeModContainer#universalBucket field) as the first argument and your Fluid as the second argument. It's a static method, so you call it on the class rather than an instance.

That would probably be it. You need to tell ForgeGradle to reobfuscate the output of that task, like I do here.

You definitely built your mod with the build Gradle task and copied the built JAR from the build/libs directory? If you open the JAR in a decompiler, are all of the other references to vanilla methods/fields obfuscated to SRG names like func_00211_a and field_02301_b?

Indeed. JSON files are only loaded for your mod ID and always have your mod ID as the domain of their registry name.

Please post the full FML log (using Gist/Pastebin) from a run where this happens.

You can override recipes by registering a dummy recipe with the same name as the vanilla one, but this spams the log with Dangerous alternative prefix warnings from Forge.

No, it only accepts an Item registry name. You could create your own condition for that, but ore dictionary registration is usually done in init; which is after recipes have been loaded and conditions tested. If you use a forge:ore_dict ingredient with a non-existent ore name, the recipe will show in the recipe book and in JEI but won't be craftable. Attempting to fill the recipe using the recipe book will crash the game with an ArithmeticException: / by zero (I plan to report this to Forge). Attempting to fill the recipe using JEI will simply do nothing. Edit: Reported the crash here.

Post your code and the exception using Gist/Pastebin. What do you need the player for? Why does it need to be an AbstractClientPlayer specifically?

If you're using an IDE with Gradle integration (e.g. IntelliJ IDEA), run the build task from the IDE's Gradle window. Otherwise open your mod directory in a command prompt/terminal and run gradlew build.

The class you need to set a breakpoint in is a part of FML, not a part of your code. Open the LoadController class, navigate to the constructor, set a breakpoint in the handleException method of the anonymous class and then run Minecraft in debug mode. When the breakpoint is hit, look at the value of the Throwable argument of the method to see where it was thrown from.

What do you want a tutorial/example on? Basic Java concepts? Creating an ItemStack of the Universal Bucket?

You're being very vague. Tell us what your overall goal is, not how you intend to achieve it.

You can't use a class where a value is expected (e.g. in the argument list of a method call), this is basic Java. UniversalBucket.getFilledBucket is a static method that takes an instance of UniversalBucket (e.g. the one stored in the ForgeModContainer#universalBucket field) as its first argument. Don't call static methods on instances, your IDE should warn you when you do this.

You will unfortunately need to create a recipe file for each recipe. You can use the minecraft:item_exists condition to enable a recipe only when a specific Item has been registered.

It looks like you never register ClientProxy with the Forge event bus, so the ClientProxy.registerModels method is never called and your models are never registered. Either register it manually or annotate the class with @Mod.EventBusSubscriber to automatically register it. Make sure you pass Side.CLIENT to the annotation so the class is only registered on the client, this prevents the dedicated server from loading the class and then crashing because it can't find the client-only classes referenced by it. Forge's documentation explains events in more detail here.

I explained how to debug this to someone else a while ago:

You'll need to create your own condition that returns true or false based on this option and then create separate recipe files for easy and hard mode that use this condition. Create a class that implements IConditionFactory and then specify this class in recipes/_factories.json. You can implement BooleanSupplier (the type returned by IConditionFactory#parse) using a lambda that returns the value of your config option. In a recipe file, set the conditions property of the top-level object to an array containing an object for each condition. In each condition object, set the type property to the name of the condition type and include any other properties required by the condition type. Forge will test the conditions at recipe load time and only register the recipe if all of them are met. You can use the forge:not condition to invert the result of a condition. If the hard and easy mode recipes are mostly the same except for one or two ingredients, you may want to use a conditional ingredient like this. This will allow the individual ingredients to change based on the config option instead of having one of two recipes enabled based on the config option. Resource packs can't overwrite server-side files like recipes or loot tables, but Mojang plans to add data packs in 1.13 to allow that.

This probably isn't related to sides, though you should fix that as well. CommandHandler#registerCommand is a vanilla method, which means it has a different name outside of the development environment. You need to use the build Gradle task to build your mod and reobfuscate it from MCP (deobfuscated) to SRG (obfuscated) names.

Phone: LG G5 OS: Android 7.0.0 Browser: Chrome 60.0 Example thread: http://www.minecraftforge.net/forum/topic/60386-112-trouble-with-recipes/ When browsing the forums on my phone, I noticed that the Google ad directly after the first post often overflows and obscures the top of the second post. This can be seen in the screenshot embedded below:

If you look at the method signatures in IForgeRegistry, you'll see that IForgeRegistry#getValues returns a List<V> (i.e. a collection of all values in the registry) whereas IForgeRegistry#getEntries returns a Set<Map.Entry<ResourceLocation, V>> (i.e. a collection of all name-value pairs in the registry). There are very few areas where you need to use numeric IDs, they should be avoided wherever possible as they're automatically assigned and different for each save. You generally want to use the objects directly or use registry names if that's not possible. If you tell us what you're trying to do, we can tell you how to do it.

I managed to get this working with a single Item per bucket type, you can see my code here. This involves overriding several UniversalBucket methods that assume that the empty and full buckets are different Items and using an IFluidHandlerItem implementation that isn't limited to the Forge/Vanilla bucket Items. The model registration was already handled automatically by my existing code, so you won't see it in the linked commit. I essentially do the same thing that Forge does in ModelLoader.setBucketModelDefinition.

You can't change the textures of Forge's UniversalBucket instance (those are specified in assets/forge/blockstates/dynbucket.json), but you can create and register your own instance and specify your own textures. The universal bucket uses ModelDynBucket for its model, this is a dynamically-generated model that retextures itself based on the fluid contained in the ItemStack. Forge uses ModelLoader.setBucketModelDefinition to set the universal bucket's model, you can do the same thing as this method but specify your own blockstates file instead of using Forge's one.

Create a pack.mcmeta file in src/main/resources and set pack -> pack_format to 3. Alternatively, download a recent MDK and copy its pack.mcmeta file into src/main/resources. Mojang distribute the sounds and alternative language files through a separate resource repository system, these are stored with hashed names in .minecraft/assets (outside of the development environment) or ~/.gradle/caches/minecraft/assets (inside of the development environment). I'm not entirely sure why this is, but I suspect it's to prevent the Minecraft JAR from being too large.