mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2026-01-26 00:51:23 +00:00
febf4308d4
<!-- Write **BELOW** The Headers and **ABOVE** The comments else it may not be viewable. --> <!-- You can view Contributing.MD for a detailed description of the pull request process. --> ## About The Pull Request As part of the ore silo logging PR I'm working on I needed a way to get the information on someone's ID in a robust and consistent way. I decided on adding this proc to SSID_access and also adding a define to invoke it since it's otherwise quite verbose. ``` /datum/controller/subsystem/id_access/proc/__in_character_record_id_information( atom/movable/target_of_record, bypass_chameleon = FALSE ) as /alist #define ID_DATA(subject) SSid_access.__in_character_record_id_information(subject) ``` This proc expects either a living mob or an ID. It returns an alist of: "Name" Current ID name "Age" Current ID age "Assignment" Current ID job "Account ID" ID# of the attached bank account if a standard ID, random number if chameleon ID "Account Holder" Name of attached bank account holder if one is attached, current ID name if chameleon "Account Assignment" 'title' of the job datum of the attached bank account if normal ID, current ID name if chameleon "Accesses" a list of the accesses on the ID, in the style of our other access lists Additionally, if it fails to read an ID, it also adds [ID_READ_FAILURE] = ID_READ_FAILURE Finally, there are overrides for if The card is a chameleon card. The being scanned is a silicon. Which appends, respectively, .[SILICON_OVERRIDE] = SILICON_OVERRIDE .[CHAMELEON_OVERRIDE] = CHAMELEON_OVERRIDE And does special handling. This collects a significant quantity of relevant information into a single convenient proc call, which is also named to reflect that the information returned is meant to serve as an in character record of what is being read (if it is used anywhere). <!-- Describe The Pull Request. Please be sure every change is documented or this can delay review and even discourage maintainers from merging your PR! --> ## Why It's Good For The Game Offers standardized information returned from an ID for scenarios where the information of an ID is especially relevant, rather than writing boilerplate ID reading code for varying situations. <!-- Argue for the merits of your changes and how they benefit the game, especially if they are controversial and/or far reaching. If you can't actually explain WHY what you are doing will improve the game, then it probably isn't good for the game in the first place. --> ## Changelog <!-- If your PR modifies aspects of the game that can be concretely observed by players or admins you should add a changelog. If your change does NOT meet this description, remove this section. Be sure to properly mark your PRs to prevent unnecessary GBP loss. You can read up on GBP and its effects on PRs in the tgstation guides for contributors. Please note that maintainers freely reserve the right to remove and add tags should they deem it appropriate. You can attempt to finagle the system all you want, but it's best to shoot for clear communication right off the bat. --> 🆑 Bisar code: A proc has been added to the subsystem for ID access to serve to standardize the way information is read and returned from a given ID. /🆑 <!-- Both 🆑's are required for the changelog to work! You can put your name to the right of the first 🆑 if you want to overwrite your GitHub username as author ingame. --> <!-- You can use multiple of the same prefix (they're only used for the icon ingame) and delete the unneeded ones. Despite some of the tags, changelogs should generally represent how a player might be affected by the changes rather than a summary of the PR's contents. -->