Locks

[Taunya]

Currently locks and keys on TI all have a unique number that make them work together, which can't be changed by players.
So while some crafters can make safes, they can't make specific keys for them- it requires a request board, as does rekeying a door.
I'd like to propose a new system for locks that would enable crafters (I suggest jewelcrafters) to become locksmiths.

The most common locks in the middle ages were warded locks (https://en.wikipedia.org/wiki/Warded_lock).
Inside such a lock are wards- obstructions that block just any key from turning in them. The second key here is a neat example of a more complicated one: https://people.duke.edu/~ng46/collectio ... s-keys.htm

My proposed system would be based on this. Keys and locks would be matched up by:

a) size
b) type
c) wards

Recipes could be made for various sizes and complexity levels of locks, and finished in a POLCA to choose the type and wards and finalize the lock/key.

The sizes- small, medium, or large mainly refers to the size of the key and keyhole. A small key won't work in a medium or large lock and so on. Larger keys keys also have more space for wards than smaller keys. The sizes could also make sense for installing on containers like jewelry boxes vs on doors.

The 'types' could have neat thematic names or just be simple Type A, Type B, Type C, etc, and refers the the general mechanism. Basic locks would be limited to two types, hard locks ten or so, infuriating twenty or more. When it comes to picking locks, this will be the main determination of the difficulty. 

Wards - Besides the size and type, this is the main determination on if a key will work in a lock or not, but has no bearing on the difficulty to pick. A small, simple lock would only have one or two wards, and larger and more complex locks can have a larger number of wards, reducing the chance that someone else's key would work in the lock. However, it should also be possible to make locks that work with one key, plus a master key.
I can't think of a better way to represent wards textually, so perhaps just letters and spaces. A space will be empty, and a letter would represent a shape- but in practice, you can just put in any word. Lets say you have locks made for your phome with all of the locks the same size and type, and the maximum wards for your key size is eight, "MY HOUSE" could be the front door, "MY ROOM " could be the master bedroom "MY KIDS " could be the nursery, and so on. None of those keys would unlock the others' locks, but you could have a master key "MY      " that would open all of the above locks. Note that all spaces "        " would be a skeleton key that would work with any lock of that size and type.

My thought for lockpicking is to use an interactive mini game similar to the current medicine treat system, which will assist in picking the correct pick, which is really a skeleton key, for the lock. The higher the level of lockpicking, the fewer attempts you would need to pick the right one.
As proposed, it could also be possible to unlock with individual skeleton keys without the lockpicking system, by acquiring all possible sizes and types of skeleton keys- if there's 3 sizes and 20 types, that would be 60 different keys. It would be a bit unwieldy and tedious compared to using a single set of lockpicks and the lockpicking system, but should likely be how locksmiths handle opening locks for clients who've lost a key.

Other thoughts:
* Installing a new lock on a door would require permission from the door's owner.
* A key will have to be specified when locking and unlocking- it will not choose a key automatically. lock/unlock <object/direction> <key> edit: lock/unlock <key> <direction> would be better, to enable aliases for oft-used keys. 
* Would be best if coded so you can still specify a key without removing it from a keyring.
* lock/unlock should both be the same toggling command underneath- attempting to turn the given key in a lock. If it works it'll lock it if it was unlocked, unlock it if it was locked.

[Starstarfish]

A key will have to be specified when locking and unlocking- it will not choose a key automatically. lock/unlock <object/direction> <key>

I like most of this, but if you are a GL or someone who ends up with a lot of keys, remembering which of 12 keys goes to which of 15 doors will be IMHO kind of a hassle. And given that unlocking/locking a door quickly can become in theory a life/death factor, I feel like making this more complicated and prone to typos/mistakes might be ... problematic.

[Taunya]

Needing to specify the key was the main thing I thought might cause concern from a player perspective, and it does cause a little more inconvenience. But I think it's offset by being able to have master keys that open more than one lock, which should help GLs.

As someone who's been in a life/death situation in-game that involved a lock, I'd welcome that aspect of needing to fumble for the right key. It adds to the excitement, and makes things more fair to the pursuer than always picking out the right key the first time no matter what. I might even propose locking/unlocking become a threaded action.

[LonelyNeptune]

I like the idea of giving jewelers something cool to play with. But I definitely don't want to manually select my key every time I go through a locked door, which can be dozens of times a day.

[Starstarfish]

As someone who's been in a life/death situation in-game that involved a lock, I'd welcome that aspect of needing to fumble for the right key. It adds to the excitement, and makes things more fair to the pursuer than always picking out the right key the first time no matter what. I might even propose locking/unlocking become a threaded action.

That's the kind of thing that's just going to encourage aliases that just get around the intention to begin with.

[Taunya]

Aliases are fine! But that is what brought to mind the thought of making it threaded.
For slowing a pursuer down, wedging a blade into the door would still be an option and would be more practical in such situations anyway, would be realistically quicker than trying to stick a small key into a small keyhole while you're trying to flee. See any given thriller film.
I'm fine with it staying instant as well though. The only other reason to have it is to prevent spamming of skeleton keys to unlock a door in less time than should be realistically possible, but maybe that can be prevented a different way.

A thought: making it 'lock/unlock <key> <direction>' instead would allow aliases to be made for using specific keys, if that helps.
'alias plock lock (phomekey)' would let you do 'plock east' to lock the eastern door.
Actually, both lock and unlock should become a toggle that does the same thing- turns the key in the hole. If it's locked, it'll unlock, if it's unlocked it'll lock. Won't need a second alias for unlocking that way.

[Buzz K[ir]ill]

Threaded lock/unlock may sound realistic and exciting in a life/death situation, but for everyday mundane moving around and coming and going, which is 99% of the time, it sounds tedious AF. Even 2-3 seconds, added up across a week, could mean literally minutes of my time wasted.

While I think shifting locks into the hands of players for containers sounds great (and for phomes would allow many more shenanigans), it just doesn't sound like overall a good idea for new phomes or building requests. The proposed system sounds complicated, and our playerbase is small. It's hard enough to find someone who can make me noble-appropriate jewelry; I can't imagine having to wait on a jeweler to deliver locks and keys, both of which are far more critical for protecting one's assets and require a great deal more trust.

[Taunya]

The threaded idea isn't a sticking point for me. I'm fine with it in or out either way. Perhaps if it was only threaded when the key doesn't fit, that'd be a good compromise. Try a key and it works- turns instantly. Try a key and it doen't work, you're tied up for a few seconds trying to jiggle/twist, and the like. Just for the prevention of spamming skeleton keys faster than should be possible.

While I'd like PC locksmiths to handle locks wherever possible, and having to trust other PCs is part of what I like about this proposed system, it would make sense for staff to handle locks for the initial phome/shop/etc requests.
I'd suggest something like staff-done locks are limited to n number of doors, and can only be keyed one way, unless there's special circumstances where QP can be used for more flexibility (for a covert guild, mage's lair, etc). Have any other ideas that'd make it work?

[Puciek]

I agree with the view that it will create more annoyance than benefits. There are already many ways to pass a lock, and often too few merchants for comfort so it would turn into an annoying chore and limited options, rather than the system where you have a choice of locksmith of different repute.

[Niamh]

Added to discussion list.