Add ISpecialInventory

[FunnyMan3595]

I'm happy to see the BuildCraft liquid API being added to Forge. I'd really love to see ISpecialInventory make the transition as well.

ISpecialInventory is similar to ISidedInventory in that it provides an interface for inserting and removing items from specific sides of a block. Unlike ISidedInventory, however, it leaves the underlying details of how items are stored up to the implementing TileEntity. This has some major advantages:

• Items can be filtered, rejecting unacceptable items while accepting appropriate ones. As far as I can tell, this is only possible with ISidedInventory by engaging in hackish (and downright underhanded) subclassing of ItemStack.
• Items can be sorted, created and destroyed on demand, or simply stored in non-array data structures, without abusing the array-like design of IInventory. This is all possible with ISidedInventory, but it's much cleaner with ISpecialInventory.

Currently, using BuildCraft's ISpecialInventory adds flexibility and cleanliness to your code, but leaves you tied to BuildCraft and not able to interface with other item transport systems--like Redpower's tubes--without adding redundant and ugly code... sometimes exceptionally ugly. Moving it to Forge, where it could be easily shared by all item transport systems, would be a major gain for anyone making blocks that produce, consume, store, or convert items. (Isn't that most of us?)

[CovertJaguar]

+1

Although I've been told it could never work with RP for some reason that never made any sense to me.

[benblank]

I'd like to see this as well. ISidedInventory is very limiting, especially compared to the liquid API.

[immibis]

Why hasn't this been added?

[CovertJaguar]

Because its hated passionately by some very vocal people.

[immibis]

Who would that be? Eloraam?

[Myrathi]

The current, general concept of the inserter getting to choose what it gets to put into my blocks/machines - without some significant hackery on my part - has me in favour of this interface.

I'd like to hear the reasoning of these seemingly vocal people. "I hate it" doesn't hold much water, by itself.

[immibis]

I'd like it if extractItem took a parameter that could filter the extracted items, something like this:

public interface IStackFilter {boolean acceptsStack(ItemStack stack);}
ItemStack[] extractItem(boolean, ForgeDirection, int, IStackFilter);

Still not seeing how you could hate it, though.

[cpw]

I have an idea..

[immibis]

So did I, immibis@ab7f9be

ICustomInventory is the equivalent of ISpecialInventory.
ILinearInventory is the equivalent of ISidedInventory/IInventory. Inventories can be one or both (or neither, if something else is added later).

(Edit: ILinearInventory can do more than IInventory and is less retarded - I'm not duplicating it for no reason, and InventoryAdapters has a method to create ILinearInventory wrappers for IInventory objects)

[cpw]

Immibis, bear in mind isided is in vanilla in 1.5..

[CovertJaguar]

There was talk of creating a pluginable mediator object that could allow inventories to interact with each other, even if they use different interfaces. I think it was @ScottKillen who had the idea.

[ScottKillen]

@CovertJaguar My aged brain does not recall it, but I'll be happy to look into it. 😄

[CovertJaguar]

Ah, no it was xcomp. My bad.

[ScottKillen]

Also it would appear that Overmind has a solution.

[CovertJaguar]

Yes, well there have been disagreements over his solutions in the past.

[FunnyMan3595]

@cpw, are you going to clue us in on your idea anytime soon, or should we just keep throwing our own ideas at the wall to see if one sticks?

As I see it, the issue is basically a disagreement on what parts of the system should be "smart". Buildcraft provides an (essentially) dumb transport system and assumes that storage blocks can be smart, and so provides ISpecialInventory to allow them to define custom behaviour. RedPower, on the other hand, provides a smart transport system, and assumes that storage blocks are dumb containers, to be rifled through at will. Neither approach is good or bad, simply different architectural decisions.

Looking at it in that light, including ISpecialInventory in its current state would be a Bad Idea, as it provides no suitable interface for RedPower-style transport architecture. As it stands, we have four possible pairings, three of which are solved adequately. ISidedInventory handles Dumb->Dumb and Smart->Dumb transport->storage pairings, while ISpecialInventory handles Dumb->Smart pairings. We need a way to handle Smart->Smart pairings, and might as well absorb ISpecialInventory's Dumb->Smart support in the process, to keep the clutter to a minimum.

So, really, the question to ask is this: What API does @Eloraam need to be able to talk to a smart storage block? I could make some reasonable guesses, like the ability to ask how many it has of a particular item, or how many (more) of that item it can store. But, really, I think the right person to ask the question of is the lady herself, because (for reasons I hope are obvious) nobody else is better qualified to tell us what would work best for her.

[AbrarSyed]

I am of the opinion that we do whatever we feel best because of 1.5. And then, Elo will probably fix her side when she updates for 1.5.

[cpw]

I think we wait and see what 1.5.1 brings..

[Myrathi]

That statement is both interesting and worrying, cpw. :P

[LexManos]

Seems this never got stable enough for everyone to accept. Feel free to try again with actual code and documentation/implementation next time.

[CovertJaguar]

Meh, its been stable for a year or something, people just don't like it. But its not really needed anymore anyway.