Draco18s

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?

Make a boolean. When it's true: play the sound and set it to false.

You also can't map Block -> BlockPos. There are more BlockPos locations than there are Blocks, and the nature of a Hashmap is specifically One-to-One. Your code right now will create exactly 1 falling block for an explosion taking place inside pure stone.

That was it, thanks!

The bit you posted, by the way, says "This is just a prompt for computer specs to be printed. THIS IS NOT A ERROR" You know, for next time.

I'm not sure a giant collection of "instanceof X? do Y" code blocks is going to be any less chaotic. If anything it splits one logical operation ("Create this block and register it") out across several methods ("create this block" "register it with the game" "register an item block for it too" "register the block's renderer" "register the ItemBlock's renderer").

Yes, I had to use an interface for the statemapper business. Couldn't find another clean way of handling it. But no, still no loops other than looping over valid blockstates for registering item renderers. millstone = new BlockMillstone(); //create EasyRegistry.registerBlockWithItem(millstone, "millstone"); //register axel = new BlockAxel(); //create EasyRegistry.registerBlockWithItem(axel, "axel"); //register //etc

Which I don't like (or the array for that matter) because it assumes that all of my blocks and all of my items are going to be registered in the same way. Which they aren't. Which is why I have a whole slew of helper methods for registration (six main methods: Block, Block + ItemBlock, Block + Custom ItemBlock, Block + Custom ItemBlock + Custom StateMapper, Item, Item w/ Variants).

For being able to reference your stuff later, using an array isn't a good idea. The only time you'd want it is if you were doing something with the whole collection. Which a number of folks have done for their item registration, but you'd still have the public static properties.

Ah yes. That is correct. Was my mistake. Doing this asynchronously means forgetting some context.

What are you referring to? Passing two ItemStacks into the constructor? Yes. His wrapper object currently also contains the output, which makes it hard to construct a search-object from two arbitrary inputs and locate the output.

Your input is two itemstacks, then yes, you need to make your wrapper a 2-stack object.

Your experienceList is also probably not going to work (it's a map and ItemStack does not override equals or hashcode, making it a bad class to use as a key). public void addDualRecipes(InscriberWrapper input, InscriberWrapper inputSecond) { dualList.add(input); dualList.add(inputSecond); } For fuck's sake. Your "add recipe" method should take ItemStacks and you wrap them in the wrapper then add that wrapper to the list.

To avoid damage, you need to set the player's fall distance back to 0.

Well, if you want Blue Carpet and Blue Wool to be considered the same...

"other.item1 == this.item1" was not meant to be used literally. You can't compare ItemStacks that way

1.7.10 is no longer supported here.

this.item1 == that.item1 && this.item2 == that.item2, etc.

In 1.7 I had tasks set up for being able to build my release jars, including a line like this: oresJar.dependsOn('reobf') In 1.10, Gradle fails saying there is no such task "reobf" however if I remove this line, then I get a huge list of unknown symbols, ie. it's attempting to perform the compile before reobfuscation has occurred. What do I tell gradle my task depends on?

Ah, yes, a list that way. I was more focused on writing a proper "wrapper" around the three ingredients.

Oh for fuck's sake. EntityFallingBlock entityfallingblock = new EntityFallingBlock(worldIn, (double)pos.getX() + 0.5D, (double)pos.getY(), (double)pos.getZ() + 0.5D, worldIn.getBlockState(pos));