Keycard authenticators now authenticate keycards #2721
+15
−4
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Keycard Authentication Devices now require a keycard to use, not just access, and also require the initial card to not be the confirming card.
Bokkiewokkie
approved these changes
Dec 8, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
About The Pull Request
Keycard auth devices currently do not check whether the target using them has an ID card, despite being card auth devices (implying some physical component to the authentication).
They also do not ensure the two keycards being used are not the same, which allows a single user to perform this activity.
This PR makes keycard authenticators require an ID to swipe (This affects Silicons since they fall into the "has access but does not have IDs" category. They shouldn't really have access to these as opposed to humanoid crew, which is the main point of this requirement).
Additionally, the IDs used for triggering & confirming the requested action must be different. This is a "soft" requirement in a way, as it does not prevent you from making two IDs and switching between them while also managing to reach both devices, intended as a weak point while also not being as easy to achieve as the original bypassing methods.
Mirrored upstream at BeeStation/BeeStation-Hornet#12002
I remembered I made this change elsewhere ages ago when I saw two authenticators reachable from the same tile on the Tycoon, so I decided to remake that old PR here (and mirror it to bee so I don't have to //nsv13 but if it gets closed I'll just do that)
Why It's Good For The Game
Keycard Authentication Devices should authenticate keycards.
Their main intent was to create a two-step auth process akin to submarine movies, but at this time can easily be bypassed via either silicons (who are not humanoid nor command and thus NT wouldn't trust with these), or via quick movement methods / two auths being near eachother.
This rectifies the former, while also making it somewhat more difficult to "solo auth", incentivizing command cooperation.
Testing Photographs and Procedure
Screenshots&Videos
(Testing was repeated here but screenshots are from bee testing since I don't feel like taking new ones :) )
Silicon response
Evil captain trying to solo auth
Changelog
🆑
balance: keycard authentication devices require an ID to use.
balance: IDs used to initiate / confirm keycard auth events must not be the same ID.
/:cl: