14
edits
Changes
User:TheSilkMiner/Capabilities (view source)
Revision as of 13:24, 10 January 2021
, 13:24, 10 January 2021Add descriptions for the various Forge provided capabilities
The wary reader may note that both ''persistent'' and ''agnostic'' providers are represented the same way in code. In fact, the only difference between them comes from pure semantics in how their serialization methods are designed. This will be further discussed in their respective sections.
The wary reader may note that both ''persistent'' and ''agnostic'' providers are represented the same way in code. In fact, the only difference between them comes from pure semantics in how their serialization methods are designed. This will be further discussed in their respective sections.
Moreover, it is also common to refer to the capability interface as simply the ''capability''. While not strictly correct, due to common usage we will also use this convention. So, to refer to the capability interface <code>MyCapability</code>, we will usually talk about the "<code>MyCapability</code> capability".
== Forge-provided Capabilities and Providers ==
== Forge-provided Capabilities and Providers ==
The default capability providers in a Forge environment are: <code>TileEntity</code>, <code>Entity</code>, <code>ItemStack</code>, <code>World</code>, and <code>Chunk</code>. These are all agnostic providers, since they don't mandate any sort of capability persistency requirements. Rather, it is the job of whoever subclasses these providers to deal with either volatile or non-volatile capabilities.
The default capability providers in a Forge environment are: <code>TileEntity</code>, <code>Entity</code>, <code>ItemStack</code>, <code>World</code>, and <code>Chunk</code>. These are all agnostic providers, since they don't mandate any sort of capability persistency requirements. Rather, it is the job of whoever subclasses these providers to deal with either volatile or non-volatile capabilities.
The default capabilities that forge provides are <code>IItemHandler</code>, <code>IFluidHandler</code>, and <code>IEnergyStorage</code>. Each one of these capabilities will be discussed in the corresponding section.
The default capabilities that forge provides are represented by the interfaces <code>IItemHandler</code>, <code>IFluidHandler</code>, and <code>IEnergyStorage</code>. Each one of these capabilities will be discussed in the corresponding section.
=== <tt>IItemHandler</tt> ===
The <code>IItemHandler</code> capability refers to the ability for any capability provider to have some sort of internal '''inventory''' with a certain number of slots, from which items can be inserted and extracted. It is also possible, though, to expose this capability even if no such inventory is present as long as the capability provider can emulate its presence (e.g. tools that allow accessing remote inventories).
This effectively '''replaces''' the vanilla interfaces <code>IInventory</code> and <code>ISidedInventory</code>. These interfaces are in fact retained only to allow vanilla code to compile and should not be used in mod code. This extends to anything that implements those vanilla interfaces, such as <code>LockableLootTileEntity</code>.
=== <tt>IFluidHandler</tt> ===
The <code>IFluidHandler</code> capability refers to the ability for any capability provider to handle and store fluids in one or multiple fluid tanks. It is effectively the equivalent in terms of fluids of the <code>IItemHandler</code> capability.
=== <code>IFluidHandler</code> ===
=== <tt>IEnergyStorage</tt> ===
The <code>IEnergyStorage</code> capability refers to the ability for any capability provider to store, consume, and produce energy. This capability is the base capability for what's commonly known in the modded world as Forge Energy (or FE), i.e. the energy system most mods use. Its internal design is heavily based on the (now defunct) Redstone Flux Energy API, supporting both a push and pull system.
== Working with Capabilities ==
== Working with Capabilities ==