Leaderboard

EventHandler is for mod lyfecycle events - init/pre-init/post-init, etc. You need to work with event bus events. Here is how to do it

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.

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.

Ultimately, you can't rely on another mod to make itself compatible with yours (or any other). You could try to contact them personally or open an issue rather than a PR to discuss it, but at this point it seems like they probably know they're incompatible with other mods and just don't mind.

Okay, so a couple of things I would like to explain: 1. Difference between TileEntity::getUpdateTag and TileEntity::getUpdatePacket. They are build around the same purpose and cause a lot of confusion, but they are slightly different. getUpdateTag is appended to the ChunkData packet(the one player recieves from a server when loading a chunk/chunk data is changed). getUpdatePacket is sent in 2 circumstances: If a BlockState changes and the new one has a TileEntity(world::setBlockState is mostly the cause here) or if the amount of changes in the chunk is greater than 1 and less than 64(so a couple of blocks got thanged). Then the getUpdatePacket is sent for each changed blockstate with tile entity. So you do need to override both in your tileentity. Override only getUpdatePacket - and the client will not recieve the data when the chunk is loaded or multiple blocks are changed at the same time. Override only getUpdateTag - and the clients will not see the changes upon blockstate changes. 2. Please use breakpoints to debug. They are so much nicer and handy, you have no idea. Writing stuff to output is messy, time-consuming and leads to situations when modmakers forget to remove their println debugging from the final product and the log gets overflown with useless debug information and slows the game down. Just launch any big modpack out there and watch the log. You will quickly see what I mean. A breakpoint is literally 2 clicks of mouse to set, gives you all the info you need and even more and it will never end up in the final product. 3. getUpdateTag should return all your NBT information you need to sync. A couple of responses above you posted: That will not work. It will send an empty packet to the server upon chunk loading and your tileentity will not have any data synced. Even worse, it will completely mess everything as the tileentity will not get loaded at all! See how it is done in the base Tileentity class. If you simply override both of those methods and their handlers (onDataPacket, handleUpdateTag) then your tile will get updated correctly on the client when the respective packet arrives. You still will need custom packets to sync real-time changes though.

Which means it's called on the client-side. On the client-side, you can use the Minecraft class which contains a lot of information about the game, including the player and the world he's in.

I don't know anything about the universal bucket textures, I'm afraid. The fluids thing though - unfortunately forge fluids don't do anything with collisions. So if you want to e.g. make entities slow down in the fluid, you'll have to manually implement something. I have a very simple version here, overriding onEntityCollidedWithBlock to reduce the entity's horizontal motion by a fixed amount.

Your block class doesn't contain a facing property though. You have to define it in the block's code, otherwise how does minecraft know when to use which variants from the blockstate file? When you don't specify variants, it uses "normal" by default. The link I sent explains how to create a block property.