Draco18s

Method calls have overhead, but sure, if you want to go that way for aesthetic reasons, go for it. I'm not going to stop you, I just think its weird.

So, defined "doesn't work" for me here, because this worked for me just fine: public boolean onBlockDestroyed(ItemStack stack, World world, IBlockState state, BlockPos pos, EntityLivingBase entityLiving) { if(entityLiving instanceof EntityPlayer) { EntityPlayer harvester = (EntityPlayer) entityLiving; Iterable<BlockPos> list = BlockPos.getAllInBox(pos.add(-1, -1, -1), pos.add(1,1,1)); for(BlockPos offset2 : list) { IBlockState state2 = world.getBlockState(offset2); Block block2 = state2.getBlock(); boolean canharvest = block2.canHarvestBlock(world, offset2, harvester); if (canharvest) { block2.removedByPlayer(state2, world, offset2, harvester, true); block2.onBlockDestroyedByPlayer(world, offset2, state2); block2.harvestBlock(world, harvester, offset2, state2, null, stack); } else { if (world.isBlockModifiable(harvester, offset2)) { world.setBlockToAir(offset2); } } } } return super.onBlockDestroyed(stack, world, state, pos, entityLiving); } http://s32.postimg.org/uemjtabol/2016_07_29_13_18_51.png[/img]

state.getBlock() //the block I mined out (diamond ore) ...removedByPlayer(state, worldIn, offset2, player, true); //offset2, the location of a different block (dirt), state: the diamond ore...

ItemStack#getItem() instanceof ItemBlock

If a field is public you don't need a getter...

Why are these two different?

That's because those are textures, models.

Gosh. It's almost like you're asking a block of diamond ore what type of dirt it is. When you change position you need to get a NEW BLOCKSTATE or check that the two blocks ARE THE SAME FIRST

Oh, I misunderstood your original question. You want to add this method to the vanilla compass. Ha. Good luck. Forge is supposed to have a thing called "addSubstitutionAlias" (e.g. GameRegistry.addSubstitutionAlias("minecraft:stick", GameRegistry.Type.ITEM, itemStickReplacement); ), but as far as anyone has tried, it doesn't work correctly. See: http://www.minecraftforge.net/forum/index.php/topic,35899.msg191091.html#msg191091

I run all the registration through my common/client proxies myself. It lets me handle the various cases once just by passing a Block/Item and string like the old GameRegistry.registerBlock methods. It sets the registry and unlocalized name, registers the block, and registers the rendering as well.

That depends, but almost certainly "no." (You can detect when the player is in the gui or not and that's about it)

There are always problems. But no, there is no reason why you shouldn't start now with 1.10.2

Block#harvestBlock doesn't actually set the block to air. You would know this if you actually looked at the method. Point is, you can't call just one method, or you completely bypass the set of hooks designed to let other mods know that the block was harvested and removed, or in some cases, letting the block itself know. Take a look at PlayerInterationManager#tryHarvestBlock(BlockPos) The series of things to do is: Block#canHarvestBlock (ensure you can actually harvest the block: you might be able to skip this if you're destroying same-type blocks only) ItemStack#onBlockDestroyed (you would probably skip this because this is how your Item knows that it destroyed a block, and if that calls these methods again, you have a problem) Block#removedByPlayer (automatically called Block#onBlockHarvested; default empty method, but used by various blocks to handle TE containers) Block#onBlockDestroyedByPlayer Block#harvestBlock (finally get the harvested drops to...drop)

I think Macs are smarter and will let you rename a file from "AFile.Ext" to "afile.ext" and actually display the change, whereas windows is like "That's the same thing, not changing it!" but if you try to reference a file with the wrong casing, both systems will go "yeah, sure, here. Close enough."

His thing about wooden pipes was actually because he didn't know what side to check and if the player puts a wooden pipe on one side and a plasma-containment-pipe on another side, the fluid could be drained via the wooden pipe "because a plasma containment pipe exists." Changing to the sided version fixes the problem.

No, it's because you get "logged in" as a random player name. Specifically, a random number between 0 and 1000. e.g. "Player392" then "Player178" then "Player251"

Well it doesn't compile because your method needs a return value, which you're not doing.

That pull request was never merged. There is no such even in Forge and never has been.

That code should be throwing giant red errors at you and shouldn't compile.

Because block textures aren't in the items texture atlas.

Nevermind, I get it. I was missing something that hadn't been spelled out well. When I went looking at the Explosion particle class, there it was. public int getFXLayer() { return 3; }

Then don't use addSubstitutionAlias

Possibly look at the class for a method related to setting the registry name...

You override the read/write methods and make them save the fields to NBT and read them back again. You don't invoke these methods, you implement them.