Cataclysm-dda: Locked storage furniture idea that NPCs would not be able to take from.

[JerryLin1]

Is your feature request related to a problem? Please describe.
Neutral NPCs will walk through your base and take your items. The main ways to deal with this are hiding your items or killing the NPC, neither of which are elegant solutions.

Describe the solution you'd like
Add a furniture called lockbox/locked crate/locked chest that you can drop items in. NPCs will not be able to access the items on the furniture tile. It could be crafted and deployed (think brazier) or be made using the construction menu using a lock, two by fours, and a medium level of fabrication.

Additional context
I know NPCs are being worked on and once player ownership is defined this won't be a problem, but this could be a simple solution for now (I don't know C++ so this might be harder than I think it is)

[0be1isk]

it wouldn't be too hard to add, just need to add a conditional to the section from where NPCs can pick things up

[mlangsdorf]

I'm not going to stop anyone else from doing it, and if someone wants to start working on NPC AI, this is a good simple project and I'll be happy to help. But I'm not going to work on it myself because I would rather implement ownership.

[DracoGriffin]

This feature already exists as the cargo lock set.

However, the part can only be installed on these vehicle storage parts.

Duplicate of #19439.

[mlangsdorf]

This is a request for a furniture item with similar functionality.

[DracoGriffin]

This is a request for a furniture item with similar functionality.

Whoops, you are correct. I apologize, I hastily read through this as I was already seeing quite a few similar questions on subreddit about locking stuff.

[chriseich21]

I feel it might be a better solution if player was able to use a lock function/terrain recipe on certain objects, such as storage locker and doors, but might be better to implement after or with ownership since they're interrelated. Also description wise would probably be a combination lock. Could later be extended to vehicle security systems and car doors (similar to 2000's Explorers with keypad locks) to prevent use like mentioned in #19439 or #29112. Would be interested in working on it or another maybe simpler project to begin digging into Cataclysm's code and contributing.

[mlangsdorf]

See #29834 - it's complicated and has lots of moving parts.

[ghost]

Is this still wanted/required now item ownership is implemented?

[kevingranade]

If neutral NPCs respect ownership, yes.
Discouraging theft by hostile NPCs is a different feature.

[korvyr]

Tagging this for this weekend or next. (The comment lets me find it again.)

Current thought process for a quick fix:
1) Create a "SECURED" tag that can be applied to furniture, and slap it on safes for good measure (gives an example, is applicable, and allows testing).
2) Modify the NPC AI behavior that goes a hunting for loot in furniture and have it check for the "SECURED" tag if it belongs to a hostile faction. If it is "SECURED" and belongs to a hostile faction, no NPC looting.
3) Test it.
4) Profit.

Yes, I am the king of low-hanging fruit.

[Night-Pryanik]

Create a "SECURED" tag that can be applied to furniture

There is no way to apply flags to furniture in the runtime, that's the main issue.

[korvyr]

Create a "SECURED" tag that can be applied to furniture

There is no way to apply flags to furniture in the runtime, that's the main issue.

Didn't plan to.

[Night-Pryanik]

Then what did you plan to? Just set a prohibition for NPCs to check for loot? How it would be explained? Why wouldn't they want to look in some openable safe?

[korvyr]

Then what did you plan to? Just set a prohibition for NPCs to check for loot? How it would be explained? Why wouldn't they want to look in some openable safe?

More thinking along the lines of if it's able to be secured then why wouldn't you keep it secured after each use? If you want to get into it at that point, and it's not yours, you'd have to break into it (smash). Unless, of course, it's yours and then you'd have access.

That's why I said it would make said check for hostiles only. I suppose in that same vein I should have it equally act as "sealed" if the player attempts to access a "secured" piece of furniture that doesn't belong to them.

[korvyr]

Second post for a second thought: Along those lines, might even be worth looking at adding a lock picking check when accessing a hostile-owned secured container? Thoughts?

Edit: That may not work, as why would you lock it behind you if you just cracked it open, and there's no way to remove a flag. Short of having two objects, one for a secured state and one for an opened state? If opened, swap it out for the open object. If secured, swap to the secured version? Similar to doors and windows perhaps. That sounds messy though.

[Night-Pryanik]

Short of having two objects, one for a secured state and one for an opened state?

This was always and option, of course, but this limits us to only that specific type of furniture. And we want to place a lock on any container-type furniture.

[korvyr]

Short of having two objects, one for a secured state and one for an opened state?

This was always and option, of course, but this limits us to only that specific type of furniture. And we want to place a lock on any container-type furniture.

Hrm, would it be possible then to have the item gen take every type of furniture marked as "LOCKABLE" or some sort in the json data and automatically generate a second, locked version of that container? I know that too is getting into the danger zone, but it would allow you to have two different "states" for a collection of objects without actually having to have two different objects defined in the json data. It would then even permit tile designers to create an open/unlocked visual version by just applying it to the different objects.

At that point you could easily type up a piece of code that, when called, "locks" or "unlocks" a piece of furniture by reaching out to its designated and generated counterpart.

Edit: Hell, at that point you could almost just use the "SEALED" tag that already exists and generate a second state for each object with that flag that doesn't have the "SEALED" flag on it. You'd want to ID the second "state" in a very specific and accepted way, of course... some kind of prefix or suffix?

[Night-Pryanik]

I think this is possible, but I believe it would require a lot of coding.

[korvyr]

I think this is possible, but I believe it would require a lot of coding.

I'll give it a whirl, after I fix my big mistake on my open pull request. I'm hoping I can find a point in the furniture json->object generation process to hook in, check for a flag, and then generate a second item with a slightly modified ID and the flag removed.

I'd want a check to make sure the generated ID name doesn't already exist, of course. I'm excited to see if I can make it work without blowing everything up.

Edit: Definitely not the low-hanging fruit I was hoping for, but hey, gotta go bigger eventually.

[Night-Pryanik]

Good luck! Looking forward for your work.

[korvyr]

It seems I sadly won't be getting to this one. I think the idea is sound, though, if anyone else wants to give it a whirl.