372
edits
Changes
Copy Capabilities to MC1.16 archive
Capability providers must also reflect changes in the ''exposure state'' of a capability, meaning that if the
Capability providers must also reflect changes in the ''exposure state'' of a capability, meaning that if the
accessibility of a capability from a certain <code>Direction</code> changes (refer to
accessibility of a capability from a certain <code>Direction</code> changes (refer to
[[#Accessing a Capability|Accessing a Capability/1.16]] for more information), it is the provider's responsibility to trigger
[[#Accessing a Capability/1.16|Accessing a Capability]] for more information), it is the provider's responsibility to trigger
a state response by invalidating the returned <code>LazyOptional</code> and caching a new one. This should also be
a state response by invalidating the returned <code>LazyOptional</code> and caching a new one. This should also be
performed when a capability gets ''invalidated'', such as when a capability provider gets removed.
performed when a capability gets ''invalidated'', such as when a capability provider gets removed.
via the event. This is done so that the attaching agent can have control over when, how, and where its capabilities are
via the event. This is done so that the attaching agent can have control over when, how, and where its capabilities are
exposed, instead of relying on the game itself deciding these parameters. For this reason, all considerations given in
exposed, instead of relying on the game itself deciding these parameters. For this reason, all considerations given in
the [[#Exposing a Capability|Exposing a Capability/1.16]] section on how to correctly create a Capability Provider.
the [[#Exposing a Capability/1.16|Exposing a Capability]] section on how to correctly create a Capability Provider.
With the above in mind, part of an attaching agent may be similar to the following snippet of code:
With the above in mind, part of an attaching agent may be similar to the following snippet of code:
should be queried. This can be done in a variety of ways and is outside the scope of this article. The user should
should be queried. This can be done in a variety of ways and is outside the scope of this article. The user should
then invoke the <code>getCapability</code> method passing the unique instance of the capability that should be queried
then invoke the <code>getCapability</code> method passing the unique instance of the capability that should be queried
(see [[#Obtaining a Capability|Obtaining a Capability/1.16]] for more information) and the querying <code>Direction</code>,
(see [[#Obtaining a Capability/1.16|Obtaining a Capability]] for more information) and the querying <code>Direction</code>,
if applicable.
if applicable.
Defining a custom Capability requires the user to provide three main components: the Capability Interface, at least one
Defining a custom Capability requires the user to provide three main components: the Capability Interface, at least one
Capability Implementation, and the Capability Storage. Optionally, a Capability Provider can also be created. In this
Capability Implementation, and the Capability Storage. Optionally, a Capability Provider can also be created. In this
case, the provider will be used as described in [[#Attaching a Capability|Attaching a Capability/1.16]]. The various details
case, the provider will be used as described in [[#Attaching a Capability/1.16|Attaching a Capability]]. The various details
for all these components are described in the respective sections of this article.
for all these components are described in the respective sections of this article.
store a single mutable <code>String</code>.
store a single mutable <code>String</code>.
Refer also to [[#Code Examples|Code Examples/1.16]] for an example on how the various components may be implemented in a
Refer also to [[#Code Examples/1.16|Code Examples]] for an example on how the various components may be implemented in a
real-world scenario.
real-world scenario.
The Capability Provider is an optional component of the capability that allows the Capability to be attached to a
The Capability Provider is an optional component of the capability that allows the Capability to be attached to a
component. The details on how a Capability Provider should behave have already been discussed in the two previous
component. The details on how a Capability Provider should behave have already been discussed in the two previous
sections [[#Exposing a Capability|Exposing a Capability/1.16]] and [[#Attaching a Capability|Attaching a Capability/1.16]]: refer
sections [[#Exposing a Capability/1.16|Exposing a Capability]] and [[#Attaching a Capability/1.16|Attaching a Capability]]: refer
to those for more information.
to those for more information.
This '''needs''' to happen when the <code>FMLCommonSetupEvent</code> is fired on the <code>MOD</code> event bus. The
This '''needs''' to happen when the <code>FMLCommonSetupEvent</code> is fired on the <code>MOD</code> event bus. The
registration will also automatically inject the created Capability into all relevant fields and methods: refer to
registration will also automatically inject the created Capability into all relevant fields and methods: refer to
[[#Obtaining a Capability|Obtaining a Capability/1.16]] for more information.
[[#Obtaining a Capability/1.16|Obtaining a Capability]] for more information.
An example of registration can be found in the snippet that follows:
An example of registration can be found in the snippet that follows:
[[Category:Data Storage/1.16]]
[[Category:Data Storage/1.16|Category:Data Storage]]