The calcinator is unable to accept items from Extra Utilities Transfer (and retrieval) nodes, Buildcraft Pipes, Thaumcraft Golems, Infinitubes Teleposers, Translocators Item Translocator, and Vanilla Hoppers.

However, it is capable of outputting to any of these from it's output slot, meaning only partial automation is possible.

I'm not sure if this is a bug, or intended, however I'd like to suggest that they be capable of receiving items to be calcinated from the top and fuel from the bottom, since many mods, magical and technological, tend to include some form of automated item transport.

The Calcinator supports ISidedInventory and therefore should easily support automation

i have the same issue as all of the above in anti material mod pack i went in creative and tried all methods of getting fuel to the calcinator. no system or pipe will add to the fuel slot. Pahimar i'm glad to see the mod moving forward and wish you the best wherever that may be. You and the mod are legendary to mine craft and modding in general. test is with build 1.7.1.0-0.2.461.

I have also tested this just now with the latest version, the calcinator will still not accept anything piped in through any means of transportation.

This bug must have been prematurely closed. What good is ISidedInventory support if there is a typo preventing it from working as martejj pointed out?

@hawken93 I'm confused - what typo? Also no one has reported this being an issue in months. Are you experiencing an issue with this? If so I need details like version of EE3 and Forge.

Ah, sorry... I was playing around with EquivalentExchange3 0.3.507 and I couldn't seem to get any pipes in/out working, so I assumed that it was this bug.. I guess I will test it some more.. It's forge with minecraft 1.7.10, should be this version: forge-1.7.10-10.13.4.1614

@pahimar WIth this mentioned version I have tested the calcinator with a vanilla hopper from the sides and top, none of which inserts items, is it expected behavior? :)

@pahimar I have looked at the code now and this function seems to explain it to me:

@Override
public boolean isItemValidForSlot(int slotIndex, ItemStack itemStack) {
    return false;
}

So I guess that I know roughly how this function should be implemented, so I guess I will try to set up an environment in which I can compile your mod :) I will get back to you if I can make it work! :)

#1042
Yay, this seems to work for me :) I'm hoping that my pull request will convince you.

I'm sorry if this caused the bug to reopen against your will, didn't know that it would happen..

I also want to thank you for making this great mod :)

For automation of any kind to work on the Calcinator the Boolean return of the method isItemValidForSlot() in TileEntityCalcinator (line 188) must be changed to true. This is for allowing other blocks like hoppers to drop items into the TileEntity's inventory. Though im not sure if this is on purpose because he has got automation on other blocks.

According to this guide and TileEntityCalcinator.java its input is the top:
"public static final int INPUT_INVENTORY_INDEX = 1;"
"Face 1 (Top Face)"

I think you missunderstood something here, the constants are the slot indices (or slot IDs) of the specified slots.

Am 03.01.2015 um 11:57 schrieb Sebastian Stark [email protected]:

According to this Guide and TileEntityCalcinator.java its input is the top: "public static final int INPUT_INVENTORY_INDEX = 1;"
"Face 1 (Top Face)"

—
Reply to this email directly or view it on GitHub.

Derp. I thought it was that because of this

  @Override
    public int[] getAccessibleSlotsFromSide(int side)
    {
        return side == ForgeDirection.DOWN.ordinal() ? new int[]{FUEL_INVENTORY_INDEX, OUTPUT_LEFT_INVENTORY_INDEX, OUTPUT_RIGHT_INVENTORY_INDEX} : new int[]{INPUT_INVENTORY_INDEX, OUTPUT_LEFT_INVENTORY_INDEX, OUTPUT_RIGHT_INVENTORY_INDEX};
    }

Well I am just a wannabe modder it's good to be corrected by other people. Thank you Sir!

Brought me to the false track some time ago, too. It is a good style to express these with constants. @pahimar is a good engineer :D

Am 03.01.2015 um 12:22 schrieb Sebastian Stark [email protected]:

Derp. I thought it was that because of this

@OverRide
public int[] getAccessibleSlotsFromSide(int side)
{
return side == ForgeDirection.DOWN.ordinal() ? new int[]{FUEL_INVENTORY_INDEX, OUTPUT_LEFT_INVENTORY_INDEX, OUTPUT_RIGHT_INVENTORY_INDEX} : new int[]{INPUT_INVENTORY_INDEX, OUTPUT_LEFT_INVENTORY_INDEX, OUTPUT_RIGHT_INVENTORY_INDEX};
}
Well I am just a wannabe modder it's good to be corrected by other people. Thank you Sir!

—
Reply to this email directly or view it on GitHub.

Too bad he stopped doing Let's Mod Reboot :(

Maybe Pahimar has an idea for a transport mechanism that will eventually work?

This happens for me too. I've tried(in addition to what NullMagic has): Omni-Directional Hopper(PneumaticCraft), Remote Interface(Don'tRememberTheModName), Pretty much every item transport mechanism I can think of.

Looking through the calcinators tile entity it appears as though it only accepts items from a certain side because it implements ISidedInventory. I'm not completely sure how to check which side accepts what but I'm sure there's a way to find out somewhere.

I have considered that it might be on purpose, but it'd be really nice to know if it is or not, given how quickly he seems to close complaints/reports about things that are on purpose I've, up until now, just chosen to assume that either he'll get to it when he gets to it or he hasn't yet decided what he wants to do with it.