Package net.fabricmc.fabric.api.transfer.v1.item

Class ItemStorage

java.lang.Object

net.fabricmc.fabric.api.transfer.v1.item.ItemStorage

public final class ItemStorage
extends Object

Access to Storage<ItemVariant> instances.

Field Summary

Fields

Modifier and Type	Field	Description
static final ItemApiLookup<Storage<ItemVariant>,ContainerItemContext>	ITEM	Item access to item variant storages.
static final BlockApiLookup<Storage<ItemVariant>,@Nullable Direction>	SIDED	Sided block access to item variant storages.

Method Summary

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Field Details

SIDED

public static final BlockApiLookup<Storage<ItemVariant>,@Nullable Direction> SIDED

Sided block access to item variant storages. The Direction parameter may be null, meaning that the full inventory (ignoring side restrictions) should be queried. Refer to BlockApiLookup for documentation on how to use this field.

When the operations supported by a storage change, that is if the return value of Storage.supportsInsertion() or Storage.supportsExtraction() changes, the storage should notify its neighbors with a block update so that they can refresh their connections if necessary.

Block entities directly implementing Inventory or SidedInventory are automatically handled by a fallback provider, and don't need to do anything. Blocks that implement InventoryProvider and whose returned inventory is constant (it's the same for two subsequent calls) are also handled automatically and don't need to do anything. The fallback provider assumes that the Inventory "owns" its contents. If that's not the case, for example because it redirects all function calls to another inventory, then implementing Inventory should be avoided.

Hoppers and droppers will interact with storages exposed through this lookup, thus implementing one of the vanilla APIs is not necessary.

Depending on the use case, the following strategies can be used to offer a Storage<ItemVariant> implementation:

• Directly implementing Inventory or SidedInventory on a block entity - it will be wrapped automatically.
• Storing an inventory inside a block entity field, and converting it manually with InventoryStorage.of(net.minecraft.inventory.Inventory, net.minecraft.util.math.Direction). SimpleInventory can be used for easy implementation.
• SingleStackStorage can also be used for more flexibility. Multiple of them can be combined with CombinedStorage.
• Directly providing a custom implementation of Storage<ItemVariant> is also possible.

A simple way to expose item variant storages for a block entity hierarchy is to extend SidedStorageBlockEntity.

This may be queried safely both on the logical server and on the logical client threads. On the server thread (i.e. with a server world), all transfer functionality is always supported. On the client thread (i.e. with a client world), contents of queried Storages are unreliable and should not be modified.

ITEM

public static final ItemApiLookup<Storage<ItemVariant>,ContainerItemContext> ITEM

Item access to item variant storages. Querying should happen through ContainerItemContext.find(net.fabricmc.fabric.api.lookup.v1.item.ItemApiLookup<A, net.fabricmc.fabric.api.transfer.v1.context.ContainerItemContext>).

This may be queried both client-side and server-side. Returned APIs should behave the same regardless of the logical side.