Describe your feature idea

The inventory manager (and ae/rf bridges) could implement the same api as the cctweaked inventory api as it would allow polymorphic code to utilize different inventories with less work. (This doesn't mean removing the old functions as that may break some new ones, just adding an alias to the standard names) This also includes adding support for local directions (left,right) and cabled inventories as imports and exports and would allow exporting from a RF bridge directly to an inventory controller.

Example renames for Inventory Manager

• addItemToPlayer -> pullItems
• removeItemFromPlayer -> pushItems
• getItems -> list
  And maybe implementing the others:
• size() | Get the size of this inventory.
• getItemDetail(slot) | Get detailed information about an item.
• getItemLimit(slot) | Get the maximum number of items which can be stored in this

Describe alternatives you've considered if you've any

An alternative is to add a local chest that is also wired and use it as a buffer, but requires extra management code, especially in more complex managed software.

Additional context

This would match the CC: Tweaked api described here and should allow a chest to .pushItems to a RF bridge and such, as well as adding slot support to the inventory manager

Added in 0.7a

Originally described in #89 but got off topic

size() | Get the size of this inventory.

The occupied size? I mean, the size of a player inventory should always be the same

getItemLimit(slot) | Get the maximum number of items which can be stored in this

You mean, when I have 32 dirt in the slot, only 32 another can be stored in this slot. So this function would return 32

Ah nvm.
These functions are for the connected inventory

size would always give the constant number and getItemLimit would give the stack size for that slot (usually 64, but enderpearls would have 16). This would mean that some code that uses a chest peripheral would just work if you passed in a RS peripheral or an inventory manager peripheral