fix (accessories, fabric): various issues relating to accessories being voided / duplicated / not displaying / incorrectly named

[Aquaeyes]

Fixes for:

• Dispensers equipping accessories into all slots.
• If the entity could generally equip an item, but could not under the current circumstances, it will void the accessory when trying to equip it. e.g. if all slots are filled, an accessory will be voided.
• Trinkets breaking when the Aether Accessories menu is created - due to creating an instance of InventoryMenu, which generally is only instantiated once, Trinket slots will be recreated, which can cause duplication glitches.
• Entity accessory drop chance setting being wholly disconnected from the actual accessory being set to always drop, leading to either potentially the wrong accessories dropping with 100% chance, or the right ones not dropping.
• Aether Accessories Menu failing to open with the Curios Slots option enabled, instead printing an exception to the log.
• Aether Accessories Menu not displaying Curios/Accessories slots with the Curios Slots option enabled
• Hardcoded slot names and the Curios Override datapack all reference default Curios slots, not default Accessories slots.
• When in the default capes slot, Aether Capes render as an item as well as displaying the cape renderer.
• If a mob has had it's Accessories capability removed, it can still pick up accessories, voiding them.
• If a slot-count changing item is added or removed whilst in the Aether Accessories menu, unlike the main Accessories menu, the menu does not reopen, as such, the items may be duplicated by being both placed into the player's inventory, and remaining in the still-visible removed slots.
• If more or less than six - the number expected by the mod - non-charm/miscellaneous accessory slots are present, the charm/misc accessory slots will be placed beginning at the leftmost slot's x position.

Caveats:

• The cursor position will reset to the centre when re-opening the Aether Accessories menu due to slot count changing. This doesn't happen often, however, and seems preferable than item duplication or voiding.
• The Curios Override Datapack is still named such, as changing this seems like it could break already-set user configs?
• The accessory slots will still visually overflow the pre-drawn bounds in the Accessories Menu if more than eight exist, though it should be somewhat less due to preventing the charms/miscellaneous accessories from traversing rightwards. Fixing this fully would probably require the screen as a whole to be entirely different, which seems somewhat out of scope. It works as intended, and looks mostly as presumably intended.

Closes issue #2636.

---

I agree to the Contributor License Agreement (CLA).

[Aquaeyes]

If it is relevant, the following were tested before, and after the above fixes. To disclaim, some of the tests were done preceding further fixes, but there should be no change to the functionality borne of those changes.

• Standing in front of a dispenser filled with Zanite Pendants, and repeatedly triggering the dispenser, would fill the player Aether Accessories inventory with 8 pendants, and void the ninth. After the fix was implemented, only one pendant would be equipped. The same was tested with Zanite Rings, and only two were able to be equipped after the fix.
• Both testing with a mod mimicking Accessories' API, and with the default, base Aether installation alongside Trinkets confirmed that opening the Aether Accessories Menu would break Trinkets upon initialisation of the Menu ScreenHandler. As it stands, even though not directly touching Trinkets, having the Aether installed at all will cause a duplication bug with it upon opening the Aether Accessories Menu. Confirmed to not occur in both dev and outside of dev environments post-fix.
• A Zombie that could equip items was spawned, with both a Zanite Pendant and Valkyrie Gloves equipped. Stepping through the drop code revealed that if only one is equipped, it would check the hands drop chance first - then necklace, then aether_gloves, then aether_pendant - no matter the item that was being checked against, or the current setting of whether default slots should be used. At some point, a commit - a HashMap to translate was used in the interests of backwards compatibility, as I am unsure if any addons rely on the current behaviour. The filtration was removed in commit #1c20356 - the new solution checks if the slot can contain the item before modifying drop chances, and doesn't touch Accessories outside of that scope. Previously, other accessories from other slots would be voided, and the slots that Accessories fit in were hardcoded, making modification by datapack to add additional slots, or by compatibility mods, incompatible. Afterwards, Zombies would drop precisely the items that were given to them, and not modify the drop chances of Accessories already equipped. It is, however, worth noting that mobs that can equip items do not always overlap with mobs that can spawn with accessories. Additionally, if a slot is somehow queried for a non-Aether-supported slot, it will not modify the drop chances.
• If the requested, hardcoded slots for the Aether-specific slots do not exist, then the Aether Accessories menu would not open. This also affects the ability to access the Aether Cosmetics menu through the menu. This was both null-checked to open if the requested slots did not exist, and changed to use the 'Curios' slots if set as well - tested working both with no slots enabled, and with the alternative, default slots enabled.
• Previously, the Accessories Mod would use the default renderer for the cape accessory - simply rendering it as an item on the back of the equipping entity. The capes now have a registered renderer that renders nothing, deferring to the Cape Layer rendering. This has also been tested to work on armour stands, where it is particularly visible.
• Prior to the change to Accessories Slots, changes were tested with custom-added slots to mimic the Curios slot names. The change to use Accessories Slots satisfies Bug: Duplicative Ring Slots in Accessories with Trinkets #2636 and allows for use with Accessories Slots, instead of Curios slots, which do not exist on Fabric.
• If a mob has its Accessories Capability removed, it would be able to pick up items, but those items would not be added to the inventory of the Entity, even though its chances of dropping the item would be set to certain.
• Whilst the Accessories Menu re-opens to show updated slot counts, the Aether Accessories Menu does not. If an accessory that modifies the number of aether_rings to 0 was equipped whilst in the menu, then the rings would both drop, and remain in their slots, creating a duplication bug. This appears to have been resolved by reopening the Aether Accessories Menu upon the Accessories mod reporting slot count modification through ContainersChangeCallback, with the slots, and items inside, being rendered inaccessible. Also highlighted through testing was that the left-justification for positioning of the charms / aether_accessories was tied to the exact slot count, which could lead to a slot overlapping itself, or, more likely, being positioned far to the right of the screen. By resetting x coordinate by the first charm / aether_accessory slot, instead of by the 6th overall slot, this did not occur again in testing.

I am unsure if this is enough information regarding the testing of the above changes, if more is required, I would be more than happy to test additional scenarios suggested?