Access

Access requirements

Access requirements are generally held in the req_access var on atoms. This is a lazy list with valid entries being either strings or lists of strings. The strings represent access constants, and should correspond to (unique) access datums to ensure that user-facing code works correctly. The format is:

list(A, B) -> needs access A AND B
list(list(A, B)) -> needs access A OR B
list(A, list(B, C)) -> needs access A AND (B OR C)

On entities with complicated or dynamic access setting, the get_req_access proc can be overridden to supply something other than the value of the req_access var. As such, reading req_access directly is discouraged.

Differences from stock

• Access codes are strings, not numbers.
• There is no req_one_access; use req_access = list(list(...)) instead.
• Use get_req_access to retrieve access requirements.

Access on doors and areas

By default, most door subtypes will automatically inherit their access from the req_access var on the two areas adjacent to them and in the directions that they open. They do so in one of two different ways, depending on the areas' secure var:

• If at least one of their adjacent areas has secure = TRUE, the door will require all the req_access requirements on both areas to open.
• If both adjacent areas have secure = FALSE, the door will require only those req_access requirements that one area has but the other does not.

Note that in the case of OR-group access requirements, a minimal list of requirements satisfying the above properties is still computed, even if the computation is less straightforward. If a door is wholly contained in one area, then that area is used twice in the description above.

This behavior can be overridden in the following way: set autoset_access = FALSE on a given door, and then set req_access to the desired access requirements, in the standard format. If req_access is set without turning off autoset_access, it will be overridden; there is unit testing to check for this.

Differences from stock

• You should generally set req_access on areas instead of doors. Doors will then inherit access from the adjacent areas. This will lead to simpler and less error-prone mapping.
• If you wish to opt out of this system, either for specific doors or entirely, set autoset_access = FALSE and then set access on doors directly.

Checking access

To see if an atom/movable (actor) should have access to another atom/movable (target), the preferred call is target.check_access(actor). The older call allowed works similarly on mobs, but should be considered deprecated. These procs will search the actor for various entities granting access and then compare them against the target's access requirements; no searching by hand should be needed.

In cases where you wish to supply access codes available manually (e.g., the actor is not of the right type, or you wish to check against something other than all accesses the actor possesses), use target.check_access_list(list_of_access_codes).

In cases where you wish to supply access requirements manually, use the global helper proc has_access. The first argument is a list of access requirements, in standard format.

If you wish an item to grant access codes, use the helpers GetAccess and possibly GetIdCard. Generally, anything returned with GetIdCard is then checked using GetAccess, so you will need to ensure that the item you are designing both returns codes with GetAccess and is found with its holder's GetIdCard proc.

Differences from stock

• Use the above check and get procs instead of comparing access codes directly.