V0idWa1k3r

Depends on what exactly do you want to acheve here and how do you want it to look. For a fluid tank I would use either a cusom IBakedModel (if I do not need the client to see smooth water level transitions in real time as the fluid level raises/loweres through say a pipe) or a FastTESR, and I think that you want the later. Register your TESR using ClientRegistry::bindTileEntitySpecialRenderer. In the renderer itself use water texture UVs and render your desired image at desired positions with Tessellator(or rather put your vertex data in Tessellator's buffer). You can get the water texture using BlockModelShapes::getTexture(state). BlockModelShapes can be obtained through BlockRendererDispatcher::getBlockModelShapes and BlockRendererDispatcher lies at Minecraft::getBlockRendererDispatcher. You can see how exactly to use tessellator in vanilla TESRs. Or you might ask here for more clarification Just remember that with FastTESR you do not need to bind your textures or call neither begin nor draw methods.

You can rotate your textures in your blockstates file, I believe(if you need to rotate your texture on a block/item). Or if you are not satisfied with that you can use a custom IBakedModel. You specify UVs for that yourself and you can rotate them as you please. If it is for a gui/renderer simply rotate your UVs

Attach a capability to the player. https://mcforge.readthedocs.io/en/latest/datastorage/capabilities/

Yes, because you have not specified it a modid, as I've said. Your modid must be followed by a colon(:), not a slash(/)

Your texture file is not found because the resourcelocation you have specified is invalid. Resourcelocation is structured as follows: modid:pathWithinThe[assets/Modid]Folder. I assume iv is your modid. In this case your resourcelocations would be: iv:textures/entity/villager/butcher.png

...instantiate your render object. You know, new IvVillagerRender(manager)

The name property of your sounds is a resourcelocation and must include your modid. Currently it has none and the game assumes they will be located withing minecraft's assets.

Yes, the buttons need an IMessage to sync their presses. I'm not really sure why that issue is happening then. Try just debugging your code in 'problematic' spots that could potentially be causing the issue. See if any TileEntity data is persistent at all upon reloading the world. If it is not then the problem is within saving/loading your tileentity. Also check the log for any error messages - your tile entity will not be saved if it is not registered with GameRegistry::registerTileEntity. Container indeed handles all slot itemstacks changes, and your IGuiHandler seems fine.

Oh, when you are manually moving items? Then most likely there is an error in your container implementation. How exactly are you opening you gui + container? You need to do it using your proxy, providing a Container instance for the server and a GuiContainer instance for your client.

You are either not changing the inventory of your tileentity in your packet handling (as in you are spawning items in the world but not settings the itemstacks to empty in your tile entity... or setting them to empty but only on client side) or there is an error in saving/loading your Tile's inventory. You can debug those two spots in your code using breakpoints to see where the problem lies

Well, to be fair, if you simply want your items to be dropped upon your gui being closed: if you are using a custom Container for your inventory you can simply override container's onContainerClosed method and drop your items there. No packets needed as Container is server-sided. Granted, that will only work if you are using a container in the first place You haven't specified if you are using a container or not in your question, so I haven't thought about it immidiately

Yes, you do need the world/dimension ID. It can be obtained from the World's provider object(yourWorld.provider.getDimension()).

Yeah, Minecraft::getMinecraft() is client-side only. As is Minecraft class in general. Use FMLCommonHandler::getMinecraftServerInstance() to obtain the server in general if you need it, or DimensionManager::getWorld(int id) to get a specific WorldServer. All networking is done on a specific thread so you should not do anything on the networking thread that is world/entities related. Wrap your actions in a Runnable and pass that runnable to a valid IThreadListener using IThreadListener::addScheduledTask(Runnable). A IThreadListener is either a WorldServer instance(server-side) or Minecraft instance(client-side)

A string will ultimately get converted to byte array anyway in the end, as will everything else you send. The only reason I see to not convert it manually is a chance that the charset can be messed up. For example if you are sending to the server a string client has typed and it contains unicode characters. If you are converting the arriving byte array to a string manually on the server you might use say, ASCII charset and mess that string up completely. There is a ByteBufUtils class that handles that for you though. Apart from that I think that structuring your packets is just a personal preference. If your packets are intended to be sent very frequiently and contain not much data it is the best to just write the data 'raw'. If your packets are big and contain bunch of data, especially if that data can vary (so you never know which parts the server/client will recieve) it might just be best to structure your data into an NBTTagCompound and just write/read that. Obviously sending only relevant data that has changed and needs to be synced is the best practice

If your GUI extends GuiScreen or one of it's child classes there is a onGuiClosed() method you can override and send your packet from there.

an instance of your Render class. In this case, an instance of IvVillagerRender

This is the method that controls the texture of your villager. To register your renderer use RenderingRegistry::registerEntityRenderingHandler(Class, IRenderFactory) method. Class parameter is your entity class. IRenderFactory is an interface. You need to provide your own implementation of it. It only has one method, the createRenderFor that takes mc's RenderManager as a parameter and needs to return a render object.

There is nothing stopping you from implementing all functionalities you want your block to have and have a field that controls them if you want your block to 'switch'. If you simply want it to have all the functionalities you can and should simply use capabilities. If you want to have a 'dynamic list' you can implement your functionalities in some kind of wrappers and have that list of wrappers in your tile entity. Or something different, depending on the way you want everything to be handled. It is really more of a design choice

Why would you ever want your block to switch it's tile entity? Tile entity is just a way to store and process data. What exactly are you trying to achieve?

JSON models with sizes that are bigger than 1 cube (16x16x16) already behave strange enough with incorrect UVs and bounding box issues. Solution: use custom IBakedModel(s)/make your block consist of multiple 1x1x1 'parts' Here is a good example of the 'weirdness' I am talking about.

Pretty sure that your mcmod.info needs to have a modid property defined.

And... congratulations! You are the third person in a row who forgot about applying correct translations before rendering! With correct translations applied I get the following from your code: Also if you want your block to be transparent you need to setup GL's blend too, not only alpha

So, read or write? That... is a very specific way to check booleans. Very... strict. Also you should not even need this unless you are explicitly reading entity nbt on the client. I do not think that readEntityFromNBT is ever called on the client. Erm... why? Why are you setting your variables and then redundantly calling getters? They do not do anything on their own... Maybe you ment to invoke your setters? You should use breakpoints to confirm this, not printlns which can get lost in the console. Breakpoints are the way to debug your code, trust me

You are comparing objects by reference (==) instead of by contents (ItemStack::areItemStacksEqual).

Best "open-source"-ish mod to learn the basics of things? Minecraft. Seriously, a lot of things people ask about can be found here and there in Vanilla. Best open-source mod to learn about conventional coding? Forge. Best open-source mod to learn about how to do some specific things? Your brain and a bit of logic. Best open-source mod to learn something really specific from? Well, depends on the specifics. Most mods nowdays are open-sourced, as there is literally no reason to hide your source code. Every mod does things it's own way though. Want something simple? Pick a simple mod then, Any advanced mod will have several layers of abstractions and by your definition will be 'non learner friendly'. Also I do not think that any mod but the forge example mod is intended to be 'learner-friendly'. Mods are usually designed to work, not to teach people how to code