Leaderboard

In texture/model cases, we want to see the client log file. The file has more warnings than the console output, so it sometimes tells us things that the console misses. I'm glad the problem was found and fixed.

This is nothing to do with your custom slabs/blocks, it will be a problem with your HarvestDropsEvent. Step through in the debugger to see what's going wrong. Edit: I was wrong! And beaten to it.

Your blocks return the content of drop field when the getItemDropped is called. That field is assigned in a constructor. Your blocks are created in createBlocks method, and items are created in createItems method, respectively. Those methods are called in your... proxy for some reason like this: ModBlocks.createBlocks(); ModItems.createItems(); So every time your block is constructed it gets a reference of item that has not yet been initialized and thereforeafter is null. So your ores always return null when it comes to their drops(apart from that one that drops vanilla clay). Just determine the drop item right in that method, on the fly. Or assign that field later, when the item is not null. Blocks/items should not even be constructed by you like that. They should either be constructed straight in the field initializer or provided by forge's registred-objects-to-fields-injection(if that is available for you).

Forge can't be installed in an MCP workspace. Forge's documentation explains how to set up a ForgeGradle workspace here. If you set up the workspace correctly, you'll have read-only access to the vanilla code (with Forge's patches).

You can't use the == operator to check whether these strings match. == only checks for object identity, which will always be false when you're comparing a substring to a test string. To do what you're trying to do, you can use String#startsWith. With that said, your entire approach to finding the block type seems incredibly flawed. Whatever tutorial you used.. it was terrible. There's a whole mess of inefficient and unnecessary things going on. This entire method is completely excessive. It's "Stringly typing" and will be very error prone. All you need to do is directly associate the item with the block somehow, like using a single instance method which returns each block's own item. In that method, you use Block.getIdFromBlock as an instance method, but it's static. Any IDE worth its salt should be able to warn you about doing this. ItemStack i = new ItemStack(GameRegistry.findItem("blahmod", blockId.substring(7)), 2); In this line you pointlessly create a new ItemStack only to use getItem on it. The result is identical to simply returning the Item parameter you use in the stack constructor, which ignores stack size (presumably that was an attempt to get it to drop two when doubled). In these two methods you are using raw types when you should be using a type parameter.

You DO have an instance of BlockDoor at net.minecraft.init.Blocks, You in fact have 6 of them there. Blocks are singletons. But that will obviously only work with vanilla doors and only if you hard-code them. If you want your method to work with any door that uses an inplementation of ItemDoor to be placed you would need to use reflection to access the block field of ItemDoor

You're creating an AABB with the x and z coordinates of the BlockPos as both the minimum and maximum coordinates, so the entity will only be found if its bounding box overlaps the northwest corner of the block it's standing on (the area represented by the AABB). You should instead create the AABB with the x and z coordinates of the BlockPos as the minimum coordinates and the x and z coordinates plus 1 as the maximum coordinates. This way the AABB will cover the entire block instead of just the northwest corner. The AxisAlignedBB(BlockPos) constructor does this for you, you can then use AxisAlignedBB#expand to expand it by 1 in each direction of the y axis (i.e. up and down). I created this item to experiment with corner- and edge-based AABBs passed to World#getEntitiesWithinAABB. Side note: You don't need to cast the result of the List#get call to IvVillager; the result of World#getEntitiesWithinAABB is a List<IvVillager> (because of the first argument), so the List#get call returns an IvVillager. Are you registering the data parameter more than once? Post the IvVillager class using Gist or Pastebin.