Choonster

Store an IFluidHandler instance in a field of the TileEntity and expose it through the Capability System by overriding the ICapabilityProvider methods implemented by TileEntity. FluidTank is the standard IFluidHandler implementation. Forge provides the TileFluidHandler class that does all of this for you, you can simply replace the value of the TileFluidHandler#tank field if you want it to store more or less than a bucket of fluid.

One way to do this would be to create a Set<ResourceLocation> somewhere, then set a breakpoint in SimpleReloadableResourceManager#getResource with a condition to check that the ResourceLocation's domain is your mod's resource domain and an evaluated expression that adds the ResourceLocation to the Set. You can then compare the contents of the Set to the files in your assets directory and see if there are any obvious unused files.

See Wikipedia.

It shouldn't matter how many files there are, you can use wildcards like * in the file name you pass to git add; e.g. git add * to add all files.

If you followed the tutorial, you should understand the basics of how to use Git. Create a Git repository in your mod's directory (where build.gradle is), add a .gitignore file to ignore the files that don't need to be in the repository (like the example I linked, which ignores everything [the first line] except the files that should be in the repository [the lines starting with an exclamation mark]), commit the changes and push them to a repository on GitHub.

It tells you what to do and what command to type in the section above the command prompt.

I've added a link to a tutorial to my previous post.

This message is logged by LootTableManager when it can't find or load the requested loot table. Since there are no other errors relating to loot tables in the log, I suspect that the loot table files don't exist at those locations. I can only help you if you create a proper Git repository rather than putting all the files in a single RAR archive. If you don't know how to use Git, go through this tutorial.

The dragons should be using the sheared sheep loot table, since getSheared always returns true. I can't see anything that would stop them from dropping items. Try setting a breakpoint in EntityLiving#dropLoot with the condition this instanceof EntityTameableDragon, killing a dragon and stepping through the code to see why it's not dropping anything. If you can't figure it out, create a Git repository for your mod and link it here. See my mod and its .gitignore file for an example of the structure to use and which files to include.

That looks correct. Are there any errors in the log? Post your loot table registration class and your entity class.

Like I said, use a variant that already exists in the blockstates file (e.g. "slab_stair=false,type=stonebrick") as the variant of the ModelResourceLocation you pass to ModelLoader.setCustomModelResourceLocation. You can either create this string with regular string concatenation/formatting or from an IBlockState using StateMapperBase#getPropertyString.

You have an invalid trailing comma on line 9 of the blockstates file.

So you want to use the blockstates variants for the item models? The ModelResourceLocation you pass to ModelLoader.setCustomModelResourceLocation needs to have the blockstates file's name as the domain and path (the first constructor argument, which looks correct) and a full variant name as the variant (the second constructor argument, which looks incorrect). An example variant from the chimney.json blockstates file would be "slab_stair=false,type=stonebrick". You're using variants like "_stonebrick", which aren't defined by the blockstates file. The FML log (logs/fml-client-latest.log in the game directory) will usually tell you why a model failed to load, please post it (using Gist/Pastebin) in future. If you're using ModelLoader.setCustomModelResourceLocation, ModelBakery.registerItemVariants is automatically called for you; you don't need to call it yourself. In my mod, I use StateMapperBase#getPropertyString to create a property string (like "slab_stair=false,type=stonebrick") from an IBlockState when registering item models for blocks with variants. You can see how I do this here.

Those examples look correct. If it's not working for you, post your real code and blockstates file(s) and the FML log.

You're registering the loot table correctly, but it's the contents of the JSON file that need to fixed. Each loot pool in the loot table JSON file needs to have a "name" property with a unique value. Currently only the first of the two loot pools has a "name" property.

There are two loot pools in that file, one that includes an entry for the rotd:amethsyt_dragon_scales item and one that includes an entry for the rotd:entities loot table. Only the first has a name.

You didn't name the second pool.

The class looks correct, but make sure you call RealmOfTheDragonsLootTables.registerLootTables in preInit.

I'm talking about the loot table JSON file, not the class that registers the loot tables.

Yes. Forge adds the naming requirement for mod loot tables and auto-generates names for vanilla loot tables. You need to specify a name for each pool in the loot table file. I explained the naming requirements here (in the thread that @V0idWa1k3r linked). Please use code blocks (the <> icon in the editor) when posting code. Alternatively, use Gist/Pastebin.

I've changed those files since posting in that other thread, you can see the latest versions (as of the writing of this post) here: Loot table file Loot table registration For anyone reading this thread in the future, you can use the Tree/Branch/Tag dropdown on GitHub to see the latest versions of these files on each branch. The branches are currently named after the Minecraft version they're targeting.

When are you calling ModelLoader.setCustomModelResourceLocation? It needs to be called before init, otherwise it won't do anything. If you register your Items (including ItemBlocks) in RegistryEvent.Register<Item> (the new and recommended way), register the models in ModelRegistryEvent. If you register them in preInit (the old way), register the models in preInit as well. The FML log will usually have an error message telling you why a particular model wasn't loaded. If you don't know how to interpret the errors, post the full log using Gist.

The heldItem parameter was removed from the method in 1.11, since you can get it from the EntityPlayer using EntityLivingBase#getHeldItem (EntityPlayer extends EntityLivingBase). EntityLivingBase#getActiveItemStack only returns a non-empty ItemStack when the entity is actively using an item (e.g. blocking with a shield, drawing a bow). ItemStacks can no longer be null in 1.11+, the default value is now the empty ItemStack. Use ItemStack#isEmpty to check if an ItemStack is empty. The ItemStack.EMPTY field contains an ItemStack that's always empty.

The ResourceLocation is the ID of the loot table. The vanilla IDs are stored in the LootTableList class.

Don't index the Forge Maven repository, the repository doesn't support it and it's not required. You shouldn't need to index any Maven repositories.