Choonster

Use the IFluidHandler capability for fluid-related operations. You can pass false as the second argument of IFluidHandler#fill and IFluidHandler#drain to simulate the filling/draining without actually modifying the contents of the IFluidHandler.

Forge's documentation has a page on the Simple Network Wrapper here. This is what you should use to send the packets.

Find the FML log (logs/fml-client-latest.log) in the game directory Upload it to Gist by dragging the file onto the page and clicking "Create secret gist" or "Create public gist" Link it here

If you want it to work properly, yes. That may work in single player, but it's guaranteed to break when the server isn't running in the same process as the client (i.e. LAN hosted by another player or a dedicated server).

The Ordering class is from the Guava library, which uses its own functional interfaces (that predate Java 8). Make sure you've imported com.google.common.base.Function (Guava) rather than java.util.function.Function (Java 8).

Post your new Block and TileEntity classes.

Block#removedByPlayer is called on both sides, so you're spawning a real EntityItem on the server (which also spawns it on all nearby clients) and a "ghost" EntityItem on the client (that can't be interacted with because the server doesn't know about it). Entities should only be spawned on the server. Don't manually spawn the EntityItem, override Block#getDrops like I told you to in my first reply. If you store a compound tag in the "BlockEntityTag" key of an ItemStack's stack compound tag, Minecraft will automatically call TileEntity#readFromNBT with this tag when a player places the block. You don't need to do this yourself. Is the update method being called every tick (e.g. because it implements ITickable#update)? If so, you shouldn't be calling World#notifyBlockUpdate every tick, only call it to send the TileEntity's update packet or re-render the chunk (it always does both). It's possible that this is causing the TileEntity's update packet to be sent before the client knows that there's now a TileEntity at that position. The flags argument of World#notifyBlockUpdate is completely unused by the server and isn't sent to the client. Why are you reading/writing the tank and its contents from/to NBT separately? Just read/write the tank (FluidTank#readFromNBT/FluidTank#writeToNBT) and it will read/write its contents.

ItemStacks don't have a stack compound tag by default, you need to create one and set it as the stack compound tag by calling ItemStack#setTagCompound. Alternatively, use a method like ItemStack#setTagInfo that automatically creates the stack compound tag if it doesn't exist and then calls NBTTagCompound#setTag on it with the specified key and value.

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.