Draco18s

Which part are you having trouble with? Making a block? Making a TE? Or making the class that saves all the recipes and gets their results?

Couple things I'm seeing that aren't related to your problem, but you should change anyway: 1) Use of Minecraft.getMinecraft() in common code (this will crash the dedicated server). This is why the proxy system exists. 2) Use of getItemModelMesher() you should be using ModelLoader.setCustomModelResourceLocation() instead (called during preInit only!) 3) Use removedByPlayer() instead of breakBlock(). removedByPlayer() is called before the block is actually set to air, avoiding problems of trying to get a blockstate from air (actually it is set to air by the base implementation of removedByPlayer(), so remember to call super). 4) Do not implement ITileEntityProvider, the methods it "supplies" are already part of the Block class (the interface is not used anymore) JSON changes: 5) You don't want parent:"block/cube_all" if you're going to specify sides. Use parent:"block/cube". cube_all is to specify a single texture to use for all six sides + particle (e.g. stone, wool, planks). 6) You can simplify your blockstate variants, specifying the model once (you can put textures here too, this way the variant overrides the default and different variants can supply different and possibly combinatorial differences): { "defaults": { "model": "arborcraft:cardboard_box" } "variants": { "normal" : { }, "inventory" : { } } }

This is a "bug" in Eclipse. Simply click on anything in the Project Explorer again and it'll be fine. Alternatively you can edit your project's run directory to be a hardlinked rather than a programatic one. It's annoying as fuck and only occurs because of the bug and how Forge's setup points Eclipse at the run directory. Go to the Run Configurations window, find the "Arguments" tab and at the bottom, change the working directory from ${project_loc} to ${workspace_loc:MDKExample}\run

That's because it's specified in the blockstate file, not the model. Eg: { "forge_marker": 1, "defaults": { "textures": { "particle": "blocks/planks_oak" }, "model": "harderores:sifter", "uvlock": false }, "variants": { "normal": [{ }], "inventory": [{ }] } }

public int getCheckSum() { return "0xF239AFB520983D20978C290FC9"; //hax }

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.