[API] Constructing the default wrapper for ICuriosItemHandler causes NPE
Quarris opened this issue ยท 3 comments
Hey, I've been working on a mod with Curio compatibility and I've needed to create new instance of the ICurioItemHandler object, which is the CurioInventoryWrapper.
I used the default Capability way, which is to invoke the Capability's factory directly, however this creates the Wrapper object with null
player and immediately uses that null player causing NPE.
This can be found here: CurioInventoryWrapper#ctor
Would you be able to not call this(null)
and instead possibly add an init(PlayerEntity)
method in the API which would assign the player to the wearer and call the reset()
method?
Thanks!
I've fixed the NPE, but decided against adding an API method for initializing/setting a particular player to a capability instance. I think trying to decouple a capability instance from a player could be problematic. In addition, Forge has removed the default instance altogether in 1.17+ so it wouldn't be a long-term solution anyways.
Instead, I've addressed a different issue that could be applicable here where I expose new API methods to load and save the inventory from NBT which should hold all of the logic necessary to do so cleanly without needing to accommodate for Curios changes down the line.
I'm assuming that the NPE comes from this line that references the wearer before null checks:
Couldn't the fix just involve adding a null check here and that'd be it? Is there a specific reason you need the ability to instantiate an empty Curio handler and set the player later? I'm also curious what you mean by invoking the capability factory directly as I've only seen people instantiate a new provider in AttachCapabilitiesEvent
where the player is a known object. Basically, I'd need to know your use-case in more detail before developing a proper solution.
I'm working on a grave mod and I need to save data from Curios. Currently Im saving the curio stacks directly as a map of strings to list of items which works okay-ish but is prone to bugs when curios changes or there is more data to be stored.. Ideally I'd simply be able to store an instance of the capability and serialize/deserialize it during saving/loading.
Doing a simple null check might work, but from what I can tell, the wearer is needed during deserialization, so being able to set it might be needed in this case.
By the Capability Factory, I mean using Capability#getDefaultInstance
which is registered here: