Draco18s

I know that, I never said that the Code in Bukkit is the same in Minecraft I just said that the getList Method is the same method in Minecraft as in Bukkit (code changed for Minecraft compatibility) Sorry I didn't mean to imply that you were saying that. I was pointing it out, as it may have caused confusion.

That Block class in Bukkit isn't the Block class in Minecraft. That's your biggest mistake, thinking they were the same thing. Minecraft's Block class does not have a getLocation() method (and never did), that must be a Bukkit wrapper. Also, any time you're making a list of something, and then a second list that is 1:1 with it, you need a class. It's called Point and has two public fields: X and Y (or in your case Z, because you care about Minecraft's Z axis) and then you make a list of points. Also, why are your explosions affecting blocks with an airgap? If an explosion happens on the surface (Y=65) why should my floating island house (Y=128, 60 blocks of air away) fall down?

Also why are you re-requesting the block state? int meta = blockLookingAt.getMetaFromState(mc.theWorld.getBlockState(new BlockPos(x,y,z) ) ); You already looked it up here: Block blockLookingAt = mc.theWorld.getBlockState(new BlockPos(x, y, z)).getBlock(); Why not get the block state, then save a reference to that? IBlockState state = mc.theWorld.getBlockState(pos); //use pos from Choonster's post if(!state.getBlock().isAir(state, world, pos)) { int meta = state.getBlock().getMetaFromState(state); }

Yeah, I'm just not the one who needs it this time. At least not right now, not yet. I just dun wanna have to dig into the code and figure it out again.

Use generics.

I thought you ment if I was using an @Override annotation, but... My head is dumb some times The annotation doesn't compile into anything, you are still overriding a method. If you are overriding a method, mark it with the annotation as it will detect user error in the method signature.

Does that mean I need to fix it myself again? Grumble grumble. (I'm the one that did it for 1.7.10)

Probably not as easily. And I can think of remarkably few cases where the particle texture is....not wrong, but misleading. And one of those blocks are mine (the top and bottom faces are smooth stone, and so is the particle texture, but the side faces--the important information about the block*--was different). *Yes, it was intentionally misleading. If the player could not see the sides of the block there was no way to tell it apart from stone. I even made WAILA respect this.

Da fuq did you think it did? Magic? "World, I want the tile entity." Which one? "THE tile entity, obviously."

Well, for one, that only looks east. Second, world.getTileEntity (pos) returns null if there is no TE otherwise it returns aTE

te.getCapability(CapabilityItemHandler.ITEM_HANDLER_CAPABILITY, side)

Instantiate it.

So I have to ask: Why are you overriding extractItem here? It does not appear that you are doing anything different than the standard ItemStackHandler class does, except that you always return null in the case of simulate being true (which is incorrect).

Well, there is a way. But: a) what you've done is the wrong way to make a coremod b) coremods aren't supported here, so its not like I'll tell you what you should be doing Because basically, you've resorted to ASM before Reflection. ASM is always the last solution. In order: Overrides Events Substitution Reflection Ask on the forums to see if you've missed one or more of the above Forge Pull Request Cry in a corner Abandon all hope and abandon feature ASM

Take Part A and combine with Change B. It's not that hard. Remove "Slot" add "SlotItemHandler" Watch the magic happen. We are not here to give you copy-and-paste code. You should already know how to program on your own, we are not Java school.

Because you'll end up iterating multiple times up a column of blocks if you have 2 blocks with the same (X,Z) in the list of affected blocks. Waste of CPU cycles. No you wouldn't. By storing Y values you don't iterate over the columns.

If your getResult is a list, then you need to iterate over it and check ALL of its contents and validate each one individually.

Well....recipe.outputChance isn't an ItemStack, so no....

list = new ArrayList<ItemStack>() ... list.add(recipe.output);

The ITileEntityProvider thing was not actually related to your problem, it was getting your class to use the more up to date method of having a TE. My only suggestion is to use your debugger to step through your code and see what is not being called and why.

Use your debugger and find out.

BlockContainer implements ITileEntityProvider:

Subscribe to the BlockHarvestEvent

By the way you don't need both of these checks: heldItem != null && heldItem.getItem() != null The first one is sufficient, you will never have a non-null item stack of a null item. Also, don't use ITileentityProvider, you should override the hasTileEntity and getTileEntity methods that are present in the Block class (which have a different signature).

I mean really, what's wrong with List<BlockPos>? Also this: if(!b.getRegistryName().contains("air")){ Block#isAirBlock() much?