Animefan8888

This is in your ModTileEntity And this is in your TileEntityFluxGrinder And this is the isItemValid in your Slot classes

Did you check if you could shift click fuel into the inventory? *Ignore what code question was here.

There was an error log?

Could you post your code?

Anything to do with public static final PropertyDirection FACING = BlockHorizontal.FACING; in the BlockFurnace class is basically what you need.

How can you place orientable blocks with in the code, look at BlockFurnace it has all of the code for that.

Just look at BlockFurnace try to wrap you mind around that, then have your models parent be block/orientable

That should be working....but change //This if (!mergeItemStack(sourceStack, first_fuel_index, first_fuel_index + fuel_slots, true)) // To this if (!mergeItemStack(sourceStack, first_fuel_index, first_fuel_index + fuel_slots, false))

What do you mean it is not a safe solution, and I agree that would be a very useful hook.

What does this line print out now? System.out.println(first_input_index + ", " + input_slots + ", " + (first_input_index + input_slots));

You could probably use the InputEvent.

addSlotToContainer is being called in your main class. When you call it the number of slots is still = 0 for all of those, and since you stored the number of slots in your TileEntity I don't understand why you don't use those? Instead of creating new variables in your container. *Note make them not final.

Where did you copy that from? { "parent": "item/handheld", "textures": { "layer0": "items/iron_sword" } }

Note these edits work for me.

Ok you are going to have to add your Slots that are for you TileEntityFluxGrinder, you need to add them in your ContainerFluxGrinder.

In get output you never check if input2 is input. And honestly forge why would you just check to see if the item is the same when you should be comparing ItemStacks.....

Why not use BrewingRecipeRegistry.addRecipe(input, ingredient, output);

Sadly it is not so http://stackoverflow.com/questions/1168345/why-does-this-and-super-have-to-be-the-first-statement-in-a-constructor What I mean is if you have something like upgrade slots that will be in all of the containers, you can add them in the main container. And all new ones for that specific TileEntity you add in that TileEntities container.

Well then I'm going to say what I think happened since you are using for loops and setting variables that are initially set to 0. The constructor for the previous class gets called before the variables could get set in your ContainerFluxGrinder. Solution add slots in your new Containers atleast the ones that are not required.

Why would super have to be first?

Instead change the variables to not final and call super after changing them.

Yes, did that work.

Why would he want to use capabilities, he is using a TileEntity, not saving data to the player. Note to self capabilities can be tied to TileEntities.

Also never mind it exists in block models not in Item models.

Also // This "parent": "block/fence_gate_open", // and "parent": "block/fence_gate_closed", // Don't exist in vanilla 1.10