Draco18s

The problem there is that both: a) the block might not have an ItemBlock (most crops, cake, door, many redstone objects) b) the given state might not correspond to a special item (leaves, for example: the 4th bit is just a "did the player place this" flag) The latter is probably not something that will cause an error (maybe not even unexpected behavior), but the former absolutely will.

No, it doesn't, really...There is no visible relationship between ItemStack damage value and block metadata Let's see...where is getMetaFromState invoked in vanilla... Block#createStackedBlock (creating an ItemStack) which is called by Block#harvestBlock BlockNewLeaf#getItem (creating an ItemStack) BlockSilverfish#getItem (creating an ItemStack) BlockTallGrass#getItem (creating an ItemStack) GuiCreateFlatWorld#drawSlot (creating an ItemStack) And then four different commands (Clone, ExecuteAt, Fill, TestForBlock) as well as writeEntityToNBT in both EntityMinecart and EnttiyFallingBlock (for other purposes). It would appear that block state->meta is correlated with ItemStack metadata (due to the default implementation of harvestBlock and createStackedBlock). getMetaFromState is also not marked @Deprecated. It's getStateFromMeta that's deprecated. As for using it, yes, I agree it should be used as sparingly as possible. But it's not inherently wrong.

Except when you do, such as registering variant ItemBlock models... Mind, that's the only time I've had need of it, and there's currently at least one spot in Custom Ore Gen that uses it (admittedly because it was easier to update by saying "convert back to metadata" than "change the way 44 config files are structured and parsed." Correct? No, but faster so that at least the mod was available on 1.10). And vanilla uses it to create an ItemStack of metadata blocks, which is a Thing that I could see a mod wanting to do (such as the OP is trying to do).

What do you mean by "glow"? "Glow" is not something shaders, or really, any part of rendering does. There are a variety of possible effects to which you could be referring to, I'm trying to suss out which one.

Well, yes, if your resources aren't present, then of course you'll get those errors. That's kind of what they're there for.

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.