Potential bug?

[Erfurt92]

Hey, I'm trying to make some jewels that have effects and attributes, they also have durability, and that seems to be causing a problem. I'm using the onCurioBreak method, which I assume triggers the Unequipped method. Everything works fine when I just unequip a jewel. However the effects remains on the player when a jewel breaks. The effects seem to be because there's a bug on my end, where you replace the jewel with another in the same tick. As far as i can tell, when a jewel breaks it's replaced with Air, not sure what's that about? The attribute though, also remains attached to the player, and I can't for the life of me understand why... The attributes are not affected by the same bug that's present with the effects.

Here's my code for my jewel class, it's messy AF I know: JewelItem class

[TheIllusiveC4]

There does seem to be an issue with effects persisting. More accurately, empty item states are being ticked when they shouldn't be. That's why effects persist when they break but not when they're removed manually. I'll fix that momentarily.

I'm using the onCurioBreak method, which I assume triggers the Unequipped method.

This is incorrect usage. If you refer to the javadocs commentary on the method, it says Called when rendering break animations and sounds client-side when a worn curio item is broken. If you look at the default implementation, you'll see that it is only used for playing the broken sound and rendering the broken particles. It does not call any other logic and is only meant to be overridden to perform custom client-side breaking behavior.

As far as your attribute issue goes, I'm not sure there. All I can suggest is to make sure your removal method is catching them accurately. Unless you're doing some custom logic, attributes must always return the same map in order to remove the right ones.

[Erfurt92]

Ah I see, I'll take another look at my code then, thanks for the help

[Erfurt92]

@TheIllusiveC4 In version 2.0.2.4, it still seems to be a bug, unless the bug you found was unrelated to this.
This works fine on ring slots.

[TheIllusiveC4]

Sorry, I didn't realize that you mentioned something like that previously. The equipped and unequipped methods will only be called if the items are different to prevent repeated calls when durability or something else changes but the item remains the same. That's not a bug per say, although it's possible this warrants a change.

Something I'm very curious about though is that you say it "works fine on ring slots". There's nothing special about one slot or another, they all behave exactly the same. Are your rings coded differently than your amulets?

[Erfurt92]

I see, nothing's different. However I didn't realize that, that was how it worked, so I might have used two different items when I checked the rings. I have a gold and a silver variant of both amulet and ring, so 4 registered items. I basically just did a really quick test, when I saw this "bug" appearing, and I could see that it worked fine. The amulets in the gif are both of gold variant, so that's the problem there. Thanks for the reply, I hope that you'll consider changing it at some point, even if it's for the 1.16 release :)