Line 18: |
Line 18: |
| == Terminology == | | == Terminology == |
| The high flexibility of the system comes with a cost, though, which is terminology. The following section wants to be a dictionary of sorts, defining all the terms that you may come across when dealing with capabilities. | | The high flexibility of the system comes with a cost, though, which is terminology. The following section wants to be a dictionary of sorts, defining all the terms that you may come across when dealing with capabilities. |
| + | |
| + | In the rest of this article, we will refer to these terms frequently, so make sure you are familiar with them. |
| | | |
| * '''Capability''': the ability to perform something; in-code this is represented by the <code>Capability</code> class. | | * '''Capability''': the ability to perform something; in-code this is represented by the <code>Capability</code> class. |
− | * '''Capability Provider''': | + | * '''Capability Provider''': something that is able to support capabilities and provides a mean of accessing them; capability providers come in multiple kinds. |
| + | ** ''Volatile Provider'': a provider that doesn't persist data to disk; once the provider ceases to exist for any number of reasons, all capability data gets deleted. |
| + | ** ''Persistent Provider'': a provider that requires all capabilities to serialize data to disk, in order to persist data even across game restarts. |
| + | ** ''Agnostic Provider'': a provider that isn't neither volatile nor persistent, rather delegates the decision either to the capability directly or to sub-implementations. |
| + | * '''Capability Interface''': the interface that defines the contract of the capability, so what operations the capability exposes. |
| + | * '''Capability Implementation''': one of the possibly many implementations of the capability interface, that actually carries out the work; one of the various implementations may also be considered the '''default capability implementation'''. |
| + | * '''Capability Storage''': the manager that handles loading and storing persistent capabilities data from and to disk, guaranteeing preservation of information; in-code this is represented by an implementation of the <code>Capability.IStorage</code> interface. |
| + | |
| + | == Forge-provided Capabilities and Providers == |
| + | In order to ensure mods can work together seamlessly, Forge provides a set of default capabilities and capability 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 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. |
| + | |
| + | === <code>IItemHandler</code> === |
| + | |
| + | === <code>IFluidHandler</code> === |
| + | |
| + | === <code>IEnergyStorage</code> === |
| + | |
| + | == Operating with Capabilities == |
| + | |
| + | === Exposing === |
| + | |
| + | === Attaching === |
| + | |
| + | == Creating Custom Capabilities == |
| + | |
| + | == Code Examples == |
| + | |
| | | |
| | | |