Expose CellInventory.addBasicBlackList via the API for RV5.

While most times there is little need to blacklist an item, there are some circumstances where you may want an item blacklisted. For example, if you are implementing a custom cell to store a particular item type you may want to blacklist that item from the standard cells. There may also be other circumstances like if an item represents some form of energy, then thematically it may not make sense to be able to convert that energy to other energy for storage.

Exposing this through the API will eliminate the need for the mod author to resort to using reflection or linking directly to AE internal classes for this functionality.

Makes sense.

In my case I need to be able to represent items to the crafting grid, but really don't want those items exposed to the storage grid... Kind of a weird situation.

I don't mind if I have to make my own buses, and I have already implemented my own grid, but I have had to resort to some hackish approaches to handle my cells being usable in Drives. What I want to avoid is having to build my own crafting grid. Requiring the player to build a completely different crafting complex for certain items would be a nightmare.

I certainly think the ability for mods to add new storage channels sounds like it could accomplish most if not all of what I need, but it also sounds like a very major change.

That is actually something I want to get rid of. It is pretty much unused/useless, and also a bit hacky.

It is actually something which should be provided by forge to detect baglike items to prevent excessive NBT data by recursively stacking them.

Opening it up for normal items, will just be a headache for players once some mods decided that their items should not go into cells. (Not speaking about virtual items to represent energy type stuff)

It actually touches my idea of getting rid of StorageChannel itself. It is/was mostly for ExtraCell, to actually prevent it from having to blacklist items in item cells. But it is very limited for other things.

The easiest way would be to completely drop it and simply leave it to the addon devs to implement their own grid for a specific thing. Plus improve helpers to obtain cells for a specific type from drives to add them to your own grid. But this will most likely eliminate the native interface/storage bus interaction for anything but items and each addon would have to provide their own blocks/parts for it.

The other solution would be to move to a Class<?> based approach and allow other mods to register new storage channels. Probably the most flexible way and we can handle things like interface/storage bus internally. But most likely still require custom buses for supporting the new thing. Extending the normal ones would be particularly hard as it not just affects the normal block interaction (that might be solvable with caps), it will also affect the GUIs and what not.
Further it would certainly bput more responsibility on the addon dev, as a new storage channel needs a couple of functionality like a factory to create a new IItemList for the particular type. These have to follow a specific contract and we might not be able to verify it when registering a new type. Thus they have a good chance to break something internally, when not following the contract defined via JavaDocs.
(Of course also ways to prevent them from overwriting existing core lists)

The problem with the crafting grid is that it relies heavily on normal itemstacks. Not just for patterns. they should probably not be hard to improve to use a more abstract stack type.

But everything else like the tree, guis, parts like the level emitter, and what not is designed with itemstacks in mind. At least we need to be able to convert any stacktype into an itemstack representation to render it for the crafting status.

Handling patterns with different types is probably also out of question for AE2 itself. It is way too complex, especially if we no longer talk about things which can be aquired as itemstack, but need something else to add them. While we could probably allow some workarounds for things likes fluids, so double clicking with a bucket will change it from the bucket to the actual fluid, it would still be very crude and limit it to items and fluids. Otherwise every addon would have to provide their own pattern terminal. But that makes it impossible to support patterns with cross addon recipes. E.g. no recipe with a itemstack + fluidstack + visstack. Or every addon has to provide support for every other addon out there...

While a more generic StorageChannel is certainly an option and probably only is a moderate amount of work. Doing the same for autocrafting is a huge investment. Which also increases that some addon can easily break it because they decide to violate the contract of some methods/classes.