[#bugs] has someone reported the issue where the "equip (auto)" interaction sometimes do...

[Freehold Games Bot Account]

Marked for crossposting by: Ashe-No-Longer, Legendary Seeker

Message (jump):

<Soron> has someone reported the issue where the "equip (auto)" interaction sometimes does silly things with multiple limbs? e.g., croccasins on forefeet, leather boots on hindfeet, and "equip (auto)" on a new pair of croccasins replaces the forefeet (same item) instead of the hindfeet (inferior item)

[Brian Bucklew]

could you post a save that reproduces the behavior?

[Noelle Lavenza]

This can be reproduced on any save: if no empty valid slot exists, autoequipped armor will always be equipped to the first slot with a matching type, even if the armor it replaces is better than it. This is undesirable if there exists more than one valid slot, and the non-first one has armor that is worse than the autoequipped item.

A variant of/alternative to GetFirstPart that accepts a predicate to sort parts (or just using LoopPart(Slot).OrderBy(Predicate).First()) would be one method to solve this: if you sort the valid parts by PreciseArmorScore(bodyPart.Equipped) - PreciseArmorScore(equippingItem) (or the relevant predicate, although I believe this only occurs for armor) between their Equipped item and the item being auto-equipped, the item with the lowest resulting value will be the best item to replace.

[JRB]

I’ve reported this before, but it is relevant here. If you have no empty head slot then helmets are automatically directed to your first head, even if you have horns. (There are also grave issues with multiple faces and two-faced helmets, but that is probably a separate problem.)