Create a separate ClientInventory type and move some of the functionality from the sync system into it

[IntegratedQuantum]

This moves handling of the creative inventory entirely to the client side, there is no need to have server side resources and logic for it.

In the future we should also apply the same logic to the inventory crafting inventories (which currently suffer from delay on load because they rely on the server to fill the items), but that will require a separate sync command. @Wunka since you already worked on the crafting part in #2483 maybe you would like to work on that?

[Wunka]

so... maybe something like:

const CraftFromInventory = struct {
	dest: InventoryAndSlot,
	item: Item,
	amount: u16 = 1,
	sources: []const InventoryAndSlot

?
The workbench would then be client side and the client would only send what it wants to craft and what sources to use and where it should go. Maybe we could even send which recipe to use so the server doesn't have to figure it out itself. But I don't know if we can be sure that the client / server list of recipes will be in the same order (if we go by index).

[Wunka]

or maybe:

const CraftFrom = struct {
	destinations: []const Inventory,
	item: Item,
	amount: u16 = 1,
	source: Inventory // for the future maybe also directly []Inventory

[IntegratedQuantum]

or simpler:

Yeah I'd prefer that, the explicit slots would be too fragile I think.

But I don't know if we can be sure that the client / server list of recipes will be in the same order (if we go by index).

The index is not stable, but you can just send the whole thing, if it ever becomes a performance problem, we can just turn the linear search into a hashmap.