Keys overhaul

[Numbuh474]

Is your feature request related to a problem? Please describe.

As of now, there isn't a decent implementation of key/lock pairs. A system should be implemented that is able to generate reasonable pairings between keys and track what keys are able to open what locks. It would be hard to represent rare loot keys such as the various ID cards with "realistic" portrayals without making it frustrating for the player, so a chance-based key system should be added as a bridge between keys automatically opening everything and making the player hunt down one specific door to use it on. This also makes zombie-held keys easier to deal with as you don't need to go pick a house to bind a key to whenever you generate one.

Solution you would like.

• A key_type field for keys that defines what kind of locks a key is capable of interacting with. key_type should be an item property and the same for each instance of an item type.
  • Standard: house keys and potentially the "key" from the "small lock and key" item.
  • Simple: A type of key for a lock a survivor would be able to craft, such as a warded lock.
  • Card: RFID keys for keycard readers.
  • Signal: remote keys that can be used at a distance.
  • Magic: keys that work through magical means. Included here for Magiclysm but could be used in Nether buildings.
• A key_faction field for keys that describes what locks "unbound" keys should work with.
  • No faction: generic key type for things like civilian house or vehicle keys.
  • Industrial, Science, Military: things unlocked with their respective ID cards, as well as stuff you would expect to find in those areas.
• A key_data field that represents whether a key of a specific type can open a door. Some number pseudo-randomly assigned on item generation if applicable. Can use a null value to represent "unbound" keys or locks that can only be opened via prying or lockpicking.
• A binding_roll field for keys when "unbound" keys try to unlock something of the same type and faction. Unbound keys have a 1 in (bind_roll) chance to unlock that door and save its key_data.
• A no_open field for "unbound" keys. If a key fails a bind_roll that lock's 'key_data' is saved here so that repeated attempts will not work with that lock.
• A mapgen function for creating keys and locked doors that have the same key_data, with random permutations so that specific keys can be made to open specific locks.
• A vehicle gen function to assign key_data to a vehicle on generation.
• A way to activate keys on locked terrain, setting them as locked or unlocked.
• A way to activate keys on vehicles, behaving similarly to the "remote vehicle controller" but only allowing door control.
• A way to re-key doors and other lockable items.

In terms of items, the following changes would need to be implemented.

• Add house keys to map templates that are given the same key_data as any locked doors that generate on that tile.
• Certain doors, like vehicle doors, should be able to accept multiple key types.
• Add vehicle keys to vehicle templates that are given the same key_data as the vehicle.
• Craftable blanks that can be turned into copies of a "bound" key.
• Craftable "master keys" that are able to store multiple instances of "key_data."
• Change military ID cards into "unbound" military card items with binding_roll=1 that work with any military card readers.
• Make vehicle keys a variant of remote vehicle controllers that have a limited interact menu.
• Change science and industrial ID cards into "unbound" science or industrial card items with binding roll=5, to represent that not all cards should grant access to the same facilities.
• Add "unbound" house and vehicle keys to zombie inventories with binding_roll=50 to represent keys you could probably find a lock for if you were persistent enough.

Describe alternatives you have considered.

• A "Refugee Center" key_faction for sneaking into places you aren't supposed to be.
• A "Nether" key_faction for use with portal storm dungeons.
• Make it so military signal keys can pacify turrets, manhacks, and/or dispatches. It's not realistic that they wouldn't have some way to turn them off without risk of being shot.
• A "police" key_faction and corresponding item that can pacify police bots, for similar reasons to the above.
• An "Exodii" key_faction for whenever they reach a stable state and/or making someone slap themself with their own robot arms.
• A single_use field for keys that indicates they are deactivated or destroyed on (successful) use.
• Set binding_roll to null for decorative keys that will never open any locks.
• Make "unbound" keys map-local so they only work in or near the area they were generated in.
• Add a clearance tool quality that represents different levels of security or code complexity, for more realistic portrayals of special locations. For instance, military ID cards can be split into multiple variants where clearance 1 cards are able to open doors and clearance 2 cards are able to open both doors and ammo lockers. Clearance 3 cards can be used to open treasure vaults in addition to doors and ammo lockers, and so on.
• Change remote vehicle controllers into no faction signal master key items to represent the fact that vehicles usually require some form of cryptographic handshake with their keyfobs that you need to decipher.

Additional context

No response

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. Please do not bump or comment on this issue unless you are actively working on it. Stale issues, and stale issues that are closed are still considered.