Choonster

You need to use a class that extends ItemBlock for the Item form of a Block. Where are you registering your item models? There should be some errors in the FML log telling you why the models aren't working, please post this using Gist or Pastebin.

Have you tried looking at how Ender Pearls do this?

If you must register recipes in code (which I recommend against doing), use the registry events.

Use World#getCollisionBoxes(Entity, AxisAlignedBB) to get all Block and Entity collision bounding boxes that intersect with the specified AABB. Use World#collidesWithAnyBlock to check if the AABB intersects any Block collision bounding boxes.

Use RenderLivingEvent#getEntity to get the entity being rendered, check if it's the client player (Minecraft#player) and then cast it to AbstractClientPlayer before rendering the ears. Since you're only rendering this for a player, it's probably best to subscribe to RenderPlayerEvent.Post instead of RenderLivingEvent.Post. This is only fired for players rather than every living entity.

You need to save the BURNING property to the metadata in DualFurance#getMetaFromState and then load it from the metadata in DualFurance#getStateFromMeta. You shouldn't be manually changing the TileEntity like you do in DualFurance.setState, just set the state to currentState.withProperty(BURNING, isBurning). Since you've overridden TileEntity#shouldRefresh to return true only when the Block changes, the TileEntity will automatically be preserved when the burning state changes. Vanilla only does this because it uses separate Blocks for the two burning states instead of one Block with a boolean property.

You don't. That code uses registry events, which Forge fires when each registry is ready to receive registrations.

As jeffryfisher said, you need to read up on how Java and IDEs work. Oracle have a set of official Java tutorials here that might help. Your IDE should have some documentation on how its debugger works. When you set a breakpoint on a line, you're telling the IDE to pause execution of the code once it reaches that line (and optionally meets some arbitrary conditions, but you don't need them here). This allows you to inspect things like arguments, local variables and fields and execute code in the context of the line it's paused at. Breakpoints are only hit when the program (Minecraft) is running in debug mode. When the breakpoint is hit, you should be able to hover over the Throwable argument of the method in the anonymous class (the one you set the breakpoint in) and look at its value. Alternatively, there should be a window that shows you the values of various arguments, local variables and fields in the current context. In this case, it's probably easier to change the breakpoint so it doesn't suspend (pause) execution and instead tell it to log the Throwable using FML's Logger when it's hit (i.e. call Logger#error(String, Throwable) on FMLLog.log) , this will print the full stacktrace to the log.

I didn't ask you to post the new log, since setting the breakpoint won't actually change fix the problem; it will merely allow you to identify it. This new log has the same errors as the previous one. Please do this:

You can only use an array as a fully-defined variant, you can't use it as one of the values of a property. It might be best to register an IStateMapper that uses a different blockstates file for each value of the type property, this way you can define the textures in the defaults section of each file and avoid repeating them for the variants with multiple possible models.

To open a class by name, use Navigate > Class (Ctrl-N) in IDEA or Navigate > Go To > Type... in Eclipse.

I think the only option is an array of variants, you can't just have an array of models.

I'm not too sure what's going on, please post the full output from running the build task.

In my first post, I was talking about an ore name that never had any items registered for it. This will always return a zero-length array from Ingredient#getMatchingStacks. If a mod were to register an item for that ore name at any point (i.e. even in init, postInit or when there's a world loaded), the OreIngredient would now match that item and include it in the array returned from Ingredient#getMatchingStacks. This is because OreIngredient stores a read-only view of the Ore Dictionary's item list for the specified ore name rather than creating a snapshot of the list at construction time.

OreIngredients will match items registered for the ore name at any time, they don't take a snapshot of the Ore Dictionary when they're created.

Where are you calling this from? Which player are you trying to render the ears for?

Indeed, I saw that some time after posting in this thread. That was news to me, since I'd previously thought that init was the de-facto standard phase for Ore Dictionary registration. Even with this recommendation, I suspect a lot of mods are still doing things the old way (i.e. registering Ore Dictionary entries in init).

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.