[Dev] InventoryAPI

BASIC InventoryAPI

It is not more then an itemholder.
We should hide the index structure if minecraft changes the internal system.
Atm I have two designs.

  1. Bukkit like system, but with SlotType instead of int’s
  2. Component based system (each Inventory have ComponentInventories, e.g. a PlayerInvebtory has the Components: Equipment, Backpack, Crafttable, Hotbar)

InventoryUtil - Syntax Sugar

Give you the possibility to do cool stuff, e.g. to add Item to existing Stacks and return non fitting ones.

for 2. it provides methods to grab “Vanilla” Inventories from enties, e.g. the player.

I know you don’t want to use an arbitrary indexing system for inventories, but I think there is a need to index inventories. For example a plugin might want to lay out a chest in a particular way(knowing the dimensions of the inventory) and to do this easily, indexing is required. Getting the first/last air/non air slot is not sufficient and would drive plugin devs crazy.

I think SlotType should be an abstract class or interface with methods to navigate the inventory and select the applicable slots, maybe inventory indexing could be exposed at this level as any change in minecraft could easily be fixed. This would limit the impact of the change as the only implementations of SlotType would be affected(If these methods where package private only API implementation would be affected). This would means there could be a slot type that selects the 5th slot from the start of the inventory.

1 Like

Agree with you …
Or we give developer over SlotTypes.Row1Colum2 a “dirty” way to use it

As long we are not using direct indies we can change the underlying implementation

I would go for a simpler system that does have inventory “types”, but also has indices for slots within that type.

E.g. for a Player inventory, you would have 8 inventory types

  • Hotbar
  • Main inventory
  • Head
  • Chest
  • Legs
  • Feet
  • Crafting grid
  • Crafting grid output

And the interface to interact with all of those inventory types will be the same.

e.g. player.getInventory(hotbar).setSlot(0, 0, stack);

You could also have overloads for that for simpler inventories. e.g. setSlot(stack) would call setSlot(0,0,stack) in the background making it useful for single slot inventories like the armor slots or the crafting output slot. Or setSlot(5,stack) would call setSlot(5, 0, stack) which would be useful for 1 dimensional inventories like the hotbar.

Having the interface like that would allow for flexibility but also hides the nasty clumped together inventory slots as minecraft has it internally.

Using indices is not a bad thing for stuff that are indexed by nature. Inventories are.

List of classes/interfaces and functions needed:

interface Inventory
    void setSlot(int x, int y, ItemStack stack);
    ItemStack getSlot(int x, int y);
    // can be used to check the size of inventories. e.g. chest inventories are always 9 wide, but can be from 1 high to 6 high.
    int getWidth(); 
    int getHeight();

interface InventoryType // used as a marker interface to determine which inventory to get.

interface InventoryHolder // e.g. player, chest, etc.
    Inventory getInventory(InventoryType type);

I don’t like the idea of having inventory types. This could break the support for forge mods. And honestly I think we may not make the same mistake bukkit made if it comes to supporting mods. We should have a inventory class that can handle any kind of inventory.

Mods can define there own InventoryType …
So you prefer more option (2) ?

Neither of those will work with mods without extra support from Forge. You cannot tell any information about what a slot does, or what part of the inventory it belongs to without external help.

There’s also the fact there’s three different layers of ‘inventory’, and at least two of them are quite important. IInventory/ISidedInventory for representing the lowest-level, which is directly used by hoppers (and many mods), and Container for representing the mapping of GUI slots to (Multiple) IInventory instances.

I’m not sure I really understand SlotType. I think there should be Slot. Slot should represent something like slot.armor.chest. Perhaps then there could be SlotType which would just represent slot.armor. Maybe then you could add that with something to specify the first/last available slot or such (you could think of it as slot.inventory.next-available). This could also be how you would get a slot.armor.chest Slot from a slot.armor SlotType. Of course with this system, SlotTypes would only be applicable to certain inventories. These inventories could provide convenience methods to get a slot with a slot type. For example, an Inventory with armor slots could provide a method getArmorSlot. This would definitely need to be more figured out than what I have here. I just wanted to record my thoughts on the matter. Maybe they don’t differ much from what the general idea is, but it didn’t seem very clear.

I added javadoc:

already existing:

My PR for that:

Is their going to be different event on click and drag? That put me into some miserable struggle when I was making a custom inventory system in Bukkit. I hope it can all be in one event and maybe have a click type like left click/left clickdrag or something like that.

Also an event like InventoryMoveItemEvent would be handy to reduce writing code like this.