Immersive Engineering

Immersive Engineering

134M Downloads

Conflicting ToolTip generation issue

skiprocks999 opened this issue ยท 5 comments

commented

Hello,
I ran into this is conflict here while creating a new capability for my mod (see attached). I have been using Immerisve Engineering to assist me in development, as it will list the ore tags associated with items (a feature which is invaluable). From what I can tell, it is an issue with adding Tool Tips to the item that I am adding a capability to.

The method responsible for this is an override of the addInformation() method in my ItemClass. To generate the tooltip, the method first reads the new capability I added, and then generates if if the capability exists.

I have attached a link to the code in question here: https://github.com/skiprocks999/Electrodynamics-JEI-Integration/blob/1.16.5/src/main/java/electrodynamics/common/player/armor/CompositeArmorItem.java

Let me know if I need to provide anything else!
crash-2021-07-05_16.34.59-client.txt

commented

This is a bug in your mod: Every capability provider on an ItemStack, TileEntity or whatever is asked if it has the capability that was requested and you are returning your capability without checking which capability was requested. Out of pure coincidence your provider is asked before the provider from IE which results in IE getting your capability when asking for one of its own capability and crashing. The offending code is here: https://github.com/skiprocks999/Electrodynamics-JEI-Integration/blob/1.16.5/src/main/java/electrodynamics/api/capability/compositearmor/CeramicPlateHolderProvider.java#L21

commented

So would I need to check in the methods calling the Capability if it is an instance of mine? Or would I need to handle the return of the getCapability() method?

commented

In getCapability() you check if the Capability object passed in is equal to this field: https://github.com/skiprocks999/Electrodynamics-JEI-Integration/blob/1.16.5/src/main/java/electrodynamics/api/capability/compositearmor/CapabilityCeramicPlate.java#L15. If it is, you return your capability, else you return null.
Normally you would call super.getCapability() instead of returning null but in this case there is no super class with an implementation of getCapability().
See https://mcforge.readthedocs.io/en/1.16.x/datastorage/capabilities/#exposing-a-capability for more details.

commented

Got it working thanks. I went ahead and had it return LazyOptional.empty(), as that will at the very least avoid any null pointer exceptions.

commented

Yup, that was an error on my part, returning LazyOptional.empty() is the correct way, null is wrong there.