Access

+jhelp access

Anomaly Jobs has a tiered access structure. By changing who has access to various commands, you can selectively allow players like builders into the system so they can work. The access locks are on the Job Database  object. Bucket access locks are stored at the bucket level. HAS_ACCESS: Returns 1 if a player can access the +jobs system. COMPLETE_ACCESS: Returns 1 if a player can /complete jobs. APPROVE_ACCESS: Returns 1 if a player can /approve jobs. DENY_ACCESS:    Returns 1 if a player can /deny jobs. CREATE_ACCESS:  Returns 1 if a player can use the /create command. ADD_ACCESS:     Returns 1 if a player can use the /add command. GIVE_ACCESS:    Returns 1 if a player can use +bucket/access. EDIT_ACCCESS:   Returns 1 if a player can use the /edit command. STATS_ACCESS:   Returns 1 if a player can pull reports on the system. LOG_ACCESS:     Returns 1 if a player can /log a job. MAIL_ACCESS:    Returns 1 if a player can /query and /mail.

A player must pass HAS_ACCESS before the other locks are applied. Access to buckets are set at the bucket level (see 'baccess').

See also: baccess

+jhelp baccess

Bucket access is set on the bucket itself, as the ACCESS attribute: &ACCESS =[switch(get(%0/RACE),VAMPIRE,1,0)] It should return 1 for access and 0 for no access. You should make an effort to keep the access locks uncomplicated, as the broadcast code uses it to filter out non-receivers. Large locks can chew up that process on games with many people connected.