V0idWa1k3r

Well, post your new code and elaborate on what you've already tried and what are the debugging results.

You are comparing by reference, and not by content. Additionally you are comparing an object by reference with a newly created object. That comparason will obviously always fail. The original tutorial you've linked compares an item from the itemstack with an item instance stored somewhere else. Items are singletons, meaning that that comparason can succeed. So that part turns into if(playerIn.getActiveItemStack().getItem() == ModItems.cracker) You might additionally want to check the damage value, if needed. It can be obtained with ItemStack::getMetadata() or ItemStack::getItemDamage()

If you also remove the condition it should. Debug it to see if it does.

Preferences of what? Eclipse? Window->Preferences Java? There should be a Java Control Panel executable on your PC, just search it (or don't, it is located in the bin folder in your jre installation directory and is named javacpl)

Well, based on the code you have posted I see a problem: if (this.getSheared()) { } else { switch (this.getBreedType()) So your switch statement will only get evaluated if the getSheared() method returns false. If it returns true the getLootTable() returns null and no items are dropped. And a few lines below: private boolean getSheared() { return true; } So based on the code you have posted the dragons will actually never drop anything.

Well, if the method is being called at all(and it should be, looks fine to me, but you still should debug it) you should check your loottables. Are they registered properly? Are they pointing to correct JSON files? Are those files correct?

I believe it is the metadata for dye items. While blocks casually moved from metadata to blockstates(although metadata is obviously still there) items still use raw numbers for their differentiations. This particular field is used in recipes, cocoa beans drops, model registering, colors for collars/sheep/etc

Your resourcelocation is declared as But your file is Your names do not match. The resourcelocation points towards a non-existing file

So, village or villager?

Works just fine for me. Wjere is your json file located, exactly? If you are registering it the way you are it must be located at resources/assets/iv/loot_tables/villager_butcher.json

Your JSON is invalid. There is a comma missing after name property declaration. You can use any of a multitude of JSON validators to check for errors. I personaly use jsonlint but there are many more.

Ah, yes, like that, sure.

Your common proxy is... an interface? Why? The way proxies work is you have 2 classes - a common(server) and client. If the game is loaded as a client(normal executable/jar) it will use an instance of your client proxy class. Otherwise it will use an instance of your common proxy class. Right now your common proxy is an interface, which can't be instantiated, obviously. The reason common proxy is named common and not server is because usually people put common(both server and client) things there and call super() in their client proxy, so the code in the common proxy is fired on both sides. Make your common proxy a normal class, change your client proxy to extend it instead of implemeting it and it should work. Yes, you can tecnically still have a common interface, I think. But then the serverSide must point to a normal instantiable class too.

If you make your dragon extend IShearable then it will be shearable by normal shears as well. Although you can simply check if the shears are your desired diamond shears in your dragon's isShearable method and only then return true thus allowing the entity to be sheared by only your diamond shears. It is up to you which way do you want to go, really. Both ways will work. Either make checks if the entity is the dragon in your Item implementation or check if the shears are your diamond shears in your Entity implementation.

Then in your diamond shears item you can override the Item::itemInteractionForEntity method, check that the entity you are interacting is your dragon and drop your desired items.See ItemShears to see how it is done there in more details. My timezone seems to be slightly different from most of other forum members thus I am the one answering you right now

Use loot tables. You can override EntityLiving::getLootTable and return an appropriate loot table. Or you can drop your items in any methods that fire on entity's death, like EntityLivingBase::dropLoot EntityLivingBase::dropFewItems or even EntityLivingBase::onDeath if you really need to do it there of all places for some mysterious reason

net.minecraft.client.renderer.entity.RenderLivingBase. Idk about IDEA but in eclipse you can ctrl+click on any classname and it will open that class in a new window.

Override the preRenderCallback method in your renderer and scale the model there. You can look at RenderVillager for an example

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.