V0idWa1k3r

Erm, yes

Your json has no name property defined for your pools. Forge requires that property to be defined for mod loottables.

You do not use eclipse's export for creating jar files for mods. Like, never. Use gradle

You can see how vanilla does it in classes like BlockRotatedPillar, BlockChest, BlockAnvil... there are multiple blocks that are placed with rotation so there are plenty of examples. Be wary that those are vanilla examples and forge advices you to use a new forge method I've linked below that additionally contains a hand the player uses to place a block. Long story short the blockstate determined on placement is now conviniently returned in Block::getStateForPlacement(World world, BlockPos pos, EnumFacing facing, float hitX, float hitY, float hitZ, int meta, EntityLivingBase placer, EnumHand hand). You can override that method and return whatever you need.

You do not need to extend anything anywhere. Look at the examples Choonster graciously provided

Make sure that your loottable is a valid json and has proper syntax (name property defined) Place it somewhere within assets/modid/loot_tables/ Get a ResourceLocation pointing to it in your core. It should point to your loottable file, but it should not include the path up to loot_tables folder and the extension. Obtain a registry ResourceLocation using LootTableList::register Double check that your ResourceLocation is correct, your json is correct, etc. That ResourceLocation you obtain in step 4 is what you need. Refer to this topic for more details and examples: It is a very recent one too, so all the information there is up to date. Another related topic I've found: loottable file, location and syntax example. And registration example.

Replace all direct OpenGl calls with GlStateManager calls and your problem will magically go away. GlStateManager class is there for a reason and you should use it. The whole game uses it. Your problem lies in the fact that GlStateManager will only change the state if the change requested is not the current remembered state. Before the Post event is fired blend is enabled in the state manager. You are enabling it again later(which is fine, you never know if it is enabled or not) and then disabling it with GL. When the game renders the inventory screen it renders a slightly transparent overlay over the world. Guess how it does that? By calling GlStateManger::enableBlend(). Oh but there is a problem - GlStateManager thinks that blend is already enabled because you've used direct GL call and the boolean in the state manager has not been updated... so it does nothing leaving blend disabled. Thus you see the black screen. TL;DR - do not call GL directly. Use GlStateManager. Or things will get screwed up. Also you are neither scaling,rotating nor translating anything. You do not need to push/pop GL matrix as you are not changing it.

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