Bug: [1.21.1] Corpse Curios Compat puts armor inside invisible Accessories Slots used for Cosmetic Slots
benniekiss opened this issue · 19 comments
What Feature Types Apply to This Bug?
API
Feature Type
No response
What Type of Bug Is This?
Compatibility
Minecraft Version
1.21.1
Mod Loader
Neoforge
Mod Loader API Version
21.1.172
The Accessories Version
1.1.0+beta.43
What Compatibility layer are you using?
Curios
The Compatibility Version
2.2.2
Is This Bug a Conflict With Another Mod?
Corpse x Curios API Compat
Client Log
No response
Crash Report (if applicable)
No response
Steps to Reproduce
- Equip armor (type is unimportant)
- Kill player
- Collect inventory from corpse
- Equip different armor (different type to illustrate bug)
- Kill player
- Collect inventory from corpse
What You Expect To Happen
The armor that was equipped before each death, and which is visible on the corpse, should be equipped when the inventory is transferred from the corpse to the player.
When used with Curios directly, the functionality works as expected.
What Actually Happened
After the first death, the equipped armor disappears from the player inventory after transfer. After the second death, the newly equipped armor disappears, however, the armor from the first death reappears. Subsequent deaths alternate between which armor is present in the inventory.
Additional Details
This was initially reported here Leclowndu93150/Corpse-Gravestone-Curios-Compat#14
Modrinth mod pages:
Corpse
Corpse x Curios Compat
Please Read and Confirm The Following
- I have confirmed this bug is on the most recently supported version of Minecraft.
- I have confirmed the details provided in this report are concise as possible and does not contain vague information (ie. Versions are properly recorded, answers to questions are clear).
- I have confirmed this bug is unique and has not been reported already.
- If playing on a modpack, I have reported this bug to their issue tracker already.
@HotFudgeCherryRosy You should use Cosmetic Armor for "transmog" (because the cosmetic slots are kept on death with Corail Tombstone).
There is no support for "Accessories" with Corail Tombstone (because it changes the behavior of Curio, the proof being when the dropped curio were not in the drop event in one previous issue).
Also, Minecraft is probably the only game when in modding the "cosmetic appearance" is really dropped... instead of being just a visual appearence.
Unfortunately, Simple Hats seems to only support Accessories for some reason. I am working in KubeJS for some sort of workaround right now.
Dumping player data from KubeJS seems to show two separate slots labeled "accessories:head", "accessories:chest", "accessories:legs", and "accessories:feet" in some way. One set under "accessories:inventory_holder"."accessories_containers" and another set under "curios:inventory".Curios. The lost armor is in the former slots. There seems to be some sort of item list under the accessories slots that cause them to hold multiple items at once.
@Leclowndu93150 It seems here that the corpse compat mod attempts to keep track of where a stack was equipped but not if the stack was equipped in the cosmetic slot or the primary slot, leading to items being equipped in the wrong slot if i.e., they were only equipped into the cosmetic slot. Adding an extra boolean for if it was equipped cosmetically first prevents cosmetics from being equipped into primary slot
There is no support for "Accessories" with Corail Tombstone (because it changes the behavior of Curio, the proof being when the dropped curio were not in the drop event in one previous issue).
Such has been fixed already and if I remember looking at decompiled source that Corail just dose not keep track and attempts to just auto equip items with and regard to where their were which justs means it can be inconsitent if containers resize or if it was within a cosmetic slot vs primary slot.
@Dragon-Seeker I don't say it won't work, i just say that i don't add specific code for Accessories. (and you're right, i don't track where are equipped curio items, i use the order that they were dropped to know where to re-equip them). To my opinion, it's more a problem of implementation of "transmog". Theses items shouldn't be real items, they should only provide the model to render. And they should stay on the player on death if there is no better implementation (item capability or permanent slot skin, or any better solution).
i have tracking code if you want, just check my source :) but i use a custom event from my lib
I resolved the issue by exchanging the Curios Compat mod with the Curios API, using Accessories only for SimpleHats, and installing Cosmetic Armor. @Corail31 thank you for the recommendation
@Dragon-Seeker I don't say it won't work, i just say that i don't add specific code for Accessories. (and you're right, i don't track where are equipped curio items, i use the order that they were dropped to know where to re-equip them).
To my opinion, it's more a problem of implementation of "transmog". Theses items shouldn't be real items, they should only provide the model to render. And they should stay on the player on death if there is no better implementation (item capability or permanent slot skin, or any better solution).
...it's more a problem of the implementation of "transmog"
The problem is that you expect two things when handling any of the current accessory mods:
- All accessories are designed to be equipped only within the a single slot type and can not be equipped in another type
- Slot type containers can not be resized
Such allows you to then use a iterable to re add the stacks that are in the primary slots and not work about any cosmetics but the problem is that in all accessory API's this can occur where a stack can be equipped into any slot or another slot meaning when iterating over the stacks given and trying to push it into a slot index, you could shift accessories into a slot it was not before combined with cosmetic stacks possibly disappearing since the containers can also be resized leading to missing cosmetic stacks.
Like the implementation is not going to insure that its consistent in any accessory API and that is why I suggest to use other mods who track properly the equipped slots, toggles, and even cosmetic stacks.
Futhermore I have plans to add support for the "ghost" stack for cosmetic slots to prevent abuse of people who use it as storage for another set of accessories that can be easily swapped but such comes with its own downsides with iteracting that was pushed back to later time.
@Dragon-Seeker I'm just replying for the sake of discussion, but personally, I don't care ;)
Storing the location of curio items where slots can be removed/modified later would just be a source of problems.
@Leclowndu93150 I only use a tracker for the offhand slot.
Using the drop order guarantees finding the slots (and won't change a lot to where they were before) and is much faster and less cumbersome to store.
The real problem is more related to these cosmetic slots, which are simply illogical and only correspond to a tricky use of how to make 'transmogrification' based on what exist in Curio (and just make tons of items to store and iterate on death).
Storing the location of curio items where slots can be removed/modified later would just be a source of problems.
Like, there is an increased amount of complexity, but its just a record object holding onto some simple values like SlotType, Index, and whether it was within the Primary or Cosmetic section. Like that is not that compared to what will be consistent as even with what I said the removal of cosmetic slots as a factor still leave some amount of issues with inconsistencies due to the nature of ALL accessories APIs (Trinkets, Curios, Accessories) as such can be reszied and Accessory's have the possibility to be equipped into other slots.
Using the drop order guarantees finding the slots (and won't change a lot to where they were before) and is much faster and less cumbersome to store.
Faster would be to store the exact positions to then attempt to set into those slots if empty, if something already exists, replace it with the stack from the grave (If you want to) and then dump the other stack into the inventory if not possible to equip. Like that would be faster than just randomly iterating the stacks of drop accessories to then attempt to insert the stacks inside the entities' containers
The real problem is more related to these cosmetic slots, which are simply illogical and only correspond to a tricky use of how to make 'transmogrification' based on what exist in Curio (and just make tons of items to store and iterate on death).
I am not going to beat around a dead horse, but like I think even with the concept of how the slots could be changed, it will not fix that in some cases, it's better to fully restore the state of accessories from a backup of exactly where things are equipped, as the API's are dynamic.
@Leclowndu93150 If you do make such a change to adjust the cosmetic vs primary slot equip, this should be fixed from occurring in the future, and I can most likely recommend your mod over others if people do not prefer grave mods.
I am having this problem with Corail Tombstone, where upon death and recollecting your gear from the tomb, armor is being put in slots 114b, 116b, 118b, 126b, which are inaccessible.
If the player dies again with a set of cosmetic armor on, the cosmetic armor disappears and is replaced with the "lost" armor.
Using most recent versions of Accessories, Curios Compat Layer, and Corail as of 8/13/25.
Seen a discord message about this and the response is most likely down to the fact that the armor is being but into the logical side as a curios since Accessories adds cosmetic slots leading to the armor just being in an inaccessible area for players,s which is not ideal... It really should properly track where the slots are for equipping them back into the correct slots, instead of just trying to equip it, but this ideally should be patched to prevent it from happening.