Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Fix Select Equipment Presets (#5758)
# About the pull request <!-- --> This is literally a one-line fix to an apparently unnoticed bug affecting multiple loadouts, particularly certain ERTs. Explanation below. Select Equipment now spawns in an ID before equipment. # Explain why it's good for the game <!-- --> ID Locks check via the COMSIG_ITEM_ATTEMPTING_EQUIP signal when someone tries to equip them, and searches for an equipped ID to lock with. If there's none, it cancels the equip. /obj/item/proc/mob_can_equip() sends out that signal as part of its testing, and the usual mob equip_to_slot_or_del() proc used in most presets ends up checking the item's mob_can_equip() before equipping. IDs were generated AFTER equipment within /datum/equipment_preset/proc/load_preset() in _select_equipment.dm. This means every single item with an ID lock would be spawned in, the mob would see if it could equip them, the item would return no, cancelling the equip, and the item would be deleted. Pre-equipped Spec loadouts were the most affected, losing all of their armor and ID-locked sights. Most special ERT NVGs were affected as well, being subtypes of the Sniper Spec's NVGs, and sharing the same MOB_LOCK_ON_EQUIP flag. **If there's a reason IDs were spawned in after, this might break something, but I doubt it. Just went tracking once I noticed this bug, and found this as the most effective solution.** An alternative solution was to use the unsafe equip_to_slot() proc instead. # Testing Photographs and Procedure <details> <summary>Screenshots & Videos</summary> Put screenshots and videos here with an empty line between the screenshots and the `<details>` tags. </details> # Changelog :cl: Kaga fix: Fixed a bug that broke ID-Lockable items in presets. Rejoice, PMC Snipers, pre-equipped USCM Specs, UPP Commandos, and WY Deathsquads. /:cl:
- Loading branch information