Fix Select Equipment Presets #5758
Conversation
this pr looks like it was dancing around difficulties in when the name is loaded for clf synths, but didn't address the core issue - your pr would end up reverting the quasi-fix |
Did some further investigating, found the issue - you're absolutely correct that the PR's fix was really sloppy. The issue isn't tied to CLF Synths, it's tied to what happens when you Select-Equipment versus spawn in a new mob. What goes wrong, from just a couple minutes of testing, is that the 'broken' presets are those which call load_name() within their load_gear() procs. load_name() is already called when load_preset() is called, towards the beginning. So they get an ID with their first randomly generated name, and then again when their ID is spawned. If load_id() is after gear, then it's spawned in with their second generated name. If it's before, it generates with the first. The second reported error (Select-Equipment not changing names) is intentional. Select-Equipment, as opposed to ERTs and Create-Human, does not randomize. The first load_name() isn't triggered, and so they get an ID with their old name, and then get their mob name changed by the load_gear(). I assume this was done in an attempt to make it so people could be transformed into those Synth presets without needing to spawn in a new mob, but that's really not a good reason. SE for keeping a name but changing species and gear, Create Human and put a CKEY inside or spawn an ERT/Freed Mob if you want it to match. Patching in the fix now, at least for CLF Multipurpose Synth and UPP Combat Synth, by removing the secondary load_name() procs. This shouldn't impact normal gameplay at all, only makes it so spontaneously transforming someone into a synth with those presets by Select Equipment will not change their name at all, giving them an ID that matches their original name. Using VV to change their name (by clicking on the name) will automatically update the ID anyway. |
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
Screenshots & Videos
Put screenshots and videos here with an empty line between the screenshots and the
<details>tags.Changelog
🆑 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: