Draco18s

1) you didn't cancel the event 2) you don't play any sounds

What happens? That is, what does happen that you don't want or what doesn't happen that you do want?

I've kind of been ignoring this one for a while because there's nothing technically wrong, just that the display is not as would be desired. I have a block with multiple states that uses a blockstate file to define which texture should display. The block model is blocks/cross (flowers, tall grass, etc) However this means that the item model is likewise displayed as a cross block: https://s14.postimg.org/5skgv4dtt/2016_11_26_13_09_32.png[/img] Is there a way to specify a separate item model, but still use the blockstate file for the specific texture?

pushMatrix and popMatrix, which you're already doing. I suspect the reason is that

You should also stop using IInventory and use IItemHandler instead.

Then I guess you have your answer.

If you're trying to make a block with a huge bounding box: you can't. You must make secondary "technical" blocks, like the way Beds and Doors do.

http://mcforge.readthedocs.io/en/latest/blockstates/states/

Shouldn't you be getting your items from the TE instance?

You mean like... http://mcforge.readthedocs.io/en/latest/blockstates/forgeBlockstates/#sub-models ? The "submodels" part of that section not being the relevant part, look at mossy and pillarcount.

Lets see.... Ahh. At first I was going to say "well yes, you're forcing the metadata, but it's still not a valid blockstate per the BlockStatecontainer rules (that is, you can't use world.setBlockState(..) ) but actually it is. There's two properties involved: Variant (stone, wood, etc) and Seamless. All double slabs are not seamless by the way the slab item works, but you can set the property. The OP is still going to have to register their own item and model for it, though.

Do you know what that means? Also, you set the HoverStart for the one item, but not the other.

Surprisingly, not very hard. Well, unless you want the dimension to contain something. The three bits you're missing are these three: https://github.com/Draco18s/ReasonableRealism/tree/master/src/main/java/com/draco18s/industry/world Mind, I have those set up to provide an inaccessible dimension full of nothing so I can store tile entities from one of my blocks.

GUIs bypass isItemValid checks, you will also need a custom Slot class. Also switch over to capabilities.

This is the better solution, you'd just have to take care not to destroy the hopper as part of your mining. Might want to ignore the 3x3 area directly below your quarry device. The only machine I've ever made that doesn't work like that was a millstone, for grinding ore, that when it got "full" (stack of 8 tiny dusts) it would drop it into the world below it, because it was intended to be built before you had regular access to iron (so spending 5 ingots would be an expensive investment) and had no GUI. Then I had a sifter that could suck items dropped on it (like a hopper) to combine the dusts into large piles, but it didn't drop those into the world (it has a GUI).

That block does not exist as a valid state any more. It used to only through a quirk of how the metadata value was handled. You will need to fake it.

I don't see anything obviously wrong. Use the debugger and step-through.

What method is this inside?

(A, B) != (B, A)

If you want the block to be diamond, yes. Keep in mind that if you wanted spruce planks instead you'd have to do: Blocks.PLANKS.getDefaultState().withProperty(BlockPlanks.EnumType.SPRUCE) (Assuming I got the proper names of everything correct) Because spurce is a variant. The default state would get you oak.

Getting the recipe result while looping through the crafting list is very easy, as the IRecipe interface includes getRecipeOutput() . So that'll let you narrow in on the right recipe quickly. From there, you just need to convert it to the proper recipe class (there are several) and get the inputs. Do note that (most!) tools are of type ShapedOreRecipe and they're made up of lists of items in each slot, rather than a single item (I had to write a recipe comparison function last night that would take in an arbitrary recipe and find recipe with the same pattern, but using a different material: i.e. given the recipe for a wooden axe, find the recipe for the golden axe; that was fun).

Hmm. That sounds pretty reasonable, actually.

Ah, gotcha.

Should just be able to call super.insertItem() at that point, no?

So something occurred to me recently. ItemHandlers need to be exposed for both input and output. In order to prevent an item from being inserted into an "output" slot, setting up a custom ItemHandler class to always return the item inserted into it seems to make sense. Expose for extraction, forbid insertion, seems reasonable. However. Now that means that a machine itself can't put items into its own output slot (other than by using setStackInSlot() which requires that it calculate the stack size manually). There's got to be a better way than this...what am I missing?