Inventory System overhaul

[EastArctica]

Currently, the inventory system is very complicated and hard for users to understand. I propose the API be changed to return a Array<Slot> where Slot is a record following this general structure:

public record Slot(
    int slotId,
    ItemStackHelper item,
    String map // InvMapId, ex. "main" or "container"
    // Anything else needed? Reference to the inventory?
) {}

These records would be returned by any methods currently returning slot as an id.

Additionally, the "Map" naming referring to the section of the inventory is relatively poor. Perhaps we should consider different naming.

[EastArctica]

Additionally, we may want to add a findItemInMap or implement a findItem that allows an array of slots to be given. This would allow us to write like this:

const inv = Player.openInventory;
const epearlSlot = inv().findItemInMap("minecraft:ender_pearl", "main");
// or
const epearlSlot = inv().findItem("minecraft:ender_pearl", inv().getItems("main", "hotbar"));

We may also want to consider renaming main to inventory. The colloquial name most people would refer to that specific section would generally be inventory rather than main.

[EastArctica]

type Slot = {
    slotId: number,
    item: ItemSlotHelper | null,
    container: Container,
};

type Container = {
    name: 'inventory' | 'offhand' | 'armor' | 'container' | 'fuel', // etc.
    slots: Slot[],
}

type Inventory = {
    name: string,
    containers: Container[],
    allSlots: Slot[],

    clickSlot: (slot: number | Slot, mouseButton?: number) => void,
    dragClick: (slots: number[] | Slot[], mouseButton?: number) => void,
    dropSlot: (slot: number | Slot, entireStack?: boolean) => void,
};

// Example:
const inv = Player.getInventory(); // Previously openInventory(), perhaps getOpenInventory() or getActiveInventory()? Or just getInventory()
if (!inv) throw new Error('Failed to get inventory');

// Find some slot(s):
// Relatively nice, but requires a lot of knowledge about JS specifically, pushes the responsibility onto the graalvm engines instead of in the java. Is this a good thing or a bad thing?
const myPearls = inv.allSlots.find(slot => slot.getId().includes('pearl'));
const bigStacks = inv.allSlots.filter(slot => slot.getCount() > 48);

// Find only in a specific segment:
// This is yucky! Having to get the container like this is NOT ideal.
const shopContainer = inv.containers.find(container => container.name === 'container');
if (!shopContainer) throw new Error('Failed to find inventory container');
const gearShop = shopContainer.slots.find(slot => slot.getName().getString().includes('Gear Shop'));
inv.clickSlot(gearShop);

A technical description of how minecraft "container screens" like the furnace, survival/creatives inventories, chests, beacons, and the vast majority the others work is as follows:

AbstractContainerScreen<AbstractContainerMenu>
Each container screen extends from AbstractContainerScreen<AbstractContainerMenu>.

• Each screen implements a getMenu method which return's it's AbstractContainerMenu. quickCraftSlots always exists as a Set<Slot>, however it may be empty. I'm not certain when this updates.
• Each screen is given the AbstractContainerMenu, the player's Inventory, and the screen title.
• This class mostly handles the raw clicking/pick block/hotbar keys/offhand key and rendering of slots and labels.
  • This calls onMouseClickAction, which handles any ItemSlotMouseActions (this is only bundles at the moment, it's how custom handlers for things like scrolling on specific slots work).
  • This also calls minecraft.gamemode.handleInventoryMouseClick
    • This validates the container id
    • Makes a copy of the slots
    • Calls AbstractContainerMenu#clicked
    • Diffs the slots to see what changed
    • Sends ServerboundContainerClickPacket with the container id, state id, slot id, mouse button, ClickType, an array of changed slots (id and HashedStack), and the carried item as a HashedStack
• Classes which extend this don't seem to touch the menu at all and generally worry only about specifics to the rendering of that screen.

There is currently just one exception to this, the lectern. The lectern implements MenuAccess<LecternMenu> and appears to contain a Container of 1 slot for its book.

AbstractContainerMenu

• All AbstractContainerMenu seem to be in net.minecraft.world.inventory and net.minecraft.client.gui.screens.
• Clicks outside the screen are registed as slot -999, negative slots are generally considered "special", any positive slots are usually treated as normal slots.
• This manages a NonNullList<Slot> slots
• This must be given a unique(?) container id

Hopefully that's all accurate...