This is half code half game design, I apologise in advance.
-Punished Urist, The Game Designer Rejected By His Fellow Comrades.
Overview
Access is based on three components, ID, AccessReader and Access. An AccessReader has functions that, well, read a given Access component and tell other components and the entity itself whether access is granted or denied. This is usually done through one or two entities - an ID lock and, optionally, a signal splitter (see #30). Some access attempts are also recorded in a remote security console (via an AccessLogger component).
Access component
An Access component can hold several tags, such as “security”, “medical” and so on. These are strings that can be defined at runtime, not enums.
ID component
An ID component is an extension for Access. Access can exist without ID, ID can’t exist without Access. It holds a name of the ID’s owner, the job name and a “unique” number (well, ID). The third value follows a specific format and is generated at the beginning of the game for every ID assigned to a mob (human, AI, cyborg), guaranteed to be unique at that time. It is then recorded in a database on the station along with the associated name/job pair. After the ID number is generated, it can be edited with special tools in order to throw investigators off-track, and so can its database value.
AccessReader component
An AccessReader component has a list of rules, each of which is either in “OR” mode or “NONE” mode and has a list of tags. When an Access gets passed to the AccessReader it gets compared to each rule in the list, and if all rules are met, then the test is considered passed; otherwise it is considered failed. When an entity gets passed, it tries to find the Access item using the entity’s rules (for example, a human mob would tell about the Access-providing PDA in the PDA slot). If it does, it uses that as above. If it doesn’t, the test is automatically failed.
An “OR” mode rule is met if there’s at least one match between its list of tags and the Access’s list of tags. A “NONE” mode rule is met when there’re no matches between its list of tags and the Access’s list of tags.
If there is an AccessLogger component on the entity then it tells that component the time, success value of the attempt and the using Access’s entity’s ID component, if any.
Example
An AccessReader has the following rules: “OR”: “medical”, “security”; “NONE”: “engineering”.
It will pass the following Accesses: “medical”; “medical”, “security”; “security”, “botanical”.
It will fail the following Accesses: “medical”, “engineering”; “medical”, “security”, “engineering”; “botanical”
AccessLogger component
An AccessLogger component sends messages to a connected security console containing a link to the entity, ID information, date and success value of access attempts when it receives information about them. It has two bool values, “send successful attempts” and “send failed attempts”, which determine which attempts it logs.
The default (not-overriden behaviour) AccessLogger requires a Device component. It sends information about successful attempts only in powered mode and about successful and failed attempts only in powered or power-saving mode.
ID lock
A simple entity with AccessLogger, AccessReader, Device, RCOutput(#30). When interacted with using a PDA or a built-in ID service (for AI and such), checks the Access with the AccessReader and tells RCOutput to output an instant signal, “passed” or ”failed” depending on whether the test passed or failed. Its AccessLogger component is disabled by default but can be enabled and set up depending on where the ID lock’s used.
PDA
A held item with Access, ID components and a lot of other stuff (more on that in a separate PDA design doc). Generated for a player at round start. Goes into a separate inventory slot. When a mob with a PDA slot is asked for its Access, if it doesn’t have an Access component, the PDA in the PDA slot is automatically used.
Security logging and ID database
A single security console and a single ID database are located on the station. These are used to store information about access attempts across the station and everyone’s IDs, respectively.
The security console lists all the attempts sent to it by AccessLoggers across the station, but only up to X entries (on a FIFO system). The UI includes filtering by entity and getting info from the ID database via a click on the ID. It can be hacked and edited to remove, add or modify entries.
The ID database holds the information on all the round-start generated IDs and the associated name/job pairs. When something needs to know information about an ID, it asks the database. It can get updated information from ID editing consoles or hacked directly in order to add, remove or modify entries. It can never have two separate entries with the same ID numbers.
ID editing console
Edits a PDA’s ID and Access values - name, job, access tags. Has job + access tags presets. Can be hacked to also allow editing the ID number directly.
UI
Basically there’s UI for editing rules on AccessReaders and UI for editing tags on Access and UI for editing an ID. Dunno, it’s pretty simple but I ain’t visualising it just yet.