V0idWa1k3r

Debug it. Is the method even getting called? Is the signature correct? I think it isn't. Should it not be preRenderCallback(IvVillager entitylivingbaseIn, float partialTickTime) ?

A child/adult rendering is handled within the model itself. There are no 'child models'. A villager is one of the few exceptions. It's size gets handled within the renderer itself.

A whole cube is 6 more faces. You would add them just after the 4 vertices definitions for your up face - add 4 more for 1 more face and so on. You might need to experiment a bit with UVs/positions to make your face render the correct way but is it quite easy once you get used to vertexbuffer

It does not. It just takes a blockstate and returns a texture of that blockstate. Different blockstates can have different textures This is not the case for a water block, thus you do not have to do anything with it. A lightmap is... kinda obscure but it just controls the 'final' brightness of your texture, it's exposure to light and light's color(you know how in vanilla torches, sun and moon slightly vary in color of light they cast? That is your lightmap coordinates.) You can see how lightmap is normally calculated at Particle::renderParticle. To be precise, the int i = this.getBrightnessForRender(partialTicks); int j = i >> 16 & 65535; int k = i & 65535; j and k are the lightmap coordinates here and getBrightnessForRender simply returns the combined light value for a specified block position(in particle's case the position the particle is at)

This is fine, you do not need to do anything with this It is not rendering because it is... at 0,0,0. Why do you think there are x/y/z parameters given to you in renderTileEntityFast? Vanilla translates TEs in it's rendering using GlStateManager, but you can't do that because of FastTESR. Simply translate your vertices. Also the default vertexformat is BLOCK. Meaning that you need to specify more than xyz+uv in your vertices. You need to specify xyz + color(as 4 bytes(rgba)) + uv + lightmap

You need a custom model for your mob then. Rendering mobs as children with oversized heads is handled in model's render method most(if not all) of the time.

See how it is done in vanilla's RenderVillager class. Specifically, the RenderVillager::preRenderCallback handles child villagers to be rendered smaller than adults.

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